Algunas páginas de mi sitio web eran vulnerables a la inyección de SQL. La inyección funcionó solo cuando el usuario inició sesión. Ahora he solucionado este problema y ahora quiero asegurarme de que no haya problemas similares. He intentado escanear con sqlninja y sqlmap pero ninguno de los programas Tiene una disposición para dar detalles de inicio de sesión del sitio web. ¿Hay alguna herramienta que pueda escanear las vulnerabilidades de inyección con una sesión iniciada?
Hay una opción de cookie en sqlmap:
--cookie = COOKIE HTTP Encabezado de la cookie
Así que solo necesitas pegar tu cookie y podrás usar sqlmap como si estuvieras registrado.
Si necesita la lista de todas las opciones: enlace
Permítame ofrecerle una alternativa más fácil.
Es tu sitio web. Tienes acceso al código fuente. Revíselo y verifique que todas sus consultas de base de datos estén parametrizadas. Esto es mucho más eficaz que escanear su sitio web con la esperanza de que la herramienta que utilice intente la inyección correcta en el lugar correcto.
No "arreglas" los problemas de inyección de SQL. Bueno, la gente lo hace, pero eso está mal. Lo que debes hacer es no permitir que ocurran en primer lugar. La principal herramienta para eso es, como señala @TerryChia, sentencias SQL parametrizadas . Las sentencias SQL parametrizadas son muy efectivas para prevenir ataques de inyección SQL, al ser una solución genérica y completa; esto es mucho mejor, incomparablemente mejor, que cualquier tipo de "saneamiento de datos de entrada".
Los ataques de inyección SQL se producen porque el sitio web está intentando interpretar los datos proporcionados por el usuario (contenido del campo) como código (después de todo, SQL es un lenguaje de programación). Esta estrategia de implementación está condenada. No puede ser realmente "arreglado"; consulte esta respuesta para una discusión conceptual sobre este tema .
"Cuando la única herramienta que tienes es un martillo, es mejor que todos los problemas sean clavos, porque los golpearás repetidamente en la cabeza". Tenga en cuenta que las sentencias de SQL parametrizadas, aunque son ampliamente aplicables y eficientes (más que las sentencias de SQL "dinámicas" tradicionales), no pueden hacer todo ; hay contextos muy raros y específicos donde la creación dinámica de sentencias de SQL es la única solución. Pero esta no es tu situación, ya lo sabrías, y también todo lo que escribo en esta respuesta.
Las "herramientas de prueba" de inyección SQL no son satisfactorias de ninguna manera: no están diseñadas para garantizar la seguridad, sino para atacar a la "fruta de bajo rendimiento". Se perderán la gran mayoría de las posibles inyecciones de SQL. Su propósito es permitir que un atacante no técnico, sin embargo, crea que es un tipo de pirata informático de élite; o para automatizar los intentos de ataque en miles de sitios distintos. Lo que estas herramientas le dirán es unidireccional: si tienen éxito en ingresar a su sitio, entonces saben que el sitio es extremadamente vulnerable; sin embargo, si fallan , entonces usted no sabe nada.
Sin embargo , si desea que una herramienta supere un sistema de "sesión de inicio de sesión" (a pesar de todo lo que he explicado anteriormente), entonces depende de cómo se administre el inicio de sesión. La mayoría de los sitios web usarán una "página de inicio de sesión" que dará como resultado la configuración de un valor de cookie en el cliente; esa cookie representa el estado de "inicio de sesión" y basta con enviarlo de vuelta al servidor para que se considere como parte de la "sesión". Las herramientas de prueba de inyección SQL le permiten incluir valores de cookie arbitrarios en la solicitud, que es lo que está solicitando. Consulte, por ejemplo, la documentación de sqlninja (busque la segunda aparición de la palabra "cookie" en esa página) .
Puedes usar webslayer. enlace .
Webslayer es una aplicación de fuerza bruta / aplicación Fuzz. Para comprobar la inyección después de iniciar sesión, siga estos pasos.
Necesitarás lo siguiente: un navegador y un proxy interceptor como webscarab (o el complemento de datos de manipulación de Firefox).
Los pasos 3 a 7 es el funcionamiento estándar de webslayer, en el que puedes obtener un tutorial. Hay muchos videos para eso en Youtube como ( enlace )
Esto ayudará a probar cualquier vulnerabilidad de inyección en una sesión iniciada.
La mayoría de las aplicaciones web bien escritas tienen un inicio de sesión central o una lógica de validación de sesión. Lo que hago en estos casos es simplemente comentar esa parte del código en el servidor de desarrollo . Ahora todas mis herramientas tienen acceso a todas las funcionalidades.
Las declaraciones SQL parametrizadas son la única respuesta confiable para su problema. Es posible que sqlmap o havij no identifiquen el parámetro vulnerable, pero un hacker determinado y hábil podría. Por lo tanto, para estar seguro, desinfecte todas las consultas de su base de datos.
Lea otras preguntas en las etiquetas tools sql-injection mysql