Formularios Sqlmap y multipart / form-data

2

Estoy trabajando en algo de seguridad para un sitio web que está construido en ASP clásico y MS SQL 2000.

He encontrado con éxito un par de formularios defectuosos que permitieron las inyecciones de SQL a través de los campos del formulario utilizando Sqlmap con los siguientes comandos:

python sqlmap.py -u "URL TO FORM" --forms --level=5 --risk=3 --batch

python sqlmap.py -u "URL TO FORM" --forms --dbs --level=5 --risk=3 --batch

Ahora estoy intentando verificar otro formulario que usa el tipo de codificación multipart / form-data.

Sqlmap no puede inyectar nada en este formulario, pero como está usando un tipo de codificación diferente, no sé si es por el tipo de codificación o porque Sqlmap no puede manejar este tipo de formulario.

El formulario utiliza consultas concatenadas, por lo que en mi opinión no debería ser seguro, pero el resultado de Sqlmap me ha arrojado un poco.

¿Alguien sabe si tengo que usar un comando diferente en este tipo de formulario o no se puede usar Sqlmap aquí?

Sólo una actualización rápida. Este es el mensaje que recibí de Sqlmap:

[WARNING] heuristic (basic) test shows that (custom) POST parameter 'MULTIPART #1*' might not be injectable

Luego continúa realizando las pruebas hasta que comienza de nuevo con:

[WARNING] heuristic (basic) test shows that (custom) POST parameter 'MULTIPART #2*' might not be injectable
    
pregunta Brigante 09.07.2013 - 15:48
fuente

2 respuestas

1

¿Por qué no lo haces manualmente? . Es bastante simple y le dará una mejor comprensión de qué tipo de filtrado está presente en la parte posterior y qué se puede hacer para evitarlo. En este momento simplemente estás confiando en la herramienta para darte un resultado. Si está involucrado en la prueba de lápiz de la aplicación, tenga cuidado, todavía puede haber errores. Y si lo haces por diversión, ¿por qué no aprender también?

Use los datos de Burp o Tamper, vea la solicitud y la respuesta, juegue con ellos y entenderá mejor la aplicación.

    
respondido por el oldnoob 07.08.2013 - 17:11
fuente
0

Este es un buen ejemplo de por qué los probadores de penetración no deben depender completamente de las herramientas, ya que a menudo conducen a falsos negativos. En este caso, un posible parámetro vulnerable se consideraría seguro debido a la obsesión de dicho tipo de "codificación" del formulario que elimina el Mapa SQL.

Mi recomendación sería utilizar un proxy de intercepción de tráfico manual como Burp Suite o Paros para comprender mejor los datos comunicados y modificarlos luego.

Consulte un cheatsheat de SQLI para conocer la sintaxis exacta con la que se debe probar.

    
respondido por el Rohan Durve 06.10.2013 - 22:43
fuente

Lea otras preguntas en las etiquetas