Quando visitiamo un sito, il browser comunica continuamente con il server attraverso richieste HTTP.
La più conosciuta è probabilmente:
GET /
Ma HTTP mette a disposizione diversi metodi:
GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS
Durante un security scan può capitare di trovarne alcuni che non ci aspettavamo.
E a quel punto nasce una domanda:
Se un server accetta
PUToDELETE, significa che è vulnerabile?
La risposta è: non necessariamente.
A cosa servono i metodi HTTP?
Ogni metodo esprime un tipo di operazione.
In modo semplificato:
| Metodo | Utilizzo tipico | | ------- | ---------------------------------------- | | GET | Recuperare una risorsa | | POST | Creare o elaborare dati | | PUT | Creare o sostituire una risorsa | | PATCH | Modificare parzialmente una risorsa | | DELETE | Eliminare una risorsa | | HEAD | Recuperare gli header senza il corpo | | OPTIONS | Informazioni sulle operazioni supportate |
L'utilizzo effettivo dipende dall'applicazione.
GET non significa automaticamente "sicuro"
Un errore abbastanza comune è pensare che:
GET /delete-user?id=123
sia sicuro soltanto perché utilizza GET.
Il problema non è il nome del metodo, ma l'operazione che il server esegue.
Le operazioni che modificano dati dovrebbero essere progettate e protette correttamente, indipendentemente dal fatto che la richiesta utilizzi GET o un altro metodo.
Perché PUT e DELETE attirano attenzione?
Immaginiamo un endpoint API:
/api/users/123
che accetta:
PUT /api/users/123
e:
DELETE /api/users/123
Non c'è nulla di strano.
È perfettamente normale che un'API REST utilizzi questi metodi.
Il problema nasce se il server permette operazioni privilegiate senza verificare adeguatamente l'identità e i permessi dell'utente.
Quindi il controllo importante non è:
"DELETE è abilitato?"
ma:
"Chi può utilizzare DELETE e cosa può eliminare?"
Il metodo OPTIONS
OPTIONS viene spesso incontrato durante l'analisi di applicazioni web e API.
Una richiesta:
OPTIONS /api/users
può fornire informazioni sui metodi supportati.
Ad esempio:
Allow: GET, POST, OPTIONS
Questo può essere utile per comprendere il comportamento di un endpoint.
Non significa però che la semplice presenza di OPTIONS rappresenti un problema.
Il metodo TRACE
Un altro metodo che può comparire nei controlli è:
TRACE
È utilizzato per scopi diagnostici e può essere disabilitato quando non è necessario.
La sua presenza merita quindi una verifica, soprattutto in relazione alla configurazione del server e dell'applicazione.
Ma anche in questo caso è importante non trasformare automaticamente un'informazione di configurazione in una vulnerabilità.
Come verificare i metodi supportati
Una richiesta OPTIONS può fornire alcune indicazioni:
curl -i -X OPTIONS https://example.com/
Il server potrebbe rispondere con:
HTTP/2 204
Allow: GET, POST, OPTIONS
Il risultato dipende dalla configurazione del server e dell'applicazione.
Per le API, è spesso più utile verificare gli endpoint specifici:
/api/users
/api/orders
/api/products
piuttosto che limitarsi alla homepage.
Il vero problema: autorizzazione
Supponiamo che un endpoint supporti:
DELETE /api/orders/123
Il problema di sicurezza non è necessariamente l'esistenza del metodo DELETE.
Bisogna verificare che l'applicazione controlli correttamente:
- chi effettua la richiesta;
- quale risorsa sta tentando di modificare;
- quali permessi possiede;
- se quella risorsa appartiene effettivamente all'utente;
- quali condizioni devono essere rispettate.
Questo porta direttamente a un concetto fondamentale della sicurezza web: l'autorizzazione.
Metodi HTTP e API
Le API moderne utilizzano spesso diversi metodi in combinazione.
Un esempio:
GET /api/users
POST /api/users
GET /api/users/123
PATCH /api/users/123
DELETE /api/users/123
Questa struttura è assolutamente normale.
Durante una valutazione di sicurezza, però, è utile mappare quali metodi sono disponibili e quali funzionalità espongono.
Un endpoint che consente di leggere dati pubblici è molto diverso da uno che consente di eliminare account.
Non guardare soltanto lo status code
Anche qui, il semplice status code non racconta tutta la storia.
Ad esempio:
HTTP/2 405 Method Not Allowed
indica che il metodo non è consentito su quella risorsa.
Un:
HTTP/2 401 Unauthorized
indica che è richiesta autenticazione.
Un:
HTTP/2 403 Forbidden
indica che il server sta rifiutando la richiesta per motivi di autorizzazione.
Questi risultati devono essere interpretati nel contesto dell'endpoint.
Una checklist pratica
Quando controlli i metodi HTTP:
- [ ] quali metodi sono supportati?
- [ ] quali endpoint li utilizzano?
- [ ] quali richiedono autenticazione?
- [ ] quali richiedono privilegi specifici?
- [ ] le operazioni distruttive sono adeguatamente protette?
- [ ]
TRACEè necessario? - [ ] CORS e
OPTIONSsono configurati correttamente? - [ ] le API applicano correttamente l'autorizzazione?
Perché è utile dal punto di vista della sicurezza
Mappare i metodi HTTP permette di comprendere meglio cosa può fare un'applicazione.
Non basta sapere che:
api.example.com
esiste.
È utile sapere anche quali funzionalità offre.
La combinazione tra endpoint, metodi HTTP, autenticazione e autorizzazione fornisce una visione molto più utile della superficie applicativa.
MiHakero e i metodi HTTP
Durante una valutazione esterna, i metodi HTTP sono una delle informazioni che possono aiutare a comprendere il comportamento di un servizio.
L'obiettivo non è segnalare semplicemente che un'API supporta PUT o DELETE.
È capire quali superfici meritano un controllo più approfondito.
Perché DELETE non è pericoloso in quanto tale.
È pericoloso quando permette di fare qualcosa che non si dovrebbe poter fare.