¿Es posible probar las vulnerabilidades de inyección de SQL con el uso de sqlmap con una url que usa reescritura de mod (o algo parecido) para limpiar las urls?
Sé cómo probar mis sitios que tienen direcciones URL como:
http://mysite.com/?id=1
Pero, ¿qué pasa con mis sitios que tienen direcciones URL limpias, como: http://mysite.com/1
Debería usar * en su URI, creando puntos de inyección de URI. Así que en lugar de usar:
sqlmap.py -u "website.com/script/paramrewrited1/paramrewrited2"
utilizar:
sqlmap.py -u "website.com/script/paramrewrited1*/paramrewrited2*"
Consulte wiki de sqlmap para obtener más opciones de uso. Desde esa página:
Punto de inyección URI
Hay casos especiales cuando el punto de inyección está dentro de la propia URI. sqlmap no realiza ninguna prueba automática contra rutas URI, a menos que señaló manualmente a. Tienes que especificar estos puntos de inyección en el línea de comando agregando un asterisco (
*) después de cada punto URI que desea que sqlmap pruebe y explote una inyección SQL.Esto es particularmente útil cuando, por ejemplo, los servidores web Apache mod_rewrite módulo en uso u otras tecnologías similares.
Un ejemplo de línea de comando válida sería:
$ python sqlmap.py -u "http://targeturl/param1/value1*/param2/value2/"
Si entiendo su pregunta, creo que sqlmap no está diseñado para hacer frente a esta situación (donde el servidor web no sigue los estándares web sobre cómo representar los parámetros de solicitud). Entonces, puedo pensar en algunas opciones:
Desactiva la reescritura de URL. Desactiva temporalmente la reescritura de parámetros de solicitud en tu servidor web (si hay una forma fácil de hacerlo), para que puedas ejecutar sqlmap.
Pruebe las solicitudes POST. Nos mostró que su servidor web codifica los parámetros de solicitud para las solicitudes GET de una manera no estándar. ¿Cómo codifica los parámetros de solicitud para las solicitudes POST? Si transmite el servidor web codifica los parámetros de solicitud de una manera más estándar, y si se puede acceder a cada solicitud a través de GET y POST (un error de configuración, pero uno común), puede probar su servidor enviando solicitudes POST en lugar de solicitudes GET. Consulte la opción --data en sqlmap.
Use alguna otra herramienta. Busque alguna otra herramienta, ya que sqlmap no parece estar diseñado para este caso en particular.
Modificar sqlmap. sqlmap es de código abierto. Podría sumergirse en el código fuente y extenderlo para respaldar el caso de uso que tiene en mente. (Es posible que desee ver el código que maneja la opción -p en sqlmap). Heck, es gratis; debe esperar que si tiene una situación inusual, es posible que aún no la maneje y que tenga que hacer un poco de trabajo por su cuenta. Si sigue esta ruta, devuélvala a la comunidad donando su código a los mantenedores de sqlmap.
No hay necesidad de reconstruir la URL. SQLMAP acepta las siguientes variaciones:
www.target1.com/vuln1.php?q=foobar www.target2.com/vuln2.asp?id=1 www.target3.com/vuln3/id/1*
Fuente: enlace
Te encuentras con esto a menudo debido a la optimización de motores de búsqueda (SEO) .
Por ejemplo, en lugar de lo siguiente:
http://www.com/index.phpoption=com_blahbla&Item=2&ItemId=5
Usted ve:
http://www.website.com/index,51,blabla
o
http://website.com/guestbook/page2
En este tipo de escenario, uno debe examinar el código fuente aplicable.
Se debe hacer una determinación sobre:
En un sitio web basado en Joomla, se evaluará el siguiente código:
<input type="hidden" name="option" value="com_blabla" />
<input type "hidden" name="ItemId" Value="5" />
<input type="hidden" name="Item" Value="2" />
<input type="hidden" Name="entry" Value="451" />
<input type="hidden" Name="view" Value="entries" />
Una vez realizada esta determinación, la URL se puede reconstruir a su forma original y, si es vulnerable, se ha explotado con éxito.
http://www.website.com/index.phpoption=com_blabla&Itemid=5&ItemId=2&Entry=451&View=Entries
Lea otras preguntas en las etiquetas web-application tools appsec sql-injection url-redirection