Il metodo TRACE HTTP è una vulnerabilità di sicurezza?

32

Ho visto molti post qui su questo sito per dare consigli su come disattivare il metodo HTTP TRACE per impedire cross site tracing . Ho cercato di fare la stessa cosa. Ma quando leggo la documentazione di Apache , dà il consiglio contrario:

Note

Despite claims to the contrary, TRACE is not a security vulnerability and there is no viable reason for it to be disabled. Doing so necessarily makes your server non-compliant.

Quale dovrei seguire?

    
posta Question Overflow 30.04.2014 - 11:46
fonte

3 risposte

26

Uno dei principi di sicurezza più seri dice che ciò che è inutilizzato dovrebbe essere disabilitato.

Quindi le prime domande sono: Lo userai davvero? Hai bisogno che sia abilitato?

Se non utilizzerai il metodo TRACE , a mio parere dovrebbe essere spento. Impedirà la tua app non solo contro XST , ma anche contro le vulnerabilità non ancora scoperte relative a questo canale, che possono essere trovate in futuro.

    
risposta data 30.04.2014 - 15:37
fonte
20

Per inviare un comando TRACE a un determinato server, devi avere il diritto di farlo, che viene normalmente impedito da Politica Same-Origin (il famoso" SOP "). Se un pezzo di codice JavaScript dannoso, intento a rubare il tuo cookie sul sito example.com , è in grado di inviare una richiesta di TRACE a example.com , allora quel malvagio JavaScript ha già vinto e sei nei guai più profondi. Disabilitare TRACE non risolve il problema reale (e tale problema è lato client).

Per fare un'analogia scandalosa: ci sono persone che uccidono gli altri pugnalandoli con coltelli. Mettere al bando i coltelli risolverà davvero il problema? (Sto usando coltelli e non pistole qui, perché è abbastanza ovvio che i coltelli sono strumenti molto utili per compiti diversi dall'assassinare persone, ad esempio uso quotidianamente i coltelli per cucinare, lo stesso non si può dire delle pistole. Il metodoTRACE è uno strumento utile per il debug.)

    
risposta data 30.04.2014 - 13:26
fonte
12

Which should I follow?

Scansionerai il tuo sito web, cosa ... Annualmente? Trimestrale? Mensile, settimanale? E questo apparirà su tutte quelle scansioni. Fino a quando non dirai al tuo scanner di saltare quel controllo, o di fare un'eccezione ... a quel punto rimarrà lì fino a quando una terza parte non eseguirà una scansione per te, o uno dei tuoi partner analizzerà il tuo sito e lo metterà sotto il tuo naso come "Come puoi lasciare una tale lista di controllo di base senza indirizzo?

Al contrario, verrai sottoposto a scansione per la conformità alle specifiche HTTP ... mai. Avrai bisogno di usare effettivamente TRACE ... praticamente mai. L'effetto pratico sull'interoperabilità con i tuoi clienti sarà ... nada.

Comprendo e concordo con @ Tom-Leek che non è un problema di sicurezza. Tuttavia, non sono d'accordo sul fatto che il lato negativo della disattivazione è minuscolo, e il lato positivo della disattivazione è di evitare un sacco di fastidio che altrimenti finirebbe nelle tue gambe.

Non sono l'unico a pensare in questo modo - ecco perché Apache ha aggiunto una direttiva in 1.3.34 e 2.0.55 per disattivare semplicemente TRACE:

TraceEnable Off

Ecco un buona pagina che lo discute , inclusi i passaggi di prova manuali.

    
risposta data 30.04.2014 - 15:13
fonte

Leggi altre domande sui tag