Criteri di sicurezza del contenuto

Mike West

Joe Medley

Il modello di sicurezza del web è radicato nella criteri della stessa origine Codice da https://mybank.com dovrebbe avere accesso soltanto all'account di https://mybank.com e l'accesso ai dati https://evil.example.com non dovrebbe essere mai consentito. Ogni origine è isolata dal resto del web, per offrire agli sviluppatori una sandbox in cui creare e giocare. In teoria, questo è perfettamente geniale. Nella gli aggressori hanno trovato modi intelligenti per sovvertire il sistema.

Cross-site scripting (XSS) attacchi, ad esempio, aggirano la stessa policy di origine con l'inganno di un sito consegnare codice dannoso insieme al contenuto previsto. È una grande opportunità perché i browser considerano il codice visualizzato su una pagina come se fosse legittimamente parte dell'origine della sicurezza della pagina. La Scheda di riferimento di XSS è un vecchio ma rappresentativo schema dei metodi che un aggressore potrebbe usare per violare tale fiducia mediante l'iniezione di codice dannoso. Se un utente malintenzionato riesce inietta qualsiasi codice, si tratta praticamente di game over: i dati delle sessioni utente compromessa e le informazioni che dovrebbero essere mantenute segrete vengono esfiltrate su The Bad Ragazzi. Ovviamente vorremmo evitare che ciò accada.

Questa panoramica evidenzia una difesa che può ridurre significativamente i rischi e impatto degli attacchi XSS nei browser moderni: Content Security Policy (CSP).

TL;DR

• Utilizza le liste consentite per indicare al client cosa è consentito e cosa non lo è.
• Scopri quali istruzioni sono disponibili.
• Scopri le parole chiave che utilizzano.
• Il codice in linea e eval() sono considerati dannosi.
• Segnala le violazioni delle norme al server prima di applicarle.

Liste consentite di origine

Il problema sfruttato dagli attacchi XSS è l'incapacità del browser di distinguere tra lo script che fa parte della tua applicazione e lo script che è stato iniettati dolosamente da una terza parte. Ad esempio, il pulsante +1 di Google nel in fondo a questa pagina carica ed esegue il codice https://apis.google.com/js/plusone.js nel contesto dell'origine di questa pagina. Me fidarsi di quel codice, ma non possiamo aspettarci che il browser lo individui da solo di apis.google.com è fantastico, mentre il codice di apis.evil.example.com probabilmente non lo è. Il browser scarica ed esegue felicemente qualsiasi codice di una pagina. richieste, indipendentemente dall'origine.

Invece di fidarsi ciecamente di tutto ciò che viene fornito da un server, CSP definisce Content-Security-Policy che consente di creare una lista consentita di da fonti di contenuti attendibili e indica al browser di eseguire o visualizzare solo da quelle origini. Anche se un aggressore riesce a trovare un buco attraverso il quale per inserire lo script, quest'ultimo non corrisponderà alla lista consentita e pertanto non sarà eseguito.

Poiché confidiamo nel fatto che apis.google.com fornisca un codice valido, Per fare lo stesso, definiamo un criterio che consenta l'esecuzione dello script solo provengono da una delle due origini seguenti:

Content-Security-Policy: script-src 'self' https://apis.google.com

Semplice, vero? Come avrai intuito, script-src è un'istruzione che controlla un insieme di privilegi relativi agli script per una pagina specifica. Abbiamo specificato 'self' come origine valida dello script e https://apis.google.com come un'altra. Il browser scarica regolarmente JavaScript ed esegue apis.google.com tramite HTTPS, nonché dall'origine della pagina corrente.

Con questo criterio definito, il browser genera semplicemente un errore invece di di caricamento dello script da qualsiasi altra origine. Quando un aggressore intelligente riesce a inserire il codice nel sito, verranno visualizzate a capofitto in un messaggio di errore anziché del successo che si aspettavano.

I criteri si applicano a un'ampia varietà di risorse

