Il protocollo HTTP funziona accettando vari metodi HTTP come verbi all’inizio di una richiesta HTTP. A seconda della configurazione del server web, le applicazioni web possono essere programmate per accettare determinati metodi HTTP per le loro diverse funzionalità ed eseguire una particolare azione in base al tipo di richiesta.
Mentre i programmatori considerano principalmente i due metodi HTTP più comunemente utilizzati, GET e POST, qualsiasi client può inviare qualsiasi altro metodo nelle proprie richieste HTTP e poi vedere come il server web li gestisce. Supponiamo che sia l’applicazione web che il server web back-end siano configurati per accettare solo richieste GET e POST. In tal caso, l’invio di una richiesta diversa causerà la visualizzazione di una pagina di errore del server web, il che non costituisce di per sé una vulnerabilità grave (a parte il fatto di compromettere l’esperienza utente e potenzialmente portare alla divulgazione di informazioni). D’altro canto, se le configurazioni del server web non sono limitate ad accettare solo i metodi HTTP richiesti dal server web (ad esempio GET/POST) e l’applicazione web non è sviluppata per gestire altri tipi di richieste HTTP (ad esempio HEAD, PUT), potremmo essere in grado di sfruttare questa configurazione non sicura per ottenere l’accesso a funzionalità a cui non abbiamo accesso o addirittura aggirare determinati controlli di sicurezza.
Insecure Configurations
Le configurazioni non sicure dei server web causano il primo tipo di vulnerabilità di manomissione dei verbi HTTP. La configurazione di autenticazione di un server web potrebbe essere limitata a specifici metodi HTTP, il che renderebbe alcuni metodi HTTP accessibili senza autenticazione. Ad esempio, un amministratore di sistema potrebbe utilizzare la seguente configurazione per richiedere l’autenticazione su una particolare pagina web:
<Limit GET POST>
Require valid-user
</Limit>Come possiamo vedere, anche se la configurazione specifica sia richieste GET che POST per il metodo di autenticazione, un aggressore potrebbe comunque utilizzare un metodo HTTP diverso (come HEAD) per aggirare completamente questo meccanismo di autenticazione, come vedremo nella prossima sezione. Questo alla fine porta a un bypass dell’autenticazione e consente agli aggressori di accedere a pagine web e domini a cui non dovrebbero avere accesso.
Insecure Coding
Le pratiche di codifica non sicure causano l’altro tipo di vulnerabilità HTTP Verb Tampering (anche se alcuni potrebbero non considerare questa vulnerabilità). Ciò può verificarsi quando uno sviluppatore web applica filtri specifici per mitigare particolari vulnerabilità, senza però coprire tutti i metodi HTTP con quel filtro. Ad esempio, se una pagina web è stata trovata vulnerabile a una vulnerabilità di tipo SQL Injection e lo sviluppatore back-end ha mitigato la vulnerabilità di tipo SQL Injection applicando i seguenti filtri di sanificazione dell’input:
$pattern = "/^[A-Za-z\s]+$/";
if(preg_match($pattern, $_GET["code"])) {
$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
...SNIP...
}Possiamo osservare che il filtro di sanificazione viene testato solo sul parametro GET. Se le richieste GET non contengono caratteri non validi, la query verrà eseguita. Tuttavia, quando la query viene eseguita, vengono utilizzati i parametri $_REQUEST["code"], che potrebbero contenere anche parametri POST, causando un’incoerenza nell’uso dei verbi HTTP. In questo caso, un aggressore potrebbe utilizzare una richiesta POST per eseguire un’iniezione SQL, nel qual caso i parametri GET sarebbero vuoti (non includerebbero caratteri non validi). La richiesta supererebbe il filtro di sicurezza, il che renderebbe la funzione ancora vulnerabile all’iniezione SQL.
Sebbene entrambe le vulnerabilità sopra menzionate siano note al pubblico, la seconda è molto più comune, poiché è dovuta a errori di codifica, mentre la prima viene solitamente evitata tramite configurazioni sicure del server web, come spesso indicato nella documentazione.