SQLMap en una forma secuencial

3

Hay un determinado formulario que se publica a través de POST. La forma tiene algunos elementos de forma. Estoy haciendo un pen-test en la aplicación que tiene este formulario. Los valores del formulario se almacenan en una base de datos determinada. Es una aplicación PHP y la parte interesante, que aprendí a través de algunas discusiones con el desarrollador que posee ese formulario, es que las declaraciones preparadas no se están utilizando para procesar las consultas respectivas para manejar los datos POST que llegan a través del formulario.

Esto me hizo sospechar y tener esperanzas de encontrar un posible SQLi.

Estoy ejecutando SQLmap incluyendo una sesión válida y otros datos de formulario. Sin embargo, a través de un -v 5, me di cuenta de que SQLMap en realidad está obteniendo una respuesta de redireccionamiento 302 para cada solicitud. A través de una investigación adicional, me di cuenta de que el formulario en cuestión (por ejemplo, form3) se obtiene después de seguir la secuencia

form1 - > form2 - > form3.

Si intento acceder a form3 directamente (incluso a través del navegador, por supuesto, después de iniciar sesión), me redireccionaré a form1. Así que necesito seguir la secuencia anterior estrictamente para poder enviar datos de form3 para ser procesados.

¿Hay alguna manera de automatizar esta secuencia en SQLmap? ¿O hay alguna forma de probar la existencia de un SQLi en form3 en el escenario anterior?

    
pregunta qre0ct 12.05.2015 - 21:38
fuente

1 respuesta

1

Generalmente, si encuentra un SQLi no necesita asignar la base de datos completa para probar la vulnerabilidad, en realidad se necesita muy poca información como prueba. SQLmap es una gran herramienta para lo que está destinado, mapear bases de datos, pero tiene algunas limitaciones en la usabilidad.

En general, recomiendo usar un escáner de aplicaciones web para buscar vectores SQLi, por ejemplo, el escáner proxy OWASP ZAP. Pero en este caso, incluso los escáneres pueden ser difíciles de configurar para realizar siempre una serie de solicitudes válidas antes de enviar el formulario de destino. Los escáneres tienen un gran conjunto de técnicas de análisis de respuestas y cargas útiles de SQLi ya hechas, y este es definitivamente un recurso que se debe utilizar.

Si todo falla, entonces una secuencia de comandos simple y una lista de cadenas SQLi podrían ser utilizado para hacer el trabajo. La automatización de los dos formularios anteriores que se enviarán con una entrada estática válida se realiza fácilmente en la mayoría de los idiomas, especialmente si no necesita ninguna parte de la respuesta. Después de esto, puede enviar el tercer formulario con un parámetro inyectado. Ahora puede repetir este proceso para todas las cargas útiles hasta obtener una respuesta interesante. Cualquier cosa ligeramente fuera de lo común es una respuesta interesante.

A menudo, un mensaje de error, una respuesta ligeramente diferente o una diferencia en la duración de la consulta es suficiente para montar un SQLi ciego ataque. Esto significa que toda la prueba necesaria para demostrar que existe una vulnerabilidad es una serie de (en este caso) tres solicitudes que terminan respondiendo de una manera que revela información sobre el proceso de consulta. Dada esta única serie de solicitudes de prueba de concepto, un atacante podría escribir fácilmente un script que extraiga lentamente toda la base de datos, usted, como probador, no necesita hacer esto.

Si es un programador experimentado, puede aprovechar las bibliotecas que forman parte del proyecto de mapa SQL .

    
respondido por el Juha Kivekäs 24.06.2015 - 15:37
fuente

Lea otras preguntas en las etiquetas