2013-07-22 11 views
9

Sto scrivendo un'estensione chrome che deve avere due domini nella sua lista bianca per la politica di sicurezza del contenuto. Ho esaminato i documenti ufficiali, ma non riesco ancora a capire la sintassi corretta.Whitelist domini multipli nella politica di sicurezza del contenuto

Quanto segue non sembra funzionare:

"content_security_policy": "script-src 'self' https://foo.com https://example.com; object-src 'self'" 

EDIT:

Sia il mio script di contenuti e il mio pop-up sono in grado di raggiungere foo.com, tuttavia, nessuno dei due può raggiungere example.com .

Le estensioni di Chrome sono in grado di avere più fonti autorizzate nel CSP?

+0

Gli script di contenuto non sono interessati dal CSP dell'estensione, ma da quelli della pagina. –

+0

Modificato ampiamente la mia risposta; per favore verifica che la mia estensione di esempio funzioni per te e che tu non stia eseguendo nessuno degli errori che dettagliamo nella mia risposta. – apsillers

+0

Stai effettivamente cercando di raggiungere 'esempio.com'? L'attuale 'https: // example.com' ha due problemi: in primo luogo, reindirizza a' https: // example.iana.org/', e in secondo luogo, usa un certificato non appropriato per il suo dominio, causando il blocco di Chrome esso. (Sicuramente ottieni una schermata di avviso quando digiti l'URL. Non sono sicuro di come gestisca le richieste di risorse di script, ma suppongo che li blocchi.) – apsillers

risposta

10

Da quello che so sui CSP, questo sembra sintatticamente corretto. Il HTML5 Rocks article on CSP concorda con la sintassi, dicendo:

script-src https://host1.com https://host2.com sarebbe correttamente specificare entrambe le origini come valida.

Tuttavia, il problema potrebbe essere che sia:

  1. Questo CSP disallows all subdomains, tra cui www.foo.com e www.example.com. È possibile aggiungere questi nomi di host sottodominio in modo esplicito oppure è possibile utilizzare https://*.foo.com per consentire tutti i sottodomini.

  2. Se uno qualsiasi dei tuoi script richiede il reindirizzamento a un dominio non consentito, la richiesta avrà esito negativo. Per esempio, se https://example.com/foo.js risponde con un 301 o 302 reindirizzamento a https://notpermitted.com/foo.js (di origine non-permesso) oppure https://www.example.com/foo.js (non consentito sottodominio), la richiesta avrà esito negativo according to the spec:

    Ogni volta che l'utente agente recupera un URI (anche quando a seguito reindirizza) ... se l'URI non corrisponde alle fonti di script consentiti, il programma utente deve agire come se avesse ricevuto una risposta vuota HTTP 400 ...

MODIFICA:

Giusto per confermare, sì, le estensioni di Chrome possono autorizzare più origini HTTPS. Si può costruire un semplice estensione per testare questo:

manifest.json

{ 
    "name":"CSP Test", 
    "version":"1.0", 
    "manifest_version":2, 
    "browser_action":{ 
     "default_popup":"csp_test.html" 
    }, 
    "content_security_policy": "script-src 'self' https://www.iana.org https://ajax.googleapis.com; object-src 'self'" 
} 

csp_test.html

<script src="https://www.iana.org/_js/2013.1/jquery.js"></script> 
<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.10.3/jquery-ui.min.js"></script> 
<script src="csp_test.js"></script> 

csp_test.js

alert(jQuery) 
alert(jQuery.ui) 

Questa estensione carica jQuery e jQuery UI da domini remoti.Se rimuovi l'origine dal CSP, verrà visualizzato un avviso "undefined" a indicare che una delle librerie non è stata caricata.

+0

Grazie mille per tutto l'aiuto. Il dominio che stavo cercando di contattare aveva alcune regole di reindirizzamento strani che applicavano HTTP in determinate condizioni. –

+0

risposta molto perspicace! – fegemo

Problemi correlati