La mejor manera de defenderse contra la inyección de mysql y las secuencias de comandos entre sitios

Question

Por el momento, aplico un método de 'tirar todo a la pared y ver qué pega' para detener los problemas antes mencionados. A continuación se muestra la función que he improvisado:

function madSafety($string) 
{ 

$string = mysql_real_escape_string($string); 
$string = stripslashes($string); 
$string = strip_tags($string); 
return $string; 

} 

Sin embargo, estoy convencido de que hay una mejor manera de hacerlo. Estoy usando FILTER_ SANITIZE_STRING y esto no parece totalmente seguro.

Supongo que estoy preguntando, ¿qué métodos emplean y qué tan exitosos son? Gracias

Answer 1

Simplemente haciendo muchas cosas que realmente no entiendes, no te va a ayudar. Debe comprender qué son los ataques de inyección y exactamente cómo y dónde debe hacer qué.

en forma de puntos:

• Disable magic quotes. Son una solución inadecuada y confunden las cosas.
• Nunca inserte cadenas directamente en SQL. Utilice los parámetros vinculados o escape (usando mysql_real_escape_string).
• No unescape (por ejemplo, stripslashes) cuando recupera datos de la base de datos.
• Cuando incrusta cadenas en html (por ejemplo, cuando echo), debe por defecto escapar de la cadena (utilizando htmlentities con ENT_QUOTES).
• Si necesita incrustar html-strings en html, debe considerar el origen de la cadena. Si no es de confianza, debe canalizarlo a través de un filtro. strip_tags es en teoría lo que debe usar, pero es defectuoso; Use HtmlPurifier en su lugar.

Consulte también: What's the best method for sanitizing user input with PHP?

Answer 2

No! El uso de mysql_real_escape_string es suficiente para protegerlo contra la inyección de SQL y el stropslashes que está haciendo después de lo hace vulnerable a la inyección de SQL. Si realmente lo desea, antes de ponerlo como en:

function madSafety($string) 
{ 
    $string = stripslashes($string); 
    $string = strip_tags($string); 
    $string = mysql_real_escape_string($string); 
    return $string; 
} 

stripslashes no es realmente útil si usted está haciendo mysql_real_escape_string.

strip_tags protege contra la inyección HTML/XML, no SQL.

Lo importante a tener en cuenta es que debe escapar de sus cadenas de manera diferente dependiendo del uso que le dé a la imediate.

Cuando está haciendo peticiones MYSQL use mysql_real_escape_string. Cuando está sacando páginas web, use htmlentities. Para compilar enlaces web, use urlencode ...

Como se mencionó anteriormente, si puede usar marcadores de posición, hágalo.

Answer 3

La mejor forma de evitar la inyección de SQL es vincular variables, en lugar de "inyectarlas" en una cadena. http://www.php.net/manual/en/mysqli-stmt.bind-param.php

Answer 4

Este tema es tan malo!

¡NO debe filtrar la entrada del usuario! Es información que ha sido ingresada por él. ¿Qué vas a hacer si quiero que mi contraseña sea como la siguiente: '"'>s3cr3t<script>alert()</script>

Filtrar los caracteres y dejarme una contraseña modificada, por lo que no puedo ni siquiera tener éxito en mi primer inicio de sesión? Esto es malo.

La solución adecuada es usar declaraciones preparadas o mysql_real_escape_string() para evitar inyecciones de sql y utilizar el escape contextual de los caracteres para evitar que el código html se estropee.

Déjame recordarte que la web es solo una de las formas en que puedes representar la información ingresada por el usuario. ¿Aceptarías tal desvinculación si algún software de escritorio lo hace? Espero que tu respuesta sea NO y entiendas por qué esta no es la manera correcta.

Tenga en cuenta que en un contexto diferente, se deben escapar caracteres diferentes. Por ejemplo, si se necesita mostrar el nombre de usuario como información sobre herramientas, que va a utilizar algo como:

<span title="{$user->firstName}">{$user->firstName}</span> 

Sin embargo, si el usuario ha establecido su nombre de pila a ser como '"><script>window.document.location.href="http://google.com"</script> lo que vas a hacer? Despojar las comillas? ¡Esto estaría tan mal! En lugar de hacer esto sin sentido, considere la posibilidad de escapar de las comillas mientras procesa los datos, ¡no mientras los persista!

Otro contexto que debe tener en cuenta es la prestación del valor en sí. Considere el código html usado anteriormente e imagine que el nombre del usuario sea como <textarea>. Esto incluiría todo el código html que sigue en este elemento textarea, lo que dividiría toda la página.

Una vez más, considere la posibilidad de escanear los datos según el contexto en el que lo esté utilizando.

P.S No estoy seguro de cómo reaccionar ante esos votos negativos. ¿Estás, gente, en realidad leyendo mi respuesta?

Última pregunta

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.

 Cuestiones relacionadas

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.