it-swarm-eu.dev

Chrome è completamente sicuro contro Reflected XSS?

Ho notato che Chrome non esegue script che fanno parte della richiesta web,

http://vulnerable_site?pageTitle=<script>alert('xss')</script>

Con tali collegamenti poiché lo script fa parte della richiesta Web, Chrome non esegue lo script. Ciò impedisce tutti i tipi di attacchi Reflected XSS con Chrome browser?

Modifica: Ho già letto questo thread; sebbene il titolo sembri simile, i contenuti sono diversi.

20
vikkyhacks

No, perché il filtro XSS sembra solo se vede il codice XSS nell'input indietro nell'HTML emesso dal tuo server.

Ad esempio, se Chrome vede l'accesso alla 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 è 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 input codificato in qualche modo, il filtro potrebbe non essere in grado di capire che il codice è il risultato di un codice XSS incorporato nella richiesta.

Come visto nel commit commit per WebKit, fino a quando non è stato recentemente biforcuto il motore di rendering in Chrome, stanno cercando di risolvere i bypass più comuni, in cui il codice XSS nell'URL e il risultante XSS- il codice nell'HTML appare leggermente diverso.

Se nessuna di queste regole viene applicata per casi speciali, l'XSS verrà lasciato in sospeso. Ad esempio, se non stanno decodificando i dati con codifica 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, si tradurrebbe in HTML di risposta in questo modo:

<p>You have searched for <b><script>alert("XSS!")</script>

Inoltre, non impedirà che XSS si verifichi con dati non incorporati nell'HTML non codificati, ma trattati in modo non sicuro da JavaScript.

Ad esempio, considera una pagina che contiene il seguente JavaScript:

eval(location.hash.substring(1))

Questo eseguirà qualsiasi codice che segue # Nell'URL, ma non viene filtrato da Chrome.

Puoi vedere questo esempio in azione qui

n altro esempio, che utilizza Base64

23
user2428118

La prevenzione XSS non è responsabilità del browser, sorgono buchi XSS a causa di difetti in un sito Web e spetta ai proprietari dei siti Web prevenire tali difetti.

Alcuni browser hanno implementato tentativi di mitigare i buchi XSS e CSRF nei siti Web, ma si tratta di euristiche che cercano schemi tipici di attacchi. Non sono in alcun modo completi.

Esistono infiniti modi per implementare un foro XSS e non esiste un modo sicuro per distinguere tra un foro e il comportamento previsto. Non è possibile che un filtro browser possa mai essere un sostituto per i proprietari di siti che conoscono, si occupano e affrontano il problema dei buchi XSS e CSRF.

Mi chiedo se questi filtri facciano più male che bene creando un falso senso di sicurezza.

12
aaaaaaaaaaaa

Come notato su Chrome bug 118808 di uno sviluppatore:

I bypass del revisore XSS non costituiscono Chrome vulnerabilità di sicurezza (motivo per cui questo bug è contrassegnato come SecSeverity-None). Puoi trovare le nostre linee guida per la gravità qui: http: // dev. chromium.org/developers/severity-guidelines

Per chiarire un po 'di più, il revisore XSS è un meccanismo di difesa approfondito per proteggere i nostri utenti da alcune comuni vulnerabilità XSS nei siti Web. Sappiamo per certo che non può catturare tutte le possibili varianti XSS, e quelle che cattura devono ancora essere riparate sul sito interessato. Quindi, il revisore è davvero una rete di sicurezza aggiuntiva per i nostri utenti, ma non è inteso come un forte meccanismo di sicurezza.

che mostra come il Chrome stesso non si aspetta che sia completamente sicuro (il che è probabilmente impossibile).

2
Ángel

No. Vedi questo commit Webkit e trova la parola "bypass". Vedrai bypassare Auditor che i ricercatori hanno trovato nel periodo di tempo ...

2
user36484