Sebbene le risorse per gli script siano i rischi per la sicurezza più evidenti, CSP fornisce una ricca insieme di direttive politiche che consentono un controllo abbastanza granulare sulle che una pagina possa essere caricata. Hai già visto script-src, quindi il concetto dovrebbe essere chiaro.

Analizziamo rapidamente le altre istruzioni relative alle risorse. Di seguito è riportato un elenco rappresenta lo stato delle direttive a partire dal livello 2. È stata pubblicata una specifica di livello 3, che però è in gran parte non implementata nella browser.

• base-uri limita gli URL che possono essere visualizzati nell'elemento <base> di una pagina.
• In child-src sono elencati gli URL dei worker e i contenuti del frame incorporato. Per esempio: child-src https://youtube.com consente di incorporare video da YouTube, ma non da altre origini.
• connect-src limita le origini a cui puoi connetterti (tramite XHR, WebSockets ed EventSource).
• font-src specifica le origini che possono pubblicare caratteri web. Web di Google i caratteri possono essere attivati tramite font-src https://themes.googleusercontent.com.
• form-action elenca gli endpoint validi per l'invio dai tag <form>.
• frame-ancestors specifica le fonti che possono incorporare la pagina corrente. Questa istruzione si applica ai tag <frame>, <iframe>, <embed> e <applet>. Questa istruzione non può essere utilizzata nei tag <meta> e si applica solo a elementi non HTML Google Cloud.
• frame-src è stato deprecato nel livello 2, ma è stato ripristinato nel livello 3. In caso contrario presente, torna a child-src come prima.
• img-src definisce le origini da cui è possibile caricare le immagini.
• media-src limita le origini consentite per la pubblicazione di video e audio.
• object-src consente di controllare Flash e altri plug-in.
• plugin-types limita i tipi di plug-in che una pagina può richiamare.
• report-uri specifica un URL a cui un browser invierà le segnalazioni quando un violazioni delle norme sulla sicurezza dei contenuti. Questa istruzione non può essere utilizzata in <meta> i tag.
• style-src è la controparte di script-src per i fogli di stile.
• upgrade-insecure-requests indica agli user agent di riscrivere gli schemi URL, da HTTP a HTTPS. Questa istruzione riguarda i siti web con un numero elevato di vecchi URL che devono essere riscritti.
• worker-src è un'istruzione CSP di livello 3 che limita gli URL che potrebbero possono essere caricati come worker, worker condivisi o service worker. Da luglio 2017, ha implementazioni limitate.

Per impostazione predefinita, le istruzioni sono molto aperte. Se non imposti un criterio specifico per un diciamo font-src, questa istruzione si comporta per impostazione predefinita come anche se hai specificato * come origine valida (ad esempio, potresti caricare caratteri da ovunque, senza limitazioni).

Puoi ignorare questo comportamento predefinito specificando un valore default-src . Questa istruzione definisce i valori predefiniti istruzioni non specificate. In genere, si applica a qualsiasi istruzione termina con -src. Se default-src è impostato su https://example.com e non riesci per specificare un'istruzione font-src, puoi caricare i caratteri da https://example.com e nessun altro. Abbiamo specificato solo script-src nei nostri esempi precedenti, il che significa che immagini, caratteri e così via possono essere caricati per qualsiasi origine.

Le seguenti istruzioni non utilizzano default-src come elemento di riserva. Ricorda che non impostarli è la stessa cosa che consentire qualsiasi cosa.

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

Puoi utilizzare il numero di istruzioni che preferisci per il tuo per un'applicazione specifica, elencandoli semplicemente nell'intestazione HTTP, separando istruzioni con il punto e virgola. Assicurati di elencare tutti risorse richieste di un tipo specifico in una singola istruzione. Se hai scritto ad esempio script-src https://host1.com; script-src https://host2.com verrebbe semplicemente ignorata. Qualcosa come il seguente potrebbe specificare correttamente come valide entrambe le origini:

script-src https://host1.com https://host2.com

Se, ad esempio, hai un'applicazione che carica tutte le sue risorse da un rete CDN (Content Delivery Network) (ad esempio https://cdn.example.net) e sappi che non hanno bisogno di plug-in o contenuti all'interno di frame, il criterio potrebbe avere un aspetto ad esempio:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Dettagli di implementazione

