necesita ayuda para entender MySQL inyección

Question

De http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php llegué:

inyección SQL se refiere al acto de alguien inserción de una declaración de MySQL a ser ejecutado en su base de datos sin su conocimiento . La inyección generalmente ocurre cuando le pides a un usuario la entrada, como su nombre, y en lugar de un nombre ellos le dan una declaración de MySQL que ejecutará sin saberlo en su base de datos.

He leído todo el artículo, pero todavía tengo algunos problemas importantes para entender qué es y cómo se puede hacer.

En el primer ejemplo, ¿qué verán en realidad?

Por lo que he entendido, si realmente me hago eco de $ name, verá todos los nombres porque siempre será "verdadero", ¿estoy en lo cierto?

La otra cosa que no entiendo es si EL problema de la inyección de MySQL se resuelve con mysql_real_escape_string(), tiene que haber más.

Lo que realmente no entiendo es que mysql_real_escape_string() está hecho para resolver ese problema, ¿por qué no se hace automáticamente, es decir, hay una razón por la que tiene que agregar cada vez mysql_real_escape_string(), hay casos cuando deberías usarlo y es por eso que no lo hacen automático?

Answer 1

MySQL no se escapará automáticamente, porque usted mismo construye la cadena de consulta.Por ejemplo:

$query = 'SELECT * FROM users WHERE name="' . $name . '"'; 

Acaba de pasar la cadena sin procesar almacenada en $ query, que está abierto a la inyección SQL. Por ejemplo, si el nombre es $ [algo "o" 1 = 1] su cadena de consulta termina siendo:

$query = 'SELECT * FROM users WHERE name="something" OR "1=1" 

que devolvería todos los usuarios de la tabla de usuario. Por eso es necesario que escapes valores. Sin embargo, si usa PDO, se hace por usted si usa la funcionalidad de enlace. Es un proceso de 2 pasos, prepara la consulta y luego "vincula" los datos/variables a los marcadores de posición. En PDO, su cadena de consulta sería algo como esto:

$query = 'SELECT * FROM users WHERE name=":name"'; 
$bindings = array('name'=>'something'); 
prepare($query); 
execute($bindings); 

Entonces, las cosas se escapan automáticamente para usted.

Answer 2

