XSS ha raggiunto la fine del ciclo di vita con l'introduzione dell'intestazione HTTP X-XSS-Protection?

8

Con l'introduzione dell'intestazione X-XSS-Protection HTTP mi sembra che l'impatto sulla vulnerabilità (leggi: quantità di utenti potenzialmente interessati con i browser moderni) sia drasticamente ridotto.

In primo luogo, questo significa che quando l'intestazione X-XSS-Protection è impostata correttamente e che quando la protezione XSS del browser è abilitata, gli sviluppatori web non devono più preoccuparsi di XSS (almeno per i visitatori con browser moderni) ? Che potrebbe essere semplice come "Non supportiamo i browser X, X e X e le versioni X e precedenti.".

In secondo luogo, quali browser (popolari) hanno implementato questa funzione di sicurezza, è abilitata per impostazione predefinita e da quale versione o in quale data è stata rilasciata quella versione?

In terzo luogo, esistono bypass noti del filtro XSS di quel browser?

    
posta Bob Ortiz 25.06.2016 - 18:45
fonte

2 risposte

19

Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header?

No. X-XSS-Protection viene utilizzato solo per abilitare o disabilitare il filtro incorporato [*], che in genere è comunque abilitato per impostazione predefinita.

Quindi una domanda più appropriata sarebbe se l'XSS raggiungesse la fine del suo ciclo di vita con i filtri del browser.

Ma di nuovo, la risposta è no. XSS è ancora un pericolo, per tre motivi:

  • XSS persistente non è influenzato dal filtro del browser, poiché il browser non ha modo di sapere cosa è l'input dell'utente e cosa no.
  • Alcuni browser non hanno filtri contro XSS , ad esempio Firefox. Le vulnerabilità XSS vengono introdotte sul lato server e gli sviluppatori web non devono fare affidamento sui venditori di browser che difendono contro di loro.
  • Ignorare i filtri del browser : XSS è sensibile al contesto, il che rende molto difficile difendersi senza conoscere il contesto (che è anche il motivo per cui l'XSS deve essere difeso quando si esportano i dati, non tramite un filtro di input generico).

Il bypass può praticamente accadere per due motivi:

  1. C'è un bug nel filtro.
  2. L'input dell'utente viene ripetuto in una posizione in cui il filtraggio non è pratico. Un esempio potrebbe essere <script>[userinput]</script> .

[*] Poiché l'intestazione non è definita in nessun RFC, è difficile dire come reagiranno i browser. Ad esempio, Chrome 51 disattiverà il filtro se l'intestazione è impostata su 0, ma non riattiverà il filtro nel caso in cui l'utente lo disabiliti se 1 è impostato. Altri browser potrebbero comportarsi diversamente.

Which could be as simple as "We don't support browsers X, X and X and versions X and lower.".

Non è davvero così semplice. Soprattutto le grandi organizzazioni sono notoriamente pessime in fase di aggiornamento. A seconda del tuo sito web, non puoi semplicemente dire che non supporti i browser X.

Secondly, what (popular) browsers implemented this security feature, is it enabled by default, and since what version or on what date was that version released?

X-XSS-Protection è supportato da IE, Chrome e Safari .

Chrome aveva un filtro XSS dal 2010 (Chrome 4) . Era disattivato per impostazione predefinita nello stesso anno e poi riattivato in Chrome 8.

IE aveva un filtro XSS since 2008 (IE 8) .

Firefox non ha un filtro , il plugin NoScript però.

Thirdly, are there known bypasses of that browsers XSS filter?

. Naturalmente . Ci sono più. La maggior parte dipende da una situazione specifica (ad esempio, l'input viene riprodotto in due posizioni). Il filtro IE8 in realtà ha introdotto una vulnerabilità XSS , anche in siti che non ne contenevano uno.

    
risposta data 25.06.2016 - 19:01
fonte
0

In realtà, anche se quell'intestazione potrebbe risolvere il problema , la seconda parte è un fattore umano: gli hosters / sviluppatori / webmaster stanno per usarlo, in realtà ...

    
risposta data 25.06.2016 - 19:25
fonte

Leggi altre domande sui tag