Vedrai le intestazioni X-WebKit-CSP e X-Content-Security-Policy in vari tutorial sul web. D'ora in poi, dovrai ignorare questi prefissi intestazioni. I browser moderni (ad eccezione di IE) supportano i caratteri senza prefisso Intestazione Content-Security-Policy. Questa è l'intestazione da utilizzare.

Indipendentemente dall'intestazione utilizzata, le norme vengono definite pagina per pagina: devi inviare l'intestazione HTTP insieme a ogni risposta che desideri garantire che sia protetta. Questo offre molta flessibilità, perché consente di le norme per pagine specifiche in base alle loro specifiche esigenze. Forse un insieme pagine del tuo sito hanno un pulsante +1, mentre altre no: puoi consentire la da caricare solo quando necessario.

L'elenco delle origini in ogni istruzione è flessibile. Puoi specificare le origini per schema (data:, https:) o che variano in specificità da solo nome host (example.com, che corrisponde a qualsiasi origine su tale host: qualsiasi schema, qualsiasi porta) per Un URI completo (https://example.com:443, che corrisponde solo a HTTPS, example.com e solo la porta 443). I caratteri jolly sono accettati, ma solo come schema. una porta o nella posizione più a sinistra del nome host: *://*.example.com:* corrisponde a tutti i sottodomini di example.com (ma non a example.com stesso), utilizzando in qualsiasi schema, su qualsiasi porta.

L'elenco di origine accetta anche quattro parole chiave:

• 'none', come previsto, non corrisponde a nulla.
• 'self' corrisponde all'origine attuale, ma non ai suoi sottodomini.
• 'unsafe-inline' consente l'utilizzo di JavaScript e CSS incorporati. Ne parleremo in dettaglio maggiori dettagli tra poco.)
• 'unsafe-eval' consente meccanismi di conversione da testo a JavaScript come eval. (otterremo anche in questo caso.)

Queste parole chiave richiedono le virgolette singole. Ad esempio, script-src 'self' (tra virgolette) autorizza l'esecuzione di JavaScript dall'host corrente; script-src self (senza virgolette) consente JavaScript da un server denominato "self" (e non dal host attuale), che probabilmente non è quello che intendi.

Sandboxing

C'è un'altra istruzione di cui vale la pena di parlare: sandbox. È un po' diverso da quelli che abbiamo esaminato, in quanto pone restrizioni sulle azioni che la pagina può impiegare anziché risorse che è in grado di caricare. Se È presente l'istruzione sandbox, la pagina viene trattata come se fosse stata caricata all'interno di un <iframe> con un attributo sandbox. Questo può includere un'ampia gamma effetti sulla pagina: forzare la pagina in un'origine unica e impedire la creazione dei contenuti inviati, tra gli altri. Non rientra nell'ambito di questo articolo, ma puoi trovare informazioni dettagliate sugli attributi di sandbox validi nel "Limitazione tramite sandbox" della specifica HTML5.

Il meta tag

Il meccanismo di consegna preferito dei CSP è un'intestazione HTTP. Può essere utile, tuttavia, per impostare un criterio su una pagina direttamente nel markup. Per farlo, usa un tag <meta> con un attributo http-equiv:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

Impossibile utilizzare questa opzione per frame-ancestors, report-uri o sandbox.

Il codice in linea è considerato dannoso

Dovrebbe essere chiaro che CSP si basa sulle origini della lista consentita, modo non ambiguo di indicare al browser di trattare insiemi specifici di risorse accettabile e rifiutare il resto. No, le liste consentite basate sull'origine non lo fanno, Tuttavia, è possibile risolvere la minaccia principale rappresentata dagli attacchi XSS: inline script injection. Se un utente malintenzionato riesce a inserire un tag di script che contiene direttamente payload (<script>sendMyDataToEvilDotCom();</script>), il browser non ha alcun meccanismo che lo consenta di distinguerlo da un tag script incorporato. CSP risolve questo problema escludendo completamente lo script in linea: è l'unico modo per esserne certi.

