However, it would still be possible to alter the data on the screen in
unexpected ways, and possible to create a convincing Phishing scam by
providing a link out to another website.
Is this accurate, or are out-links prohibitable also?
Sì, è corretto con un avvertimento: le persone sul tuo sito eseguono browser moderni. Per questo motivo esatto, il mio team considera XSS senza un'iniezione del contenuto reale (ad esempio l'inserimento in un contesto di attributo tag non quotato) come priorità inferiore rispetto a un bug di injection content stesso a causa di CSP. Abbiamo la fortuna di non avere praticamente utenti sui browser che non supportano alcuna forma di strong CSP .
What is the scope of a would-be XSS attack with the presence of a
tight CSP?
Perdonami qui se questo sembra soapbox, ma la tua domanda non definisce "CSP stretto", quindi lascia che elabori alcune cose che molti trascurano.
Per ragioni, diciamo che questo è un criterio che viene proposto (interruzioni di linea aggiunte per chiarezza, questa non è un'intestazione valida):
Content-Security-Policy:
default-src 'self';
img-src https: data:;
connect-src paypal.com api.example.com;
script-src 'self' ajax.googleapis.com;
style-src 'self' 'unsafe-inline'
Nota : rimuovere unsafe-inline da style-src non è pratico oggi.
Questa è una politica piuttosto buona con alcuni difetti evidenti e non così ovvi, ma non è consentito lo script inline. Ci sono molti altri accorgimenti da considerare con CSP, non si tratta solo di disabilitare eval e script inline (yes javascript: e on* gestori di eventi sono inclusi).
Blocco di terze parti per limitare effettivamente XSS
Esistono ancora molti altri vettori
Il viaggio CSP di GitHub contiene molti punti su come la politica è stata regolata per prevenire determinati attacchi.
È possibile abusare del tutto di seguito con la politica proposta.
- Rimozione di
'self' da script-src per impedire XSS tramite JSONP
- Esaminare i token CSRF tramite i tag
img e form
- Spostare file flash ospitati su un'origine diversa anziché
'self' perché il flash rovina tutto.
- Utilizzo di criteri dinamici per impedire l'uso inaspettato di API che devono essere utilizzate solo da un insieme specifico di pagine.
- Limitazione dell'uso di
'self' per frame-src / child-src
- Abuso del tag
base .
A volte, CSP non è applicabile.
È possibile aggirare completamente il CSP. Vedi Scorrimento del tipo di contenuto PDF per un esempio in cui i dati controllati dall'utente su una pagina possono davvero rovinare tutto.
Non c'è letteralmente nulla che possiamo fare a riguardo dal punto di vista di CSP.
E a volte Internet ti fa piangere
Vedi Rubare la torta senza toccare il davanzale dove i CSS possono essere usati per rubare e esfiltrare i dati su una pagina senza javascript.
Poiché la rimozione di 'unsafe-inline' non è pratica, questo attacco è possibile. Tuttavia, questo attacco è difficile da eseguire.