Che cos'è l'intestazione http "X-XSS-Protection"?

Quindi ora sto giocando con HTTP per divertirmi in telnet (cioè semplicemente digitando telnet google.com 80e inserendo GET e POST casuali con diverse intestazioni e simili) ma ho trovato qualcosa che google.com trasmette nelle sue intestazioni che io non lo so.

Ho cercato su http://www.w3.org/Protocols/rfc2616/rfc2616.html e non ho trovato alcuna definizione per questa particolare intestazione http che gocciola google:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

Qualcuno sa cos'è X-XSS-Protection?

X-XSS-Protection è un'intestazione HTTP compresa da Internet Explorer 8 (e versioni più recenti). Questa intestazione consente ai domini di attivare e disattivare il "Filtro XSS" di IE8, impedendo alcune categorie di attacchi XSS. IE8 ha il filtro attivato per impostazione predefinita, ma i server possono spegnere se impostati

   X-XSS-Protection: 0

Vedi anche http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header. aspx

• X-XSS-Protection: 1 : Forza protezione XSS (utile se la protezione XSS è stata disabilitata dall'utente)

• X-XSS-Protection: 0 : Disabilita la protezione XSS

• Il token mode=blockimpedirà al browser (IE8 + e browser Webkit) di eseguire il rendering delle pagine (anziché la sanificazione) se viene rilevato un potenziale attacco di riflessione XSS (= non persistente).

/! \ Warning, mode=blockcrea una vulnerabilità in IE8 ( maggiori informazioni ).

Ulteriori informazioni: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx e http://blog.veracode.com / 2014/03 / linee guida-per-setting-Security-headers /

Questa intestazione di risposta può essere utilizzata per configurare la protezione XSS riflettente integrata di un agente utente. Attualmente, solo Internet Explorer di Microsoft, Google Chrome e Safari (WebKit) supportano questa intestazione.

Internet Explorer 8 includeva una nuova funzionalità per aiutare a prevenire attacchi di scripting tra siti riflessi, noto come Filtro XSS . Questo filtro viene eseguito per impostazione predefinita nelle aree di sicurezza Internet, Affidabile e Limitato. Le pagine della zona Intranet locale possono attivare la protezione utilizzando la stessa intestazione.

Informazioni sull'intestazione che hai pubblicato nella tua domanda,

L'intestazione X-XSS-Protection: 1; mode=blockabilita il filtro XSS. Invece di disinfettare la pagina, quando viene rilevato un attacco XSS, il browser impedirà il rendering della pagina.

Nel marzo del 2010, abbiamo aggiunto al supporto IE8 per un nuovo token nell'intestazione X-XSS-Protection, mode = block.

X-XSS-Protection: 1; mode=block

Quando questo token è presente, se viene rilevato un potenziale attacco XSS Reflection, Internet Explorer impedirà il rendering della pagina. Invece di tentare di disinfettare la pagina per rimuovere chirurgicamente l'attacco XSS, IE visualizzerà solo "#".

Internet Explorer riconosce un possibile attacco di scripting tra siti. Registra l'evento e visualizza un messaggio appropriato per l'utente. L'articolo MSDN descrive come funziona questa intestazione.

Come funziona questo filtro in IE ,

Maggiori informazioni su questo articolo, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

Il filtro XSS funziona come un componente IE8 con visibilità su tutte le richieste / risposte che fluiscono attraverso il browser. Quando il filtro rileva il probabile XSS in una richiesta tra siti, identifica e neuta l'attacco se viene riprodotto nella risposta del server. Agli utenti non vengono presentate domande a cui non sono in grado di rispondere - IE blocca semplicemente l'esecuzione dello script dannoso.

Con il nuovo filtro XSS, gli utenti di IE8 Beta 2 che incontrano un attacco XSS di tipo 1 vedranno una notifica come la seguente:

Notifica di attacco XSS IE8

La pagina è stata modificata e l'attacco XSS è bloccato.

In questo caso, il filtro XSS ha identificato un attacco di scripting tra siti nell'URL. Ha neutralizzato questo attacco quando lo script identificato è stato nuovamente riprodotto nella pagina di risposta. In questo modo, il filtro è efficace senza modificare una richiesta iniziale al server o bloccare un'intera risposta.

L'evento Filtro cross-site scripting viene registrato quando Windows Internet Explorer 8 rileva e mitiga un attacco di cross-site scripting (XSS). Gli attacchi di scripting tra siti si verificano quando un sito Web, generalmente dannoso, inietta (aggiunge) codice JavaScript in richieste altrimenti legittime a un altro sito Web. La richiesta originale è generalmente innocente, come un collegamento a un'altra pagina o uno script CGI (Common Gateway Interface) che fornisce un servizio comune (come un libro degli ospiti). Lo script iniettato generalmente tenta di accedere a informazioni o servizi privilegiati che il secondo sito Web non intende consentire. La risposta o la richiesta generalmente riflette i risultati sul sito Web dannoso. Il filtro XSS, una funzionalità nuova di Internet Explorer 8, rileva JavaScript nelle richieste URL e HTTP POST. Se viene rilevato JavaScript, il filtro XSS cerca prove di riflessione, informazioni che sarebbero restituite al sito Web attaccante se la richiesta di attacco fosse inviata invariata. Se viene rilevato il riflesso, il filtro XSS disinfetta la richiesta originale in modo tale che JavaScript aggiuntivo non possa essere eseguito. Il filtro XSS registra quindi tale azione come evento Filtro script tra siti. L'immagine seguente mostra un esempio di un sito che viene modificato per prevenire un attacco di scripting tra siti.

Fonte: https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Gli sviluppatori Web potrebbero voler disabilitare il filtro per il loro contenuto. Possono farlo impostando un'intestazione HTTP:

X-XSS-Protection: 0

Altro sulle intestazioni di sicurezza in,

• Linee guida per l'impostazione delle intestazioni di sicurezza

• Intestazioni HTTP di sicurezza - X-XSS-PROTECTION

• MDN Docs X-XSS-Protection

Puoi vedere in questo Elenco di utili intestazioni HTTP .

X-XSS-Protection: questa intestazione abilita il filtro XSS (Cross-site scripting) incorporato nei browser web più recenti. Di solito è comunque abilitato di default, quindi il ruolo di questa intestazione è riattivare il filtro per questo particolare sito Web se è stato disabilitato dall'utente. Questa intestazione è supportata in IE 8+ e in Chrome (non sono sicuro di quali versioni). Il filtro anti-XSS è stato aggiunto in Chrome 4. Non è noto se quella versione onorasse questa intestazione.

TL; DR: tutti i siti Web (/ app) ben scritti devono emettere un'intestazione X-XSS-Protection: 0e dimenticare questa funzionalità. Se si desidera disporre di una sicurezza aggiuntiva che possono fornire agenti utente migliori, utilizzare Content-Security-Policyun'intestazione rigorosa .

Risposta lunga:

Intestazione HTTP X-XSS-Protection è una di quelle cose che Microsoft ha introdotto in Internet Explorer 8.0 (MSIE 8) che avrebbe dovuto migliorare la sicurezza dei siti Web scritti in modo errato.

L'idea è quella di applicare una sorta di euristica per provare a rilevare l'attacco XSS riflesso e castrare automaticamente l'attacco.

La parte problematica di questo è "euristica" e "castrazione". L'euristica causa falsi positivi e la sterilizzazione non può essere eseguita in modo sicuro perché provoca effetti collaterali che possono essere utilizzati per implementare attacchi XSS e attacchi DoS su siti Web perfettamente sicuri.

La parte negativa è che se un sito Web non emette l'intestazione, X-XSS-Protectionil browser si comporterà come se l'intestazione X-XSS-Protection: 1fosse stata emessa. La parte peggiore è che questo valore è il valore meno sicuro di tutti i valori possibili per questa intestazione!

Per un determinato sito Web sicuro (ovvero, il sito non presenta vulnerabilità XSS riflesse) questa funzione "Protezione XSS" consente i seguenti attacchi:

X-XSS-Protection: 1consente all'autore dell'attacco di bloccare selettivamente parti di JavaScript e di mantenere in esecuzione gli altri script. Ciò è possibile perché le euristiche di questa funzione sono semplicemente "se il valore di qualsiasi parametro GET viene trovato nella parte di scripting della sorgente della pagina, lo script verrà automaticamente modificato in modo dipendente dall'agente dell'utente". In pratica, l'attaccante può ad esempio aggiungere un parametro disablexss=<script src="framebuster.js"e il browser rimuoverà automaticamente la stringa <script src="framebuster.js"dall'origine della pagina effettiva. Si noti che il resto della pagina continua a essere eseguito e l'attaccante ha appena rimosso questa parte della sicurezza della pagina. In pratica, è possibile modificare qualsiasi JS nell'origine della pagina. In alcuni casi, una pagina senza vulnerabilità XSS con contenuto riflesso può essere utilizzata per eseguire JavaScript selezionato sulla pagina a causa della sterilizzazionetrasformare erroneamente i dati di testo normale in codice JavaScript eseguibile .

X-XSS-Protection: 1; mode=blockconsente all'autore dell'attacco di sottrarre dati dall'origine della pagina utilizzando il comportamento della pagina come canale laterale. Ad esempio, se la pagina contiene codice JavaScript lungo le righe di var csrf_secret="521231347843", l'attaccante aggiunge semplicemente un parametro aggiuntivo, ad esempio, leak=var%20csrf_secret="3e se la pagina NON è bloccata, la 3prima cifra non era corretta. L'attaccante riprova, questa volta leak=var%20csrf_secret="5e il caricamento della pagina verrà interrotto. Ciò consente all'attaccante di sapere che la prima cifra del segreto è 5. L'attaccante continua quindi a indovinare la cifra successiva.

Alla fine, se il tuo sito è pieno di attacchi di riflessione XSS, l'uso del valore predefinito 1ridurrà leggermente la superficie di attacco. Tuttavia, se il tuo sito è sicuro e non emetti X-XSS-Protection: 0, il tuo sito sarà vulnerabile con qualsiasi browser che supporti questa funzione. Se desideri una difesa approfondita da parte dei browser contro vulnerabilità XSS ancora sconosciute sul tuo sito, utilizza Content-Security-Policyun'intestazione rigorosa . Ciò non apre il tuo sito a vulnerabilità note.

Attualmente questa funzione è abilitata per impostazione predefinita in MSIE, Safari e Google Chrome. Questo era abilitato in Edge ma Microsoft ha già rimosso questa funzionalità errata da Edge . Mozilla Firefox non l'ha mai implementato.

Guarda anche:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https: // bugs.chromium.org/p/chromium/issues/detail?id=498982