Bypassing Security Filters
El otro tipo más común de vulnerabilidad por HTTP Verb Tampering es causado por errores de Insecure Coding cometidos durante el desarrollo de la aplicación web, lo que lleva a que la aplicación no cubra todos los métodos HTTP en ciertas funcionalidades. Esto se encuentra comúnmente en filtros de seguridad que detectan solicitudes maliciosas. Por ejemplo, si un filtro de seguridad se utiliza para detectar vulnerabilidades de inyección y solo verifica las inyecciones en los parámetros de POST (e.g. $_POST['parameter']), podría ser posible evadirlo simplemente cambiando el método de solicitud a GET.
Identify
En la aplicación web File Manager, si intentamos crear un nuevo nombre de archivo con caracteres especiales en su nombre (e.g. test;), obtenemos el siguiente mensaje:
http://SERVER_IP:PORT/
Este mensaje muestra que la aplicación web utiliza ciertos filtros en el back-end para identificar intentos de inyección y luego bloquea cualquier solicitud maliciosa. Sin importar lo que intentemos, la aplicación web bloquea nuestras solicitudes correctamente y está protegida contra intentos de inyección. Sin embargo, podemos intentar un ataque de HTTP Verb Tampering para ver si podemos evadir el filtro de seguridad por completo.
Exploit
Para intentar explotar esta vulnerabilidad, interceptemos la solicitud en Burp Suite (Burp) y luego usemos Change Request Method para cambiarlo a otro método: 
Esta vez, no obtuvimos el mensaje Malicious Request Denied!, y nuestro archivo fue creado con éxito:
http://SERVER_IP:PORT/
Para confirmar si logramos evadir el filtro de seguridad, necesitamos intentar explotar la vulnerabilidad que protege el filtro: en este caso, una vulnerabilidad de Command Injection. Entonces, podemos inyectar un comando que cree dos archivos y luego verificar si ambos archivos fueron creados. Para ello, usaremos el siguiente nombre de archivo en nuestro ataque (file1; touch file2;):
http://SERVER_IP:PORT/
Luego, nuevamente cambiamos el método de solicitud a una solicitud GET: 
Una vez que enviamos nuestra solicitud, vemos que esta vez tanto file1 como file2 fueron creados:
http://SERVER_IP:PORT/
Esto demuestra que logramos evadir el filtro a través de una vulnerabilidad de HTTP Verb Tampering y logramos Command Injection. Sin la vulnerabilidad de HTTP Verb Tampering, la aplicación web podría haber estado protegida contra ataques de Command Injection, pero esta vulnerabilidad permitió que evadiéramos los filtros implementados por completo.