Permettere che uno script non sicuro incorpori lo scopo del CSP?

Question

Permettere che uno script non sicuro incorpori lo scopo del CSP?

#1 da (6 voti)
#2 da (0 voti)

3

Sto rivedendo le intestazioni di Content-Security-Policy impostate in uno dei nostri server Web e vedo che questo è come viene impostato (dove 'example.com' è il nostro sito Web attendibile).

Content-Security-Policy: "default-src 'self'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval'; img-src 'self' *.example.com; font-src *; connect-src 'self' *example.com"

Le mie domande sono:

1) Non supplirà il tipo unsafe-inline e unsafe-eval di sconfiggere l'intero CSP?

2) Se l'opzione "non sicuro" è consentita o autorizzata come sopra, qualcuno può chiamare un JavaScript da un sito Web esterno, ad esempio www.xxxxxx.com che non è autorizzato nella direttiva script-src e lì sconfiggere l'intero scopo del CSP? Es: <script src="www.xxxxxx.com/bad.js">

Ho esaminato questa domanda qui e passando per le risposte, sembra che il CSP sopra sia non buono.

content-security-policy

posta Sree 20.11.2018 - 12:16

fonte

2 risposte

Leggi altre domande sui tag content-security-policy

Tracciamento di un utente che ha pubblicato messaggi offensivi Dove è la sicurezza quando un gateway di pagamento lascia che il sito gestisca i dettagli della carta di credito

score 6 · Answer 1

Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP?

Sì. Un CSP limitato renderà più difficile sfruttare XSS limitando gli script che possono essere eseguiti. Usando in-safe e non sicuro-eval consente di eseguire qualsiasi script. Questo è anche il motivo per cui sono prefissati da unsafe- , per scoraggiarti dal loro utilizzo nel CSP.

Ovviamente i dati: il protocollo consente anche di aggirare il CSP, dato che puoi codificare qualsiasi script come dato: URL.

If 'unsafe-inline' is allowed or whitelisted as above, can someone call a JavaScript from an external website

È possibile recuperare il contenuto dello script ed eseguirli da JavaScript. Includerlo con <script src="www.xxxxxx.com/bad.js"> non funziona, ma dal momento che è possibile eseguire JavaScript comunque ci sono altri modi per eseguire script esterni.

score 0 · Answer 2

Sjoerd ha spiegato quali sono (a mio parere) i punti principali su questo argomento, ma vorrei aggiungere che consentire JavaScript inline non rende completamente inutile CSP qui. C'è ancora motivo di usare una politica di sicurezza dei contenuti ben scritta, al di fuori dei confini di evitare XSS.

Come tutti sappiamo, CSP è uno strumento estremamente potente. Mentre la maggior parte del suo potere risiede nel rendere più facile la difesa da XSS e dai suoi amici, ha anche un certo numero di funzionalità che rimangono preziose anche dopo aver disattivato le funzionalità specifiche dell'XSS e aver aperto quel vettore. Questi includono:

Funzionalità tangenziali per evitare XSS, come la direttiva sandbox
Funzioni indipendenti, come la direttiva upgrade-insecure-requests
Supporto di funzionalità che possono essere sfruttate a fondo da sole, come ad esempio le capacità di reporting

Nel caso in cui sia utile, Mozilla ha un'eccellente descrizione delle funzioni di CSP qui .