Questo divieto include non solo gli script incorporati direttamente nei tag script, ma anche gestori di eventi incorporati e javascript: URL. Dovrai spostare i contenuti script in un file esterno e sostituisci javascript: URL e <a ... onclick="[JAVASCRIPT]"> con chiamate addEventListener() appropriate. Ad esempio: potresti riscrivere quanto segue:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

a qualcosa di più simile:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

Il codice riscritto offre una serie di vantaggi oltre all'utilizzo ottimale CSP; è già una best practice, indipendentemente dal tuo uso di CSP. In linea JavaScript mescola struttura e comportamento nel modo in cui non dovresti. Le risorse esterne sono più facili da memorizzare nella cache per i browser, più comprensibili per sviluppatori e favorire la compilazione e la minimizzazione. Scriverai meglio se sposti il codice in risorse esterne.

Lo stile incorporato viene trattato nello stesso modo: sia l'attributo style sia style devono essere consolidati in fogli di stile esterni per proteggere varietà di sorprendentemente intelligenti metodi di esfiltrazione dei dati abilitati da CSS.

Se devi avere script e stile incorporati, puoi abilitarli aggiungendo 'unsafe-inline' come origine consentita in script-src o style-src . Puoi anche utilizzare un nonce o un hash (vedi sotto), ma in realtà non dovresti farlo. L'esclusione dello script incorporato è la principale vittoria in termini di sicurezza offerta da CSP, e allo stesso modo, l'esclusione dello stile in linea rafforza la tua applicazione. Sono un po' fare in modo che tutto funzioni correttamente dopo aver spostato tutto il codice fuori linea, ma è un compromesso che vale la pena fare.

Se devi assolutamente usarlo

Il Livello 2 di CSP offre compatibilità con le versioni precedenti per gli script in linea consentendoti di aggiungere specifici script in linea alla lista consentita utilizzando un nonce crittografico (numero usato una volta) o un hash. Anche se può risultare complicato, è utile in un pizzico.

Per utilizzare un nonce, assegna al tag script un attributo nonce. Il suo valore deve corrispondere a uno nell'elenco delle fonti attendibili. Ad esempio:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

Ora aggiungi il nonce all'istruzione script-src aggiunto alla parola chiave nonce-.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Ricorda che i nonce devono essere rigenerati per ogni richiesta di pagina e inimmaginabili.

Gli hash funzionano più o meno allo stesso modo. Invece di aggiungere codice al tag script, creare un hash SHA dello script stesso e aggiungerlo all'istruzione script-src. Ad esempio, supponiamo che la tua pagina contenga questo:

<script>
  alert('Hello, world.');
</script>

Le tue norme contengono quanto segue:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Qui ci sono alcuni aspetti importanti da tenere in considerazione. Il prefisso sha*- specifica l'algoritmo che genera l'hash. Nell'esempio precedente, viene utilizzato sha256-. CSP inoltre supporta sha384- e sha512-. Quando generi l'hash, non includere il codice <script> tag. Anche le lettere maiuscole e gli spazi vuoti, inclusi iniziali o uno spazio vuoto finale.

Una ricerca su Google sulla generazione di hash SHA ti porterà a soluzioni in qualsiasi e il numero di lingue. Utilizzando Chrome 40 o versioni successive, puoi aprire DevTools e quindi ricarica la pagina. La scheda Console contiene messaggi di errore con i valori sha256 per ciascuno dei tuoi script incorporati.

Anche Eval

Anche quando un utente malintenzionato non riesce a inserire direttamente lo script, potrebbe riuscire a ingannare della tua applicazione alla conversione di testo altrimenti inerte in JavaScript eseguibile ed eseguendole per loro conto. eval(), nuovo Function(), setTimeout([string], ...) e setInterval([string], ...) sono tutti i vettori attraverso i quali viene inserito di testo potrebbe eseguire qualcosa di inaspettatamente dannoso. Valore predefinito di CSP la risposta a questo rischio è il blocco completo di tutti questi vettori.

Ciò influisce notevolmente sul modo in cui crei le applicazioni:

