È possibile impedire XSS 100% impostando la politica di sicurezza del contenuto come default-src 'self' ? C'è un modo in cui l'XSS può accadere in quel caso? Una possibilità che posso pensare è di iniettare input dell'utente in uno dei tuoi script dinamicamente sul lato server, sei d'accordo? Ci sono altre vulnerabilità a cui puoi pensare?
CSP in tale configurazione dovrebbe abilitare le seguenti misure di sicurezza:
Come tale, XSS dovrebbe essere possibile solo nei casi in cui le risorse sul dominio possono essere controllate da un utente malintenzionato, come lei ha menzionato.
È possibile bloccare ulteriormente CSP impostando default-src 'none' , quindi abilitando esplicitamente solo i tipi di contenuto che si prevede di utilizzare sul sito. Ciò aiuta a ridurre ulteriormente la superficie di attacco disattivando tipi di contenuto come Flash, applet Java, SVG, canvas, ecc. Quando non li stai utilizzando.
Un vettore aggiuntivo che potresti non aver considerato è Sostituzioni del foglio di stile relativo al percorso (PRSSI) , altrimenti note come vulnerabilità relative al Path Overwrite (RPO). Questi funzionano sfruttando il comportamento di gestione degli URL in alcuni software CMS, in cui i caratteri del percorso vengono visualizzati dopo che uno script è stato preso come parametri (ad esempio example.com/wiki/index.php/Something mostra la pagina Something ). Quando viene incluso un foglio di stile relativo al percorso (ad esempio main.css anziché /main.css ), questo può a volte essere abusato. Nel nostro esempio, poiché main.css è importato rispetto al percorso corrente, un'inclusione nell'URL di esempio sopra farà sì che il browser provi a caricare example.com/wiki/index.php/main.css come foglio di stile. Se è possibile creare una pagina wiki denominata main.css , ciò consentirebbe di controllare il contenuto di tale foglio di stile e caricare potenzialmente CSS dannoso (ad esempio con la direttiva expression ). Puoi fare la stessa cosa con le importazioni JavaScript relative ai percorsi. La correzione qui è di fare sempre riferimento al contenuto tramite il suo percorso canonico completo.
default-src 'self' consente XSS tramite JSONP e attacchi di sniffing di tipo contenuto:
Of particular note is our lack of self in our source list. While sourcing JavaScript from self seems relatively safe (and extremely common), it should be avoided when possible.
There are edge cases that any developer must concern themselves with when allowing self as a source for scripts. There may be a forgotten JSONP endpoint that doesn’t sanitize the callback function name. Or, another endpoint that serves user-influenced content with a content-type that could be sniffed by browsers as JavaScript. GitHub has several such endpoints. For example, we return commit diffs as text/plain.
Leggi altre domande sui tag javascript xss content-security-policy