Se requiere iniciar sesión antes de SQLmap

Question

Se requiere iniciar sesión antes de SQLmap

#1 de David Waters (3 votos)
#2 de schroeder (2 votos)
#3 de gmaran23 (2 votos)

5

Tengo datos de formulario de varias partes donde sospecho que uno de los campos de formulario de varias partes (parámetro denominado htmlbevt_id), es vulnerable a SQLi. Para probar el mismo, capturé la solicitud utilizando Burp y la guardé en un archivo, por ejemplo, myFile. Ahora en SQLMap ejecuté el siguiente comando:

sqlmap -r / root / Desktop / myFile -p htmlbevt_id

Recibo el siguiente mensaje de error:

no se puede conectar con la URL o el proxy de destino. sqlmap va a reintentar la solicitud

¿Me estoy perdiendo algo?

¿Debo iniciar sesión en la aplicación antes de ejecutar la consulta anterior? Si es así, ¿cómo hago para que SQL reconozca el inicio de sesión? Quiero decir, es que necesito iniciar sesión en la aplicación desde el navegador y luego ejecutar la consulta anterior (en cuyo caso no estoy seguro de cómo SQLMap sabría exactamente que ya he iniciado sesión en la aplicación), o si hay una ¿Otra forma de hacer esto?

A través de un poco más de google, aprendí que --cookie debe usarse para reproducir la autenticación de sesión en SQLmap. Además, dado que la solicitud es un POST, algunos foros sugieren el uso de --datos también, lo que hice. Sin embargo, nada de esto ha sido útil hasta ahora. Intenté -v 6 para depurar y ver qué estaba mal. Y los informes de SQLmap "no son datos de registro de WebScarab válidos". No estoy seguro si esta es la causa del error.

Ok, se resolvió gran parte del problema. Así que ahora, con la ayuda de la extensión de CO2 para Burp, pude reproducir todo el tráfico de la solicitud POST multiparte, junto con todas las cookies de sesión, a través de SQLMap.

Pero ahora hay un problema diferente al que me estoy enfrentando. Mientras busco la aplicación en el navegador, la sesión sigue viva. Pero mientras escaneaba el parámetro sospechoso inyectable de SQLi con SQLMap (establecí un nivel detallado en 3) descubrí que el servidor estaba devolviendo un tiempo de espera de sesión de HTTP 400. ¿Qué podría salir mal y hay una manera de mantener la sesión mantenida mientras SQLMap realiza el análisis?

authentication sql-injection penetration-test

pregunta qre0ct 03.09.2014 - 17:16

fuente

3 respuestas

Lea otras preguntas en las etiquetas authentication sql-injection penetration-test

¿Existe una forma eficiente de replicar un protocolo de enlace de 4 vías? Certificados de cliente contra tokens

score 3 · Answer 1

¿Puedes volver a reproducir la solicitud en burp? (Enviar a repetidor = > Ir)

Si es así, la forma más fácil de incluir esto en SQLMap es usar la extensión de CO2 que agrega "Enviar a SQLMap" en el menú del botón derecho. Esto le brinda la línea de comandos para enviar a SQLMap todas sus cookies y cualquier información. en la solicitud.

score 2 · Answer 2

2

Lo que parece que intentas hacer es ejecutar SQLmap en un archivo de texto estático. El archivo de solicitud está diseñado para capturar solicitudes para REEMPLAZAR contra el servidor. Su comando necesita el proxy o la URL que necesita probar.

respondido por el schroeder 03.09.2014 - 19:53

fuente

score 2 · Answer 3

Vengo de tu publicación del grupo nulo. Me alegro de que te hayas acercado al sistema;)

en el lenguaje de nivel de nivel de SQL puede significar dos cosas. Estoy respondiendo a tu edición el 4 de septiembre de 12.58.

-v (1-6) es el nivel de verbosidad, que se usa para mostrar la cantidad de mensajes que sqlmap escupe a la pantalla.
--level (1-5) es el nivel detectado sqli. Si el nivel especificado es más de 2, entonces sqlmap intentaría inyectar. Aumentar el nivel. A veces puede causar una solicitud incorrecta HTTP 400 porque los encabezados HTTP sería manipulado para detectar la inyección de SQL a través de valores en Los encabezados HTTP. Puede que sea por eso que obtienes un HTTP 400, no soy sin embargo, seguro que entiendes el tiempo de espera de la sesión HTTP 400.

Intente reducir el nivel o ignore el interruptor --level (déjelo con su valor predeterminado de 1) intente ajustar el interruptor --risk. ¿Realmente configuró el nivel detallado o el nivel de detección?