Bobby Tables tiene un excelente resumen de cómo funciona la inyección de SQL. De gran beneficio son los ejemplos que ofrece en varios idiomas (C#, Java, Perl, PHP, etc.)

En el caso de PHP, depende en gran medida de cómo se accede a la base de datos. Puede beneficiarse del uso de una capa de extracción de base de datos, como ADODB, que parametriza las consultas.

Answer 3

Por lo que sé, al hacer sitios web siempre debe suponer que el usuario final es una amenaza hedionda y sucia que quiere romper sus cosas. por lo que siempre debe limpiar sus cadenas con mysql_real_escape_string();, htmlentities(); y otros. El código puede ser insertado en los datos de su formulario que pueden salir de lo que estaba haciendo, insertar un nuevo código y luego tener un control completo de su base de datos y posiblemente de sus estructuras de archivos, dependiendo de a qué tiene acceso. esto significa que las tablas, los valores, las contraseñas y toda su base de datos se pueden destruir o modificar.

Hay instancias en las que es posible que desee insertar el código usted mismo, por ejemplo, qué pasa si desea crear una interfaz de usuario que pueda ingresar código en su base de datos. (ala phpMyAdmin). tal vez sería mejor tener el código de escape automáticamente de alguna manera, y luego escapársela si lo quisieras ... tal vez algo que deba discutirse con los creadores de PHP/mySQL?

Esto es todo lo que sé. Espero que alguien más pueda darte más información que esto. Recuerde siempre limpiar los valores que devuelve de los formularios y la entrada del usuario.

Answer 4

En el primer ejemplo en el enlace Tizag, la consulta parece que el autor del script espera que obtenga como máximo una fila. Por lo tanto, dado que se buscará cada fila, lo más probable es que se actúe sobre la información de la primera fila devuelta; ya que no hay una cláusula ORDER BY en la consulta manipulada, este puede ser el usuario almacenado primero en la tabla, pero por supuesto el orden no está definido en SQL cuando falta la cláusula ORDER BY, entonces quién puede decir.Lo que puede decir es que siempre que la tabla no esté vacía, obtendrá los detalles de un usuario válido.

No estoy seguro de lo que quiere decir con "if echo echo $name"; a la variable $name se le asigna el valor "timmy" en el código. Entonces ellos verían timmy, supongo. Si quieres decir, si trataste de hacer eco a la información del usuario obtenida por la consulta, ¿qué verían? Bueno, depende del código que estás usando. Si está recorriendo un conjunto de resultados y ellos usaron la inyección SQL para buscar filas que no esperaba que obtuvieran, es probable que vean todas las filas, incluidas las filas que no pretendía que vieran. Si su código simplemente recupera y actúa sobre la información de una fila, aún verá una fila, aunque nuevamente puede ser una fila a la que usted no quiso decir para poder acceder.

En cuanto a por qué la funcionalidad ofrecida por mysql_real_escape_string() no es automática, eso se debe a que para que sea automático dependerá de que una computadora pueda resolver el código SQL de lo que pretendía hacer, en lugar de solo hacer lo que dijo que hicieras. Eso es difícil y francamente indeseable, porque nadie quiere que una computadora adivine qué es lo que quiere hacer (particularmente los programadores).

Si desea poder evitar el uso de mysql_real_escape_string() y similares, es posible que desee consultar el uso de consultas parametrizadas, que le permiten tener un enfoque un poco más de manos libres. Sin embargo, todavía tiene que dejar en claro en la computadora qué partes de la consulta son variables que desea evitar, porque eso es solo una parte de comunicarle a la computadora lo que desea que suceda.

Answer 5

Tiene razón, en el primer ejemplo, a la persona que ingresó el nombre "incorrecto" se le ha permitido modificar la consulta de la base de datos que está realizando y en este caso, la han alterado para mostrar todas las filas del mesa.

En cuanto a cómo puede ser tan fácil de prevenir como el uso de una subrutina para escapar caracteres especiales, debe entender que una cadena (o cualquier dato) se puede entender en diferentes niveles. Cuando acepta la entrada del usuario y luego la usa para generar una consulta de base de datos, desea que el servidor de la base de datos interprete la cadena como datos. Sin embargo, la única razón por la que el servidor de base de datos hace esto es porque usa caracteres especiales como una comilla simple para que sepa dónde comienza y dónde termina una cadena. Escape Characters funcionan al decirle al servidor de base de datos (o cualquier otro sistema que los interpreta) que no interpreten caracteres especiales como caracteres especiales, sino que los interpreten como datos, al igual que el resto de la cadena. De esa forma, si uno de esos caracteres especiales está en su cadena, su función especial será ignorada.

¿Por qué esto no se hace automáticamente? No hay forma de que el servidor de la base de datos sepa en qué datos se puede confiar y qué datos no. Solo el programador lo sabe, ¡si tienen suerte! Y no puedes simplemente hacerlo en todos los datos porque esos caracteres especiales (como una comilla simple) están ahí por una razón: transmiten significado al servidor de la base de datos; si escapas a todos ellos, entonces no hay forma de transmitir su significado. Este es un concepto realmente fundamental en informática, que la misma información puede interpretarse en diferentes niveles en un sistema y un sistema puede usar patrones especiales de datos dentro de esa información para denotar cuándo los datos deben interpretarse en un nivel diferente.

Puede que le resulte útil leer también el concepto de capas de abstracción para obtener una comprensión más fundamental.

¡Buena suerte!

Answer 6

Cuando se habla de la inyección SQL, el ejemplo más común es "foo" O 1 = 1 "eliminar una tabla completa o revelar contraseñas. Estas inyecciones se pueden frustrar escapando de las cuerdas.

Sin embargo, hay inyecciones mucho más simples donde mysql_real_escape_string() es ineficaz. Por ejemplo, supongamos que tiene una página donde el usuario puede eliminar entradas seleccionadas de su base de datos. Una aplicación común es la construcción de consulta para borrar las entradas en función de GET o POST variables, por ejemplo:

$row_to_delete = $_POST['id']; 
$query = "DELETE FROM table WHERE id=$row_to_delete"; 

Como se puede ver, el usuario puede colocar fácilmente lo que sea "id" quieren este script, lo que podría borrar toda la tabla, incluso si mysql_real_escape_string() se realiza en la cadena. Esta misma vulnerabilidad puede explotarse en , adivinar, que "id" le pertenece al administrador y alterar los valores en cualquier lugar. Hasta donde yo sé, la única protección es validar TODOS los parámetros de obtención y publicación desde todos los ángulos posibles que se puedan imaginar. Básicamente, no solo realice la validación de formularios: realice la validación de PARÁMETROS.

Se sorprenderá de lo fácil que es dejar que una vulnerabilidad tan simple entre en su código.

Answer 7

mysql_real_escape_string() función que se utiliza principalmente para escapar de las cotizaciones que se traduce en la base de datos error.You no podía depender de esta función, ya que la desinfección muy importante, especialmente cuando la entrada del usuario directamente a query.You puede referir este sitio https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet