Running SQLMap on an HTTP Request

SQLMap dispone de numerosas opciones y parámetros que pueden utilizarse para configurar correctamente la solicitud (HTTP) antes de su uso.

En muchos casos, simples errores como olvidar proporcionar valores de cookies adecuados, complicar demasiado la configuración con una línea de comandos larga o declarar incorrectamente los datos POST formateados, impedirán la detección y explotación correctas de la posible vulnerabilidad SQLi.

Comandos Culr

Una de las mejores y más sencillas maneras de configurar correctamente una solicitud SQLMap contra el objetivo específico (es decir, una solicitud web con parámetros) es utilizando Copy as cURLla función del panel de Red (Monitor) dentro de las Herramientas para desarrolladores de Chrome, Edge o Firefox:

Al pegar el contenido del portapapeles ( Ctrl-V) en la línea de comandos y cambiar el comando original curla sqlmap, podemos usar SQLMap con el mismo curlcomando:

sqlmap 'http://www.example.com/?id=1' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0' -H 'Accept: image/webp,*/*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Connection: keep-alive' -H 'DNT: 1'

Al proporcionar datos para realizar pruebas a SQLMap, debe haber un valor de parámetro que pueda evaluarse para detectar vulnerabilidades de SQLi o opciones/interruptores especializados para la búsqueda automática de parámetros (por ejemplo --crawl, --formso -g).

Solucitudes GET/POST

En el caso más común, GETlos parámetros se proporcionan mediante la opción -u/ --url, como en el ejemplo anterior. Para probar POSTlos datos, --datase puede usar el siguiente indicador:

sqlmap 'http://www.example.com/' --data 'uid=1&name=test'

En estos casos, se analizarán los POSTparámetros para detectar vulnerabilidades de inyección SQL. Por ejemplo, si tenemos indicios claros de que un parámetro es vulnerable a una inyección SQL, podríamos limitar las pruebas a este parámetro . De lo contrario, podríamos marcarlo en los datos proporcionados con un marcador especial, como se muestra a continuación:uidnameuid-p uid*

sqlmap 'http://www.example.com/' --data 'uid=1*&name=test'

Solicitudes HTTP completas

Si necesitamos especificar una solicitud HTTP compleja con muchos valores de encabezado diferentes y un cuerpo POST extenso, podemos usar la -ropción correspondiente. Con esta opción, SQLMap recibe el "archivo de solicitud", que contiene la solicitud HTTP completa en un único archivo de texto. En un escenario común, dicha solicitud HTTP se puede capturar desde una aplicación proxy especializada (por ejemplo, `sqlmap.proxy` Burp) y escribir en el archivo de solicitud, de la siguiente manera:

Un ejemplo de una solicitud HTTP capturada con [herramienta/método] Burpse vería así:

GET /?id=1 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
DNT: 1
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947"
Cache-Control: max-age=0

Podemos copiar manualmente la solicitud HTTP Burpy guardarla en un archivo, o bien hacer clic derecho en la solicitud Burpy seleccionar la opción correspondiente Copy to file. Otra forma de capturar la solicitud HTTP completa sería mediante el navegador, como se mencionó anteriormente, seleccionando la opción Copy> Copy Request Headersy pegando la solicitud en un archivo.

Para ejecutar SQLMap con un archivo de solicitud HTTP, utilizamos el -rsiguiente indicador:

sqlmap -r req.txt
        ___
       __H__
 ___ ___["]_____ ___ ___  {1.4.9}
|_ -| . [(]     | .'| . |
|___|_  [.]_|_|_|__,|  _|
      |_|V...       |_|   http://sqlmap.org


[*] starting @ 14:32:59 /2020-09-11/

[14:32:59] [INFO] parsing HTTP request from 'req.txt'
[14:32:59] [INFO] testing connection to the target URL
[14:32:59] [INFO] testing if the target URL content is stable
[14:33:00] [INFO] target URL content is stable

Solicitudes SQLMap personalizadas

Si quisiéramos crear solicitudes complejas manualmente, existen numerosos parámetros y opciones para ajustar SQLMap.

Por ejemplo, si se requiere especificar el valor de la cookie (de sesión), la PHPSESSID=ab4530f4a7d10448457fa8b0eadac29copción --cookiese utilizaría de la siguiente manera:

sqlmap ... --cookie='PHPSESSID=ab4530f4a7d10448457fa8b0eadac29c'

El mismo efecto se puede lograr utilizando la opción -H/--header:

sqlmap ... -H='Cookie:PHPSESSID=ab4530f4a7d10448457fa8b0eadac29c'

Podemos aplicar lo mismo a opciones como --host, --referer, y -A/--user-agent, que se utilizan para especificar los mismos valores de las cabeceras HTTP.

Además, existe una opción --random-agentpara seleccionar aleatoriamente un User-agentvalor de encabezado de la base de datos incluida, que contiene valores estándar de navegador. Es importante recordar esta opción, ya que cada vez más soluciones de protección bloquean automáticamente todo el tráfico HTTP que contiene el valor User-agent predeterminado y reconocible de SQLMap (por ejemplo, `user-agent` User-agent: sqlmap/1.4.9.12#dev (http://sqlmap.org)). Como alternativa, esta --mobileopción se puede usar para imitar al teléfono inteligente utilizando ese mismo valor de encabezado.

Aunque SQLMap, por defecto, solo analiza los parámetros HTTP, es posible probar las cabeceras en busca de la vulnerabilidad de inyección SQL. La forma más sencilla es especificar la marca de inyección personalizada después del valor de la cabecera (por ejemplo, `<meta>` --cookie="id=1*"). El mismo principio se aplica a cualquier otra parte de la solicitud.

Además, si quisiéramos especificar un método HTTP alternativo, distinto de GETy POST(por ejemplo, PUT), podemos utilizar la opción --method, de la siguiente manera:

sqlmap -u www.target.com --data='id=1' --method PUT

Solicitudes HTTP personalizadas

Además del POSTestilo de cuerpo de datos de formulario más común (por ejemplo, id=1), SQLMap también admite solicitudes HTTP con formato JSON (por ejemplo, {"id":1}) y con formato XML (por ejemplo, <element><id>1</id></element>).

La compatibilidad con estos formatos se implementa de forma flexible; por lo tanto, no existen restricciones estrictas sobre cómo se almacenan los valores de los parámetros. Si el POSTcuerpo es relativamente simple y corto, esta opción --dataserá suficiente.

Sin embargo, en el caso de un cuerpo POST complejo o extenso, podemos volver a utilizar la -ropción:

cat req.txt
HTTP / HTTP/1.0
Host: www.example.com

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "Example JSON",
      "body": "Just an example",
      "created": "2020-05-22T14:56:29.000Z",
      "updated": "2020-05-22T14:56:28.000Z"
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "user"}
      }
    }
  }]
}

sqlmap -r req.txt
        ___
       __H__
 ___ ___[(]_____ ___ ___  {1.4.9}
|_ -| . [)]     | .'| . |
|___|_  [']_|_|_|__,|  _|
      |_|V...       |_|   http://sqlmap.org


[*] starting @ 00:03:44 /2020-09-15/

[00:03:44] [INFO] parsing HTTP request from 'req.txt'
JSON data found in HTTP body. Do you want to process it? [Y/n/q] 
[00:03:45] [INFO] testing connection to the target URL
[00:03:45] [INFO] testing if the target URL content is stable
[00:03:46] [INFO] testing if HTTP parameter 'JSON type' is dynamic
[00:03:46] [WARNING] HTTP parameter 'JSON type' does not appear to be dynamic
[00:03:46] [WARNING] heuristic (basic) test shows that HTTP parameter 'JSON type' might not be injectable