• Devi analizzare JSON tramite la JSON.parse integrata, anziché fare affidamento su eval. Le operazioni JSON native sono disponibili in tutti i browser a partire da IE8 e sono completamente al sicuro.
• Riscrivi tutte le chiamate setTimeout o setInterval in corso con funzioni in linea anziché con stringhe. Ad esempio:

setTimeout("document.querySelector('a').style.display = 'none';", 10);

sarebbe scritto meglio come:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

• Evita i modelli incorporati in fase di runtime: molte librerie di modelli utilizzano liberamente new Function() per velocizzare la generazione dei modelli in fase di runtime. È una un'utile applicazione della programmazione dinamica, ma comporta il rischio di per valutare testo dannoso. Alcuni framework supportano immediatamente CSP, utilizzando un parser affidabile in assenza di eval. Direttiva ng-csp di AnngularJS ne è un buon esempio.

Tuttavia, una scelta migliore sarebbe un linguaggio di modelli precompilazione (Handlebars, ad esempio). La precompilazione dei modelli può rendere l'esperienza utente ancora è più veloce rispetto all'implementazione di runtime più rapida ed è anche più sicura. Se valuta e i suoi fratelli "text-to-JavaScript" sono essenziali per la tua applicazione, attivale aggiungendo 'unsafe-eval' come origine consentita in un script-src , ma sconsigliamo vivamente di farlo. Esclusione della possibilità di eseguire rende molto più difficile per un aggressore eseguire senza autorizzazione sul tuo sito.

Rapporti

La capacità di CSP di bloccare le risorse non attendibili sul lato client è un enorme vantaggio per il tuo utenti, ma sarebbe utile ricevere qualche tipo di notifica rispedito al server, in modo che tu possa identificare e eliminare eventuali bug che consentono con un'iniezione malevola. A questo scopo, puoi indicare browser a POST segnalazioni di violazioni in formato JSON a una sede specificato in un'istruzione report-uri.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Questi report avranno il seguente aspetto:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

