¿Hay alguna forma de inyectar SQL incluso si el personaje es eliminado?

StackOverflow https://stackoverflow.com/questions/71756

  •  09-06-2019
  •  | 
  •  

Pregunta

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

¿Cómo se puede hacer?Puede alguien darme algunos ejemplos?

¿Fue útil?

Solución

Sí, los hay.Un extracto de Wikipedia

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

Es claro a partir de esta declaración, que el autor tiene la intención de a_variable a ser un número en correlación con el campo "id".Sin embargo, si es de hecho una cadena, a continuación, el usuario final puede manipular la declaración de lo que elija, evitando así la necesidad de los caracteres de escape.Por ejemplo, la configuración de a_variable a

1;DROP TABLE users

se elimina), los "usuarios" de la tabla de la base de datos, desde el SQL podría ser representado de la siguiente manera:

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

La inyección SQL es no un simple ataque a la lucha.Yo haría muy cuidadosa investigación si yo fuera usted.

Otros consejos

Sí, dependiendo de la instrucción que está utilizando.Es mejor proteger a sí mismo ya sea mediante el uso de Procedimientos Almacenados, o al menos parametrizar las consultas.

Ver WikiPedia para la prevención de las muestras.

Sí, es definitivamente posible.

Si usted tiene un formulario donde se espera un entero para hacer de su próxima instrucción SELECT, entonces usted puede entrar algo similar:

SELECT * FROM thingy DONDE attributeID=

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

El siguiente sitio web de los detalles más clásicos de inyección de SQL técnicas: La Inyección de SQL hoja de trucos.

Mediante parametrización de consultas o procedimientos almacenados no es la mejor.Estos son sólo pre-hechos de consultas con los parámetros pasados, que puede ser fuente de inyección así como así.También se describe en esta página: Atacar a los Procedimientos Almacenados en SQL.

Ahora, si se suprime la simple cita, evitar que sólo un conjunto dado de ataque.Pero no todos ellos.

Como siempre, no confiar en los datos que vienen desde el exterior.Filtro de ellos en estos 3 niveles:

  • El nivel de la interfase por obvias cosas (una lista desplegable, seleccione de la lista es mejor que un campo de texto libre)
  • Nivel lógico de los controles relativos a los datos de la naturaleza (int, string, longitud), permisos (¿puede este tipo de datos a ser utilizado por el usuario en esta página)...
  • Base de datos de nivel de acceso (escapar de la simple cita...).

Divertirse y no se olvide de comprobar WikiPedia en busca de respuestas.

/Vey

Le sugiero que pase de las variables como parámetros, y no construir su propio SQL.De lo contrario no se allways ser una manera de hacer una inyección SQL, en las costumbres que tenemos en la actualidad son conscientes de apagado.

El código de crear es entonces algo 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 usted tiene un nombre como el mío con un ' en ella.Es muy molesto que todos los 'caracteres se eliminan o marcados como no válidos.

Usted también puede que desee ver en este Stackoverflow pregunta acerca de las Inyecciones de SQL.

Con parámetros en línea de SQL o procedimientos almacenados con parámetros es la mejor manera de protegerse.Como otros han señalado, simplemente stripping/escapar el carácter de comilla simple no es suficiente.

Te darás cuenta de que puedo hablar específicamente sobre la "parametrizado" procedimientos almacenados.Simplemente utilizando un procedimiento almacenado no es suficiente si volver a la concatenación de los parámetros pasados juntos.En otras palabras, envolviendo el mismo vulnerable instrucción SQL en un procedimiento almacenado no la hace más segura.Usted necesidad de utilizar parámetros en el procedimiento almacenado igual que en línea de SQL.

También - incluso si usted sólo tiene que buscar el apóstrofo, usted no quiere que la retire.Desea escape es.Hacer que mediante la sustitución de cada apóstrofo con dos apóstrofos.

Pero consultas parametrizadas/procedimientos almacenados son mucho mejores.

Desde esta relativamente mayores cuestión, no voy a molestarme en escribir un completo y exhaustivo de la respuesta, ya que la mayoría de los aspectos de respuesta que se han mencionado aquí por un cartel u otro.
Me parece necesario, sin embargo, traer a colación otro tema que no fue tocado por nadie aquí - SQL Contrabando.En ciertas situaciones, es posible "tráfico" de la cita de carácter ' a tu consulta incluso si se trató de quitarlo.De hecho, esto puede ser posible, incluso si usted utiliza comandos adecuados, parámetros, Procedimientos Almacenados, etc.

Retirar el completo trabajo de investigación en http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (revelación, yo era el principal investigador de este) o sólo google "SQL Contrabando".

...uh acerca de 50000000 otras maneras

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

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

(-- comienza un comentario)

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

La única defensa contra ataques de inyección de SQL es el uso de la instrucción SQL con parámetros apoyo ofrecido por su interfaz de base de datos.

En lugar de tratar de averiguar qué personajes para filtrar, se me pegan a las consultas parametrizadas en su lugar, y eliminar el problema por completo.

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

Por ejemplo, en Java si usted fuera a hacer esto (deliberadamente egregio ejemplo):

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

entonces hay una buena probabilidad de que se están abriendo a un ataque de inyección.

Java tiene algunas herramientas útiles para proteger en contra de estos, tales como PreparedStatements (donde se pasa una cadena como "SELECT nombre from Clientes where ID = ?" y el JDBC capa maneja escapa mientras que la sustitución de la ?fichas para usted), pero algunos otros idiomas no son tan útiles para esto.

La cosa es que apóstrofo quizás genuino de entrada y tienes que escapar de ellos doblando con ellos si usted está usando en línea de SQL en el código.Lo que usted está buscando es una expresión regular de patrón como:

\;.*--\

Un semi puntos para poner fin prematuramente a la genuina declaración, algunos SQL inyectado seguido por un doble guión para el comentario de la parte final del SQL de la original, genuina declaración.Los guiones pueden ser omitidos en el ataque.

Por lo tanto la respuesta es:No, simplemente la eliminación de los apóstrofes no bastan para garantizar la seguridad de la Inyección de SQL.

Sólo puedo repetir lo que otros han dicho.Parametrizadas SQL es el camino a seguir.Claro, es un poco de un dolor en el trasero de codificación - pero una vez que lo han hecho una vez, entonces no es difícil de cortar y pegar ese código, y hacer las modificaciones que usted necesita.Tenemos un montón de .Net aplicaciones que permiten a los visitantes del sitio web especificar una gama de criterios de búsqueda, y el código se basa la instrucción SQL Select sobre la marcha, pero todo lo que pudo haber sido introducidos por un usuario que entra en un parámetro.

Cuando usted está esperando un parámetro numérico, siempre debe ser la validación de la entrada para asegurarse de que es numérico.Más allá de la ayuda a proteger en contra de la inyección, la validación de paso hará que la aplicación sea más amigable para el usuario.

Si usted alguna vez ha recibido id = "hola" cuando esperaba id = 1044, siempre es mejor devolver un error útil para el usuario, en lugar de dejar que la base de datos devuelve un error.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top