Quando si eseguono scansioni di vulnerabilità utilizzando Nessus, contro un host che esegue Apache, un risultato previsto è sempre "metodi HTTP TRACE / TRACK consentiti". Mentre questo risultato ha solo un CVSS di base di 4.3, consiglio sempre di correggerlo. La correzione è abbastanza facile che non ho mai ricevuto il respingimento.
Quali sono le implicazioni della vita reale di lasciare qualcosa di simile aperto?
Il metodo HTTP TRACE risponde sostanzialmente alla richiesta, insieme a tutte le intestazioni in risposta. L'intestazione cookie sarà inclusa nella risposta. I cookie di sessione devono avere link flag per impedire Session Hijacking . Questo flag blocca l'accesso al valore del cookie da Javascript. Fondamentalmente questo assicura che anche se l'attaccante sfrutta un difetto XSS in un sito web, non conoscerà il valore del cookie di sessione, quindi non può dirottarlo.
Ma se un server di applicazioni web ha TRACE abilitato, l'autore dell'attacco può semplicemente inviare ad es. XMLHttprequest (AJAX) al server di destinazione. Il browser allegherà i cookie alla richiesta, il server li rispedirà in risposta e il codice JS dell'attaccante riceverà la risposta e sarà in grado di dirottare la sessione.
La vulnerabilità si chiama Traccia sito trasversale ed è stata descritta in questo white paper .
Tuttavia, dal 2003, quando questa vulnerabilità è stata scoperta, molti browser semplicemente non consentono l'invio di richieste con il metodo TRACE. Anche la specifica per XMLHttpRequest non consente il metodo TRACE ora. Non ho alcun risultato concreto su quale browser sia possibile inviare TRACE in questo momento, la corrispondenza più vicina che ho trovato è questo articolo .
Tuttavia, probabilmente ci sono alcuni vecchi browser in giro e altri plugin come Flash, Silverlight, Java che spesso ricevono cookie dal browser e potrebbero usarli per inviare TRACE. Quindi disabilitarlo ora è l'unica opzione per essere sicuri di non essere vulnerabili a Cross Site Tracing. Ed è anche facile: basta usare TraceEnable off in Apache .
JavaScript può usarlo per accedere alle intestazioni delle richieste http. Questo consente
Questi attacchi sono soggetti allo stesso criterio di origine, ma in combinazione con gli exploit SOP in Java, Flash, ActiveX, Vbscript, possono essere applicati a qualsiasi dominio.
C'è un buon whitepaper su questo argomento.
tldr : non è sfruttabile da solo, ma rappresenta un rischio in combinazione con altre vulnerabilità.
Leggi altre domande sui tag apache web-application hardening known-vulnerabilities