No, perché il filtro XSS guarda solo se vede il codice XSS nell'input nell'HTML emesso dal tuo server.
Ad esempio, se Chrome visualizza la tua pagina web con un URL che contiene quanto segue:
?q=<script>alert("XSS!")</script>
e se l'HTML restituito dal server contiene questo:
<p>You have searched for <b><script>alert("XSS!")</script>
sa che questo codice è molto probabilmente il risultato della sua inclusione nella richiesta e lo neutralizza.
Tuttavia, se il codice non viene trovato nella richiesta, ad esempio se l'applicazione accetta un input codificato in qualche modo, il filtro potrebbe non essere in grado di capire che il codice è il risultato di qualche codice XSS incorporato in la richiesta.
Come si vede nel registro di commit per WebKit, fino a quando non è stato biforcato di recente con il motore di rendering in Chrome, stanno cercando di risolvere i bypass più comuni, in cui il codice XSS nell'URL e il codice XSS risultante in HTML sembrano leggermente diversi.
Se non si applica nessuna di queste regole per casi speciali, l'XSS verrà lasciato vuoto. Ad esempio, se non stanno decodificando i dati codificati Base64 nell'URL, se l'applicazione Web dovesse accettare input codificati con Base64, potrebbe essere possibile XSS un'applicazione web.
Un esempio:
?q=PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+
( PHNjcmlwdD5hbGVydCgnWFNTIScpPC9zY3JpcHQ+
è <script>alert("XSS!")</script>
codificato in Base-64), se non filtrato, darebbe come risultato una risposta HTML come questa:
<p>You have searched for <b><script>alert("XSS!")</script>
Inoltre, non fermerà l'XSS che si verifica con dati non incorporati nell'HTML non codificati, ma viene trattato in modo non sicuro da JavaScript.
Ad esempio, considera una pagina che contiene il seguente codice JavaScript:
eval(location.hash.substring(1))
Questo eseguirà qualsiasi codice che trascini il #
nell'URL, ma non filtrato da Chrome.
↪ Puoi vedere questo esempio in azione qui
↪ Un altro esempio, che utilizza Base64