¿Qué métodos están disponibles para probar las vulnerabilidades de inyección SQL?
Hay varias formas de probar una aplicación en busca de vulnerabilidades como la Inyección de SQL. Las pruebas se dividen en tres metodologías diferentes:
Ejemplo de MySQL:
http://localhost/test.php?id=sleep(30)
Si esta declaración SQL es interpretada por la base de datos, la página cargará 30 segundos.
http://localhost/test.php?id='"
Si el informe de errores está habilitado y esta solicitud es vulnerable a la inyección de SQL, se producirá el siguiente error:
Tienes un error en tu sintaxis SQL; revisa el manual que corresponde a la versión de su servidor MySQL para que se utilice la sintaxis correcta cerca de "" en la línea 5
Inyección basada en tautología :
http://localhost/test.php?username=' or 1=1 /*&password=1
En este caso, proporcionar una Tautology , o una declaración que siempre sea verdadera proporciona un resultado predecible. En este caso, el resultado predecible sería el registro en el atacante con el primer usuario en la base de datos, que generalmente es el administrador.
Existen herramientas que automatizan el uso de los métodos anteriores para detectar la inyección SQL en una aplicación web. Hay herramientas gratuitas y de código abierto como Wapiti y Skipfish que hacen esto. Sitewatch proporciona un servicio gratuito que es mucho mejor que estas herramientas de código abierto. Puedo decir eso porque soy un desarrollador de Sitewatch.
Es mejor no probar su sitio para la inyección de SQL. Es mejor simplemente evitar la inyección potencial de SQL. Nunca forme consultas SQL haciendo el procesamiento de cadenas usted mismo cuando hay una entrada del usuario. Utilice parámetros enlazados en todas las consultas (también puede desinfectar todos los datos del usuario si se puede usar de cualquier forma perjudicial y poner límites sensibles a las consultas). Esa es la consulta sql_execute("select user from user_db where id="+input_id) no es segura (imagínese si es input_id = "1 OR 1==1 --" ), pero stored_procedure = "select user from user_db where id = ? LIMIT 1;" , sql_execute_with_param(stored_procedure, input_id); es seguro.
Obviamente, esto es solo si está tratando de hacer que su propio sitio sea seguro. Si está tratando de encontrar fallas en otras aplicaciones, es otra historia, y potencialmente en contra de las preguntas frecuentes que indican que este sitio no es para sombreros negros. Pero OWASP tiene un muy buen artículo sobre las pruebas de inyección SQL .
Si está empezando desde cero, sugeriría una de las siguientes opciones:
Sin embargo, tenga en cuenta que cuando envía información extraña y potencialmente peligrosa a una aplicación web, tiene una posibilidad importante de dañar la integridad de su aplicación.
Puede romper completamente su aplicación web, o puede almacenar información extraña en la base de datos de la aplicación que luego se extrae y analiza de alguna manera, y tal vez ni siquiera su aplicación.
La regla general para este tipo de prueba es simple: no ha terminado la prueba hasta que se haya restaurado desde una copia de seguridad en buen estado. No debe considerar su aplicación en condiciones normales de funcionamiento después de las pruebas de inyección automatizadas hasta que lo haya hecho.
Lea otras preguntas en las etiquetas sql-injection