HTTP Method Tampering

Perché È Importante

I controlli di accesso spesso sorvegliano solo le porte che gli sviluppatori si aspettano gli attaccanti usino. Un muro di login messo davanti a GET e POST può lasciare HEAD, OPTIONS, PUT e TRACE spalancati, e un attaccante che si limita a cambiare il verbo entra dritto dentro. Poiché in un normale browser, dove ogni richiesta è un GET o un POST, il controllo continua a sembrare corretto, questa falla può sopravvivere in produzione per anni.

L'HTTP method tampering è una forma da manuale di broken access control, il rischio numero uno della OWASP Top 10, ed è banale da testare una volta che intercetti una richiesta con un proxy come Burp Suite.

Come Funziona

Un percorso amministrativo protetto restituisce 401 nel browser. Il tester cattura la richiesta e la rigioca con metodi diversi, senza cambiare nient'altro:

GET     /admin   ->  401 Unauthorized
POST    /admin   ->  401 Unauthorized
HEAD    /admin   ->  200 OK
OPTIONS /admin   ->  200 OK

Il 200 su HEAD significa che il server ha elaborato la richiesta come valida. La configurazione errata sottostante di solito assomiglia a un blocco Apache che elenca solo due metodi:

<Limit GET POST>
  require valid-user
</Limit>

Tutto ciò che non è nominato, HEAD, OPTIONS, TRACE e PUT, salta del tutto il controllo di autenticazione. Una variante correlata abusa dei framework che instradano un metodo inatteso allo stesso handler ma applicano un percorso di autorizzazione diverso e più debole.

Perché Persiste

Il bug sopravvive perché gli sviluppatori ragionano sui due metodi che un browser usa davvero e dimenticano il resto della specifica HTTP. Mettere in allow list dà una sensazione di sicurezza, ma qualsiasi metodo lasciato fuori dalla lista non eredita alcuna protezione. Load balancer, vecchie regole mod_auth e snippet di configurazione copiati diffondono lo stesso pattern in molte applicazioni.

Come Testarla

Per ogni endpoint protetto, rigioca la richiesta con l'insieme completo dei metodi: GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH e TRACE. Osserva qualsiasi metodo che restituisca un 200 o un corpo diverso, e confronta con attenzione gli status code, dato che un 405 è sano mentre un 200 su un verbo inatteso è una scoperta. Metodi arbitrari o inventati a volte rivelano una gestione ancora più lasca.

Prevenzione

Imponi l'autorizzazione su tutti i metodi per impostazione predefinita e consenti solo i verbi di cui un endpoint ha effettivamente bisogno. Sostituisci i blocchi di configurazione specifici per metodo con una policy deny by default, restituisci 405 per i metodi non supportati, disabilita TRACE e testa ogni endpoint limitato con l'insieme completo dei metodi per verificare che il controllo non si possa aggirare.