Questo contiene una buona porzione di informazioni che ti aiuteranno a rintracciare il causa specifica della violazione, inclusa la pagina in cui si è verificata (document-uri), il referrer di quella pagina (tieni presente che, a differenza dell'interfaccia HTTP campo di intestazione, la chiave non contiene errori di ortografia), la risorsa che ha violato il le norme della pagina (blocked-uri), l'istruzione specifica che ha violato (violated-directive) e la norma completa della pagina (original-policy).

Solo report

Se hai appena iniziato a usare CSP, ha senso valutare il modello attuale lo stato desiderato della tua applicazione prima di implementare un criterio draconiano per gli utenti. Come primo passo per un deployment completo, puoi chiedere al browser di monitorare un criterio, segnalando le violazioni ma senza applicare le restrizioni. Invece di inviare un'intestazione Content-Security-Policy, inviare Intestazione Content-Security-Policy-Report-Only.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Il criterio specificato in modalità solo report non bloccherà le risorse limitate, ma invierà le segnalazioni di violazioni alla località da te specificata. Puoi anche inviare entrambe le intestazioni, applicando un criterio e monitorando un altro. Questo è un ottimo per valutare l'effetto delle modifiche al CSP della tua applicazione: attiva segnalare una nuova norma, monitorare le segnalazioni di violazioni e correggere eventuali bug alzare; non appena il risultato ti soddisfa, inizia ad applicare la nuova norma.

Uso nel mondo reale

CSP 1 è abbastanza utilizzabile in Chrome, Safari e Firefox, ma ha un utilizzo molto limitato in IE 10. Puoi vedi le specifiche alla pagina caniuse.com. CSP di livello 2 è disponibile in Chrome da quando alla versione 40. L'intestazione è stata implementata da siti di massa come Twitter e Facebook (Vale la pena leggere il case study di Twitter) e lo standard è già pronto per iniziare a eseguire il deployment sui tuoi siti.

Il primo passo per creare un criterio per la tua applicazione è valutare il che stai effettivamente caricando. Una volta che pensi di avere una gestione tutti gli elementi nella tua app, configura un criterio basato su i tuoi requisiti. Analizziamo alcuni casi d'uso comuni e stabiliamo in che modo essere in grado di supportarli al meglio entro i confini protettivi di CSP.

Caso d'uso 1: widget di social media

• Il pulsante +1 di Google include uno script da https://apis.google.com e incorpora un elemento <iframe> da https://plusone.google.com. È necessario un criterio che includa entrambi Origini per incorporare il pulsante. Un criterio minimo sarebbe script-src https://apis.google.com; child-src https://plusone.google.com. Devi inoltre avere per assicurarti che lo snippet di JavaScript fornito da Google venga estratto un file JavaScript esterno. Se avevi un criterio basato sul livello 1 che utilizza frame-src Per il livello 2 devi passare a child-src. Questa operazione non è più necessaria in CSP di livello 3.

• Pulsante Mi piace di Facebook offre varie opzioni di implementazione. Ti consigliamo di attenerti alle versione di <iframe> poiché viene isolata in sicurezza tramite sandbox dal resto del sito. it richiede un'istruzione child-src https://facebook.com per funzionare correttamente. Nota che, per impostazione predefinita, il codice <iframe> fornito da Facebook carica un codice relativo URL, //facebook.com. Modificalo per specificare esplicitamente HTTPS: https://facebook.com. Non c'è motivo di utilizzare HTTP se non è necessario.

• Pulsante Tweet di Twitter sfrutta l'accesso a uno script e a un frame, entrambi ospitati https://platform.twitter.com. (Anche Twitter fornisce un URL relativo per default; modifica il codice per specificare HTTPS quando lo copi/incolli localmente). Il valore script-src https://platform.twitter.com; child-src https://platform.twitter.com sarà impostato, a patto che sposti lo snippet JavaScript forniti da Twitter in un file JavaScript esterno.

• Altre piattaforme hanno requisiti simili e possono essere affrontati in modo simile. Ti consigliamo di impostare un default-src di 'none' e di guardare la console per e determinare quali risorse dovrai attivare per far funzionare i widget.

L'inclusione di più widget è molto semplice: basta combinare i criteri istruzioni, ricordando di unire tutte le risorse di un singolo tipo in un . Se volessi tutti e tre i widget dei social media, le norme sarebbero nel seguente modo:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Caso d'uso 2: blocco

Supponi per un momento di gestire un sito di banking e di volere assicurarti che è possibile caricare solo le risorse che hai scritto personalmente. In questo scenario, iniziano con un criterio predefinito che blocca assolutamente tutto (default-src 'none') e si sviluppa da lì.

Supponiamo che la banca carichi tutte le immagini, lo stile e lo script da una rete CDN https://cdn.mybank.net e si connette tramite XHR a https://api.mybank.com/ a estrarre vari bit di dati. Vengono utilizzati i frame, ma solo per le pagine locali sito (nessuna origine di terze parti). Non c'è Flash sul sito, nessun carattere, no extra. L'intestazione CSP più restrittiva che potremmo inviare è questa:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Caso d'uso 3: solo SSL

L'amministratore di un forum di discussione per nozze vuole assicurarsi che tutte le risorse vengono caricati solo tramite canali sicuri, ma non scrive molto codice; riscrittura grandi porzioni di software di forum di terze parti che sono riempite il copione e lo stile in linea vanno al di là delle sue capacità. Le seguenti norme sarebbero efficace:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Anche se https: è specificato in default-src, lo script e lo stile non ereditano automaticamente questa origine. Ogni istruzione è completamente sovrascriverà l'impostazione predefinita per quel tipo specifico di risorsa.

Il futuro

Il livello 2 del criterio di sicurezza del contenuto è un Suggerimento dei candidati. Web Application Security Working Group di W3C ha già iniziato a lavorare alla prossima iterazione, Criterio di sicurezza del contenuto - Livello 3.

Se ti interessa la discussione su queste funzionalità in arrivo, scorri gli archivi delle mailing list public-webappsec@, o unisciti a te stesso.

Feedback