reales - sql injection example php

¿Hay alguna forma de inyectar SQL incluso si se elimina el carácter?

Question

Si de una consulta SQL elimino todos los ''caracteres, ¿hay alguna otra manera de hacer un ataque de inyección SQL en la base de datos?

¿Cómo puede hacerse esto? ¿Alguien puede darme ejemplos?

Answer 1

. . . uh alrededor de 50000000 otras formas

tal vez algo así como 5; drop table employees; -- 5; drop table employees; --

sql resultante puede ser algo como: select * from somewhere where number = 5; drop table employees; -- and sadfsf select * from somewhere where number = 5; drop table employees; -- and sadfsf

( -- comienza un comentario)

Answer 2

Además, incluso si solo busca el apóstrofo, no desea eliminarlo. Quieres escapar de eso. Lo haces reemplazando cada apóstrofo con dos apóstrofes.

Pero las consultas parametrizadas / procedimientos almacenados son mucho mejores.

Answer 3

Cosa es la entrada tal vez genuina de un apóstrofo y usted tiene que escapar de ellos duplicándolos cuando está usando SQL en línea en su código. Lo que estás buscando es un patrón regex como:

/;.*--/

Un semi colon solía terminar prematuramente la declaración genuina, algunos SQL inyectados seguidos por un doble guión para comentar el SQL final de la declaración genuina original. Los guiones pueden omitirse en el ataque.

Por lo tanto, la respuesta es: No, simplemente eliminar los apóstrofes no garantiza la seguridad de la inyección de SQL.

Answer 4

Cuando esperas un parámetro numérico, siempre debes estar validando la entrada para asegurarte de que sea numérica. Más allá de ayudar a proteger contra la inyección, el paso de validación hará que la aplicación sea más fácil de usar.

Si recibes id = "hello" cuando esperabas id = 1044, siempre es mejor devolver un error útil al usuario en lugar de dejar que la base de datos devuelva un error.

Answer 5

Dado que esta es una pregunta relativamente más antigua, no me molestaré en redactar una respuesta completa y exhaustiva, ya que la mayoría de los aspectos de esa respuesta han sido mencionados aquí por un poster u otro.
Sin embargo, me parece necesario mencionar otro tema que no fue abordado por nadie aquí: SQL Smuggling. En ciertas situaciones, es posible "contrabandear" el carácter de cita en su consulta, incluso si usted trató de eliminarlo . De hecho, esto puede ser posible incluso si usó los comandos adecuados, los parámetros, los Procedimientos almacenados, etc.

Consulte el documento de investigación completo en http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (declaración, yo era el investigador principal sobre esto) o simplemente google "SQL Smuggling".

Answer 6

Depende de cómo organices la consulta, pero en esencia sí.

Por ejemplo, en Java si tuviera que hacer esto (ejemplo deliberadamente atroz):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

entonces hay una buena posibilidad de que te estés abriendo a un ataque de inyección.

Java tiene algunas herramientas útiles para protegerse de ellas, como PreparedStatements (donde se ingresa una cadena como "SELECT name_ from Customer WHERE ID =?" Y la capa JDBC maneja escapes mientras se reemplazan los tokens), pero algunos otros idiomas no son tan útiles para esto.

Answer 7

En lugar de tratar de descubrir qué personajes filtrar, me quedaría con consultas parametrizadas y eliminaría el problema por completo.

Answer 8

Procedimientos SQL parametrizados en línea o parametrizados es la mejor manera de protegerse. Como han señalado otros, simplemente pelar / escapar del carácter de comillas simples no es suficiente.

Notarás que hablo específicamente sobre procedimientos almacenados "parametrizados". Simplemente usar un procedimiento almacenado tampoco es suficiente si se vuelve a concatenar los parámetros pasados ​​del procedimiento juntos. En otras palabras, envolver exactamente la misma declaración SQL vulnerable en un procedimiento almacenado no lo hace más seguro. Necesita usar parámetros en su procedimiento almacenado como lo haría con SQL en línea.

Answer 9

Sí hay. Un extracto de Wikipedia

"SELECT * FROM data WHERE id = " + a_variable + ";"

De esta declaración se deduce claramente que el autor pretendía que una_variable sea un número que se correlaciona con el campo "id". Sin embargo, si de hecho es una cadena, el usuario final puede manipular la declaración como lo prefiera, sin tener en cuenta la necesidad de caracteres de escape. Por ejemplo, establecer una variable para

1;DROP TABLE users

soltará (eliminará) la tabla de "usuarios" de la base de datos, ya que el SQL se representará de la siguiente manera:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

La inyección SQL no es un simple ataque para luchar. Haría una investigación muy cuidadosa si fuera tú.

Answer 10

Sí, absolutamente: dependiendo de su dialecto SQL y tal, hay muchas maneras de lograr la inyección que no utilizan el apóstrofo.

La única defensa confiable contra los ataques de inyección SQL es el uso del soporte de declaraciones SQL parametrizadas que ofrece su interfaz de base de datos.

Answer 11

Sí, dependiendo de la declaración que estés usando. Es mejor protegerse a sí mismo mediante el uso de procedimientos almacenados, o al menos consultas parametrizadas.

Consulte WikiPedia para ver ejemplos de prevención.

Answer 12

Sí, es definitivamente posible.

Si tiene un formulario donde espera un número entero para hacer su próxima declaración SELECT, puede ingresar cualquier cosa similar:

SELECCIONAR * FROM thingy DONDE attributeID =

• 5 (buena respuesta, no hay problema)
• 5; users tabla DROP; (malo malo malo...)

El siguiente sitio web detalla otras técnicas clásicas de inyección SQL : Hoja de referencia de SQL Injection .

El uso de consultas parametrizadas o procedimientos almacenados no es mejor. Estas son solo consultas pre-hechas usando los parámetros pasados, que también pueden ser una fuente de inyección. También se describe en esta página: Ataque de procedimientos almacenados en SQL .

Ahora, si suprimes la cita simple, evitas solo un conjunto determinado de ataques. Pero no todos ellos.

Como siempre, no confíes en los datos que vienen del exterior. Filtrarlos en estos 3 niveles:

• Nivel de interfaz para cosas obvias (una lista de selección desplegable es mejor que un campo de texto libre)
• Nivel lógico para verificaciones relacionadas con la naturaleza de los datos (int, cadena, longitud), permisos (este tipo de datos pueden ser utilizados por este usuario en esta página) ...
• Nivel de acceso a la base de datos (cita simple de escape ...).

Diviértete y no olvides consultar las páginas de Wikipedia .

/ Vey

Answer 13

Solo puedo repetir lo que otros han dicho. SQL parametrizado es el camino a seguir. Claro, es un poco doloroso codificarlo, pero una vez que lo ha hecho una vez, entonces no es difícil cortar y pegar ese código y hacer las modificaciones que necesita. Tenemos una gran cantidad de aplicaciones .Net que permiten a los visitantes del sitio web especificar una amplia gama de criterios de búsqueda, y el código crea la declaración SQL Select sobre la marcha, pero todo lo que podría haber ingresado un usuario entra en un parámetro.

Answer 14

Sugiero que pase las variables como parámetros y no que construya su propio SQL. De lo contrario, siempre habrá una forma de hacer una inyección SQL, de maneras que actualmente desconocemos.

El código que creas es algo así como:

'' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

Si tiene un nombre como el mío con un ''en él. Es muy molesto que todos los caracteres ''se eliminen o marquen como inválidos.

También es posible que desee ver esta pregunta de sobre las inyecciones de SQL .