Attack Tuning
En la mayoría de los casos, SQLMap debería funcionar sin problemas con los detalles del objetivo proporcionados. Sin embargo, existen opciones para ajustar los intentos de inyección SQLi y así ayudar a SQLMap en la fase de detección. Cada carga útil enviada al objetivo consta de:
vector (ej.,
UNION ALL SELECT 1,2,VERSION()): parte central de la carga útil, que contiene el código SQL útil que se ejecutará en el objetivo.límites (ej.
'<vector>-- -): formaciones de prefijos y sufijos, utilizadas para la inyección adecuada del vector en la instrucción SQL vulnerable.
Prefix/Suffix
En casos excepcionales, se requieren valores especiales de prefijo y sufijo que no se contemplan en la ejecución normal de SQLMap.
Para dichas ejecuciones, se pueden utilizar las siguientes --prefixopciones :--suffix
sqlmap -u "www.example.com/?q=test" --prefix="%'))" --suffix="-- -"Esto dará como resultado que todos los valores vectoriales queden encerrados entre el prefijo estático %'))y el sufijo -- -.
Por ejemplo, si el código vulnerable en el objetivo es:
$query = "SELECT id,name,surname FROM users WHERE id LIKE (('" . $_GET["q"] . "')) LIMIT 0,1";
$result = mysqli_query($link, $query);El vector UNION ALL SELECT 1,2,VERSION(), delimitado por el prefijo %'))y el sufijo -- -, dará como resultado la siguiente instrucción SQL (válida) en el destino:
SELECT id,name,surname FROM users WHERE id LIKE (('test%')) UNION ALL SELECT 1,2,VERSION()-- -')) LIMIT 0,1Level/Risk
Por defecto, SQLMap combina un conjunto predefinido de límites más comunes (es decir, pares de prefijo/sufijo) con los vectores que presentan una alta probabilidad de éxito en caso de un objetivo vulnerable. No obstante, los usuarios pueden utilizar conjuntos más amplios de límites y vectores, ya incorporados en SQLMap.
Para tales demandas, se deben utilizar las --levelsiguientes opciones:--risk
La opción
--level(1-5, valor predeterminado1) extiende tanto los vectores como los límites que se utilizan, en función de su expectativa de éxito (es decir, cuanto menor sea la expectativa, mayor será el nivel).La opción
--risk(1-3, valor predeterminado1) amplía el conjunto de vectores utilizados en función de su riesgo de causar problemas en el lado de destino (es decir, riesgo de pérdida de entrada de base de datos o denegación de servicio).
La mejor manera de comprobar las diferencias entre los límites y las cargas útiles utilizados para distintos valores de `x` --levele `y` --riskes usar la -vopción `--verbose` para establecer el nivel de detalle. Con un nivel de detalle de 3 o superior (por ejemplo, `-3` ), se mostrarán -v 3mensajes que contengan los límites utilizados , como se indica a continuación:[PAYLOAD]
Por otro lado, las cargas útiles utilizadas con el --levelvalor predeterminado tienen un conjunto de límites considerablemente menor:
En cuanto a los vectores, podemos comparar las cargas útiles utilizadas de la siguiente manera:
En cuanto al número de cargas útiles, por defecto (es decir --level=1 --risk=1), el número de cargas útiles utilizadas para probar un solo parámetro llega hasta 72, mientras que en el caso más detallado ( --level=5 --risk=3) el número de cargas útiles aumenta a 7.865.
Dado que SQLMap ya está configurado para detectar los límites y vectores más comunes, se recomienda a los usuarios habituales no modificar estas opciones, ya que ralentizaría considerablemente el proceso de detección. No obstante, en casos especiales de vulnerabilidades de inyección SQL, donde el uso de ORpayloads es imprescindible (por ejemplo, en el caso de loginpáginas), es posible que debamos aumentar el nivel de riesgo manualmente.
Esto se debe a que ORlas cargas útiles son inherentemente peligrosas en una ejecución predeterminada, donde las sentencias SQL vulnerables subyacentes (aunque con menos frecuencia) están modificando activamente el contenido de la base de datos (por ejemplo, DELETEo UPDATE).
Advanced Tuning
Para ajustar con mayor precisión el mecanismo de detección, existe un amplio conjunto de opciones y parámetros. En la mayoría de los casos, SQLMap no requerirá su uso. Sin embargo, es importante familiarizarse con ellos para poder utilizarlos cuando sea necesario.
Status Codes
Por ejemplo, al procesar una respuesta de destino de gran tamaño con mucho contenido dinámico, las diferencias sutiles entre TRUElas FALSErespuestas podrían utilizarse para la detección. Si la diferencia entre TRUElas FALSErespuestas se observa en los códigos HTTP (p. ej ., 200para GET TRUEy GET para 500POST ), se podría usar FALSEla opción para limitar la detección de respuestas a un código HTTP específico (p. ej., GET, POST ).--codeTRUE--code=200
Titles
Si la diferencia entre las respuestas se puede observar inspeccionando los títulos de las páginas HTTP, el interruptor --titlespodría utilizarse para indicar al mecanismo de detección que base la comparación en el contenido de la etiqueta HTML.
Strings
En caso de que aparezca un valor de cadena específico en TRUElas respuestas (por ejemplo success), mientras que esté ausente en las respuestas, se podría utilizar FALSEla opción para fijar la detección basándose únicamente en la aparición de ese único valor (por ejemplo ).--string--string=success
Text-only
Cuando se trata de mucho contenido oculto, como ciertas etiquetas de comportamiento de página HTML (por ejemplo, <style>, <meta>, etc.), podemos usar el --text-onlyinterruptor, que elimina todas las etiquetas HTML y basa la comparación únicamente en el contenido textual (es decir, visible).
Techniques
En algunos casos especiales, debemos restringir las cargas útiles utilizadas a un tipo específico. Por ejemplo, si las cargas útiles ciegas basadas en el tiempo causan problemas como tiempos de espera agotados en la respuesta, o si queremos forzar el uso de un tipo específico de carga útil SQLi, la opción --techniquepermite especificar la técnica SQLi que se utilizará.
Por ejemplo, si queremos omitir las cargas útiles SQLi ciegas basadas en el tiempo y de apilamiento y solo probar las cargas útiles ciegas basadas en booleanos, basadas en errores y de consulta UNION, podemos especificar estas técnicas con --technique=BEU.
UNION SQLi Tuning
In some cases, UNION SQLi payloads require extra user-provided information to work. If we can manually find the exact number of columns of the vulnerable SQL query, we can provide this number to SQLMap with the option --union-cols (e.g. --union-cols=17). In case that the default "dummy" filling values used by SQLMap -NULL and random integer- are not compatible with values from results of the vulnerable SQL query, we can specify an alternative value instead (e.g. --union-char='a').
Furthermore, in case there is a requirement to use an appendix at the end of a UNION query in the form of the FROM
(e.g., in case of Oracle), we can set it with the option --union-from (e.g. --union-from=users). Failing to use the proper FROM appendix automatically could be due to the inability to detect the DBMS name before its usage.
Last updated