Scanner di metodi HTTP pericolosi

Come funziona questo controllo

Scanaris invia una richiesta OPTIONS all'URL analizzato, senza seguire i reindirizzamenti, e legge due header della risposta: Allow, con cui un server dichiara quali metodi accetta su quella rotta, e Access-Control-Allow-Methods, quello di CORS. Se in uno dei due compare TRACE, TRACK, PUT, DELETE o CONNECT, apre un rilievo di gravità bassa con la lista. È un controllo prudente: segnala solo ciò che il server annuncia esplicitamente. Non invia nessun PUT o DELETE di prova, e se il server non risponde all'OPTIONS o non restituisce quegli header, non c'è rilievo.

Perché è importante

Un sito normale ha bisogno di GET, HEAD, POST e, per CORS, OPTIONS. Il resto sono metodi con una storia. TRACE restituisce la richiesta così com'è arrivata, header compresi; combinato con un'altra falla permette di leggere cookie marcati HttpOnly (l'attacco si chiama Cross-Site Tracing). PUT e DELETE creano, sostituiscono o cancellano risorse: su un server di file mal configurato, un PUT carica un file nella directory pubblica. CONNECT trasforma il server in un proxy. Che siano abilitati non significa che funzionino senza autenticazione, da qui la gravità bassa; ma annunciarli senza usarli è superficie d'attacco gratis.

Come risolvere

• Apache: TraceEnable Off nella configurazione principale (TRACE è attivo di default nelle versioni vecchie). Per il resto, dentro il Directory o Location del tuo sito: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: non implementa TRACE. Per limitare il resto in un blocco location: limit_except GET POST HEAD OPTIONS { deny all; }. Se usi if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, mettilo a livello server.
• IIS: il modulo WebDAV è la causa tipica di PUT e DELETE annunciati. Disinstallalo se non lo usi, e in web.config limita i verbi con requestFiltering/verbs.
• Express e API: se la tua API usa PUT o DELETE con autenticazione, è legittimo che Access-Control-Allow-Methods li elenchi; ciò che non deve fare è elencarli su tutto il sito o usare *. Nel middleware CORS, imposta methods: ['GET', 'POST'] sulle rotte pubbliche e amplia solo dove serve.
• Vercel, Netlify, Cloudflare Pages: non annunciano questi metodi di default. Se il rilievo compare, di solito viene da un header CORS che hai configurato tu con la lista completa.

Verifica che sia risolto

curl -si -X OPTIONS https://tuodominio.it | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://tuodominio.it | head -1

Nel primo, né Allow né Access-Control-Allow-Methods dovrebbero includere TRACE, TRACK, PUT, DELETE o CONNECT sulle rotte pubbliche. Il secondo deve restituire 405 o 403, mai 200 con la tua richiesta riflessa nel corpo.

Domande frequenti

La mia API REST usa PUT e DELETE. Devo toglierli?

No. Quello che conta è che quelle rotte richiedano autenticazione e che l'header CORS non li annunci per tutto il dominio né per qualsiasi origine. Se la scansione punta alla radice della tua API, puoi dare il rilievo di gravità bassa per accettato una volta verificato questo. La configurazione delle origini è esaminata da CORS permissivo.

Access-Control-Allow-Methods elenca metodi, ma senza Allow. È lo stesso?

Non proprio. Allow descrive ciò che il server accetta; l'header CORS descrive ciò che consente alle pagine di altre origini. Si leggono entrambi perché entrambi sono informazione che dai. Cosa significa ogni parte di una risposta CORS lo spiega CORS mal configurato.

Perché OPTIONS non è considerato pericoloso?

Perché è il metodo con cui il browser chiede del CORS prima di certe richieste. Bloccarlo rompe le chiamate tra domini. È innocuo e necessario.