CSP XSS

I CSP indeboliscono gli attacchi cross-site scripting (XSS) impedendo l'inserimento di script dannosi da parte degli eventuali aggressori.

Security

Impossibile trovare CSP in modalità di esecuzione

Perché si dovrebbe includere un CSP (Content Security Policy) nelle proprie pagine web? Facendolo si può essere certi che qualsiasi contenuto caricato sulla pagina sia attendibile. 

I CSP indeboliscono gli attacchi cross-site scripting (XSS) impedendo l'inserimento di script dannosi da parte degli aggressori. Il CSP, tuttavia, può essere aggirato senza troppi problemi se non è scritto in modo rigoroso. 

Se non viene trovato alcun CSP in modalità di esecuzione , SeoChecker lo notificherà:

Se vuoi essere sicuro che il tuo CSP non sia bypassabile, segui queste pratiche:

• CSP targets XSS

Un CSP deve essere privo di errori di sintassi e dovrebbe includere le direttive script-src, object-src e base-uri per poter colpire gli XSS.

script-src ha lo scopo di proteggere la pagina da script non sicuri, mentre l'object-src la protegge da plugin non sicuri. Se si vuole configurare un'impostazione più generica e meno specifica, si può usare  default-src.

base-uri invece impedisce l'iniezione di tag <base> non autorizzati: questi possono essere utilizzati dagli aggressori per reindirizzare tutti gli URL correlati (come gli script) ai loro domini.

• Per evitare Allowlist Bypass, CSP utilizza nonces o hash

Quando un CSP configura un allowlist script-src significa che ritiene che tutte le risposte provenienti da un dominio attendibile siano sicure e quindi eseguibili come script. Questo presupposto, tuttavia, non è così ovvio per le applicazioni moderne: di solito esistono pattern comuni e innocui che possono essere utilizzati dagli aggressori per aggirare il CSP.

Pertanto, un malintenzionato può aggirare la maggior parte delle script-src allowlist con un bug XSS; inoltre, le allowlist non garantiscono una reale protezione contro le injection di script. Una soluzione è offerta dagli approcci basati su nonce e hash.

Date un'occhiata a questo codice che utilizza un endpoint JSONP hostato su un dominio affidabile al fine di iniettare uno script comandato da un utente malintenzionato:

CSP:

script-src https://trusted.example.com

HTML

<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script> 

Per questo, è opportuno che il CSP utilizzi "strict-dynamic" e che autorizzi gli script uno per uno tramite nonces o hash.

Oltre a quelle già citate, esistono altre raccomandazioni:

• Monitorare le anomalie configurando un'area di destinazione dei report. Utilizzare le direttive report-uri o report-to.
• Se è possibile, definire unCSP in un'intestazione di risposta  HTTP:

<meta http-equiv="Content-Security-Policy" content="script-src 'none'">

• Considerato che nonces e hash, così come strict-dynamic, non sono supportati da tutti i browser, si dovrebbero aggiungere unsafe-inline e un allowlist come fallback.

Esempi di CSP rigorosi

CSP rigoroso con policy nonce-based :

CSP:

script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;

object-src 'none';

base-uri 'none';

report-uri https://reporting.example.com;

HTML:

<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>