Inhoudsbeveiligingsbeleid

Mike West

Joe Medley

Het beveiligingsmodel van het web is geworteld in hetzelfde beleid . Code van https://mybank.com mag alleen toegang hebben tot de gegevens van https://mybank.com , en https://evil.example.com mag zeker nooit toegang krijgen. Elke oorsprong wordt geïsoleerd gehouden van de rest van het web, waardoor ontwikkelaars een veilige sandbox hebben waarin ze kunnen bouwen en spelen. In theorie is dit volkomen briljant. In de praktijk hebben aanvallers slimme manieren gevonden om het systeem te ondermijnen.

Cross-site scripting (XSS) -aanvallen omzeilen bijvoorbeeld hetzelfde oorsprongsbeleid door een site te misleiden om kwaadaardige code samen met de bedoelde inhoud af te leveren. Dit is een enorm probleem, omdat browsers alle code die op een pagina verschijnt, vertrouwen als legitiem onderdeel van de beveiligingsoorsprong van die pagina. De XSS Cheat Sheet is een oude maar representatieve dwarsdoorsnede van de methoden die een aanvaller kan gebruiken om dit vertrouwen te schenden door kwaadaardige code te injecteren. Als een aanvaller met succes welke code dan ook injecteert, is het vrijwel game-over: de gegevens van de gebruikerssessie worden gecompromitteerd en informatie die geheim moet worden gehouden, wordt geëxfiltreerd naar The Bad Guys. Indien mogelijk willen wij dat uiteraard graag voorkomen.

Dit overzicht belicht een verdedigingsmechanisme dat het risico en de impact van XSS-aanvallen in moderne browsers aanzienlijk kan verminderen: Content Security Policy (CSP).

TL; DR

• Gebruik toelatingslijsten om de klant te vertellen wat wel en niet is toegestaan.
• Ontdek welke richtlijnen beschikbaar zijn.
• Leer de trefwoorden die ze gebruiken.
• Inlinecode en eval() worden als schadelijk beschouwd.
• Rapporteer beleidsschendingen aan uw server voordat u ze afdwingt.

Toelatingslijsten voor bronnen

Het probleem dat door XSS-aanvallen wordt uitgebuit, is het onvermogen van de browser om onderscheid te maken tussen scripts die deel uitmaken van uw applicatie en scripts die kwaadwillig door derden zijn geïnjecteerd. De Google +1-knop onderaan deze pagina laadt bijvoorbeeld code van https://apis.google.com/js/plusone.js en voert deze uit in de context van de oorsprong van deze pagina. We vertrouwen die code, maar we kunnen niet verwachten dat de browser er zelf achter komt dat de code van apis.google.com geweldig is, terwijl de code van apis.evil.example.com dat waarschijnlijk niet is. De browser downloadt en voert met plezier elke code uit die een pagina vraagt, ongeacht de bron.

In plaats van blindelings te vertrouwen op alles wat een server levert, definieert CSP de Content-Security-Policy HTTP-header, waarmee u een toelatingslijst kunt maken van bronnen met vertrouwde inhoud, en instrueert de browser om alleen bronnen uit die bronnen uit te voeren of weer te geven. Zelfs als een aanvaller een gat kan vinden waardoor het script kan worden geïnjecteerd, komt het script niet overeen met de toelatingslijst en wordt het daarom niet uitgevoerd.

Omdat we erop vertrouwen dat apis.google.com geldige code levert, en we erop vertrouwen dat we hetzelfde doen, gaan we een beleid definiëren dat alleen toestaat dat scripts worden uitgevoerd als het uit een van deze twee bronnen komt:

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

Simpel, toch? Zoals je waarschijnlijk al geraden hebt, is script-src een richtlijn die een reeks scriptgerelateerde privileges voor een specifieke pagina bestuurt. We hebben 'self' opgegeven als een geldige scriptbron, en https://apis.google.com als een andere. De browser downloadt plichtsgetrouw JavaScript van apis.google.com via HTTPS en voert deze uit, evenals vanaf de oorsprong van de huidige pagina.

Als dit beleid is gedefinieerd, genereert de browser eenvoudigweg een fout in plaats van het script uit een andere bron te laden. Wanneer een slimme aanvaller erin slaagt code in uw site te injecteren, krijgt hij een foutmelding in plaats van het succes dat hij verwachtte.

Het beleid is van toepassing op een grote verscheidenheid aan hulpbronnen

Hoewel scriptbronnen de meest voor de hand liggende beveiligingsrisico's zijn, biedt CSP een uitgebreide reeks beleidsrichtlijnen die een tamelijk gedetailleerde controle mogelijk maken over de bronnen die een pagina mag laden. Je hebt script-src al gezien, dus het concept zou duidelijk moeten zijn.

Laten we snel de rest van de resourcerichtlijnen doornemen. De onderstaande lijst geeft de status van de richtlijnen weer vanaf niveau 2. Er is een niveau 3-specificatie gepubliceerd, maar deze is grotendeels niet geïmplementeerd in de belangrijkste browsers.

• base-uri beperkt de URL's die kunnen verschijnen in het <base> -element van een pagina.
• child-src vermeldt de URL's voor werknemers en de inhoud van ingebedde frames. Bijvoorbeeld: child-src https://youtube.com zou het insluiten van video's van YouTube mogelijk maken, maar niet van andere oorsprong.
• connect-src beperkt de oorsprong waarmee u verbinding kunt maken (via XHR, WebSockets en EventSource).
• font-src specificeert de oorsprong die weblettertypen kan bedienen. De weblettertypen van Google kunnen worden ingeschakeld via font-src https://themes.googleusercontent.com .
• form-action vermeldt geldige eindpunten voor indiening via <form> -tags.
• frame-ancestors specificeert de bronnen die de huidige pagina kunnen insluiten. Deze richtlijn is van toepassing op de tags <frame> , <iframe> , <embed> en <applet> . Deze richtlijn kan niet worden gebruikt in <meta> -tags en is alleen van toepassing op niet-HTML-bronnen.
• frame-src was verouderd op niveau 2, maar wordt hersteld op niveau 3. Als het niet aanwezig is, valt het nog steeds terug naar child-src zoals voorheen.
• img-src definieert de oorsprong van waaruit afbeeldingen kunnen worden geladen.
• media-src beperkt de oorsprong die video en audio mag leveren.
• object-src maakt controle over Flash en andere plug-ins mogelijk.
• plugin-types beperkt de soorten plug-ins die een pagina kan aanroepen.
• report-uri specificeert een URL waarnaar een browser rapporten verzendt wanneer een inhoudbeveiligingsbeleid wordt geschonden. Deze richtlijn kan niet worden gebruikt in <meta> -tags.
• style-src is de tegenhanger van script-src voor stylesheets.
• upgrade-insecure-requests instrueert user agents om URL-schema's te herschrijven en HTTP in HTTPS te veranderen. Deze richtlijn is bedoeld voor websites met grote aantallen oude URL's die herschreven moeten worden.
• worker-src is een CSP Level 3-richtlijn die de URL's beperkt die kunnen worden geladen als worker, shared worker of service worker. Sinds juli 2017 heeft deze richtlijn een beperkte implementatie .

Richtlijnen zijn standaard wijd open. Als u geen specifiek beleid instelt voor een richtlijn, bijvoorbeeld font-src , gedraagt ​​die richtlijn zich standaard alsof u * als geldige bron hebt opgegeven (u kunt bijvoorbeeld lettertypen overal vandaan laden, zonder beperkingen) .

U kunt dit standaardgedrag overschrijven door een default-src richtlijn op te geven. Deze richtlijn definieert de standaardinstellingen voor de meeste richtlijnen die u niet specificeert. Over het algemeen geldt dit voor elke richtlijn die eindigt op -src . Als default-src is ingesteld op https://example.com en u geen font-src richtlijn opgeeft, kunt u lettertypen laden vanaf https://example.com en nergens anders. In onze eerdere voorbeelden hebben we alleen script-src gespecificeerd, wat betekent dat afbeeldingen, lettertypen, enzovoort vanuit elke bron kunnen worden geladen.

De volgende richtlijnen gebruiken default-src niet als fallback. Houd er rekening mee dat het niet instellen ervan hetzelfde is als iets toestaan.

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

U kunt zoveel of zo weinig van deze richtlijnen gebruiken als zinvol is voor uw specifieke toepassing, door ze eenvoudigweg in de HTTP-header op te nemen en de richtlijnen te scheiden met puntkomma's. Zorg ervoor dat u alle vereiste bronnen van een specifiek type in één enkele richtlijn vermeldt. Als je zoiets als script-src https://host1.com; script-src https://host2.com de tweede richtlijn zou eenvoudigweg worden genegeerd. Iets als het volgende zou beide oorsprongen correct als geldig specificeren:

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

Als u bijvoorbeeld een toepassing heeft die alle bronnen laadt vanuit een inhoudsleveringsnetwerk (bijvoorbeeld https://cdn.example.net ), en weet dat u geen ingekaderde inhoud of plug-ins nodig heeft, dan is uw beleid kan er ongeveer als volgt uitzien:

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

Implementatiedetails

U zult X-WebKit-CSP en X-Content-Security-Policy headers tegenkomen in verschillende tutorials op internet. In de toekomst moet u deze vooraf ingestelde kopteksten negeren. Moderne browsers (met uitzondering van IE) ondersteunen de niet-voorgefixeerde Content-Security-Policy header. Dat is de header die u moet gebruiken.

Ongeacht de header die u gebruikt, wordt het beleid per pagina gedefinieerd: u moet de HTTP-header meesturen met elk antwoord waarvan u zeker wilt weten dat het beschermd is. Dit biedt veel flexibiliteit, omdat u het beleid voor specifieke pagina's kunt verfijnen op basis van hun specifieke behoeften. Misschien heeft één set pagina's op uw site een +1-knop, terwijl andere dat niet hebben: u kunt toestaan ​​dat de knopcode alleen wordt geladen als dat nodig is.

De bronnenlijst in elke richtlijn is flexibel. U kunt bronnen specificeren per schema ( data: , https: ), of qua specificiteit variëren van alleen hostnaam ( example.com , wat overeenkomt met elke oorsprong op die host: elk schema, elke poort) tot een volledig gekwalificeerde URI ( https://example.com:443 , wat alleen overeenkomt met HTTPS, alleen example.com en alleen poort 443). Wildcards worden geaccepteerd, maar alleen als schema, poort of in de meest linkse positie van de hostnaam: *://*.example.com:* komt overeen met alle subdomeinen van example.com (maar niet example.com zelf), met elk schema, op elke poort.

De bronnenlijst accepteert ook vier trefwoorden:

• 'none' komt, zoals je zou verwachten, met niets overeen.
• 'self' komt overeen met de huidige oorsprong, maar niet met de subdomeinen.
• 'unsafe-inline' maakt inline JavaScript en CSS mogelijk. (We zullen hier straks dieper op ingaan.)
• 'unsafe-eval' maakt tekst-naar-JavaScript-mechanismen mogelijk, zoals eval . (Wij komen hier ook op terug.)

Voor deze trefwoorden zijn enkele aanhalingstekens vereist. script-src 'self' (tussen aanhalingstekens) autoriseert bijvoorbeeld de uitvoering van JavaScript vanaf de huidige host; script-src self (geen aanhalingstekens) staat JavaScript toe van een server met de naam " self " (en niet van de huidige host), wat waarschijnlijk niet is wat je bedoelde.

Sandboxen

Er is nog een richtlijn die de moeite waard is om over te praten: sandbox . Het is een beetje anders dan de andere die we hebben bekeken, omdat het beperkingen oplegt aan acties die de pagina kan ondernemen in plaats van aan bronnen die de pagina kan laden. Als de sandbox instructie aanwezig is, wordt de pagina behandeld alsof deze in een <iframe> met een sandbox attribuut is geladen. Dit kan een breed scala aan effecten op de pagina hebben: onder andere het forceren van de pagina naar een unieke oorsprong en het voorkomen van het indienen van formulieren. Het valt iets buiten het bestek van dit artikel, maar je kunt volledige details over geldige sandbox-attributen vinden in het gedeelte 'Sandboxing' van de HTML5-specificatie .

De metatag

Het voorkeursleveringsmechanisme van CSP is een HTTP-header. Het kan echter handig zijn om direct in de markup een beleid op een pagina in te stellen. Doe dat met behulp van een <meta> -tag met een http-equiv attribuut:

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

Dit kan niet worden gebruikt voor frame-ancestors , report-uri sandbox .

Inlinecode wordt als schadelijk beschouwd

Het moet duidelijk zijn dat CSP gebaseerd is op de oorsprong van de toelatingslijst, omdat dat een ondubbelzinnige manier is om de browser te instrueren om specifieke sets bronnen als acceptabel te behandelen en de rest te weigeren. Op origin gebaseerde toelatingslijsten bieden echter geen oplossing voor de grootste dreiging van XSS-aanvallen: inline scriptinjectie. Als een aanvaller een scripttag kan injecteren die direct een kwaadaardige lading bevat ( <script>sendMyDataToEvilDotCom();</script> ), heeft de browser geen mechanisme om deze te onderscheiden van een legitieme inline scripttag. CSP lost dit probleem op door inline-script volledig te verbieden: het is de enige manier om er zeker van te zijn.

Dit verbod omvat niet alleen scripts die rechtstreeks in script zijn ingebed, maar ook inline gebeurtenishandlers en javascript: URL's. U moet de inhoud van script naar een extern bestand verplaatsen en javascript: URLs en <a ... onclick="[JAVASCRIPT]"> vervangen door de juiste addEventListener() aanroepen. U kunt bijvoorbeeld het volgende herschrijven van:

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

naar iets meer als:

<!-- 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);
});

De herschreven code heeft een aantal voordelen die verder gaan dan de goede samenwerking met CSP; het is al de beste praktijk, ongeacht uw gebruik van CSP. Inline JavaScript combineert structuur en gedrag precies zoals u dat niet zou moeten doen. Externe bronnen kunnen door browsers gemakkelijker in het cachegeheugen worden opgeslagen, zijn begrijpelijker voor ontwikkelaars en bevorderlijk voor compilatie en minificatie. U schrijft betere code als u het werk doet om code naar externe bronnen te verplaatsen.

Inline-stijl wordt op dezelfde manier behandeld: zowel het style als style moeten worden geconsolideerd in externe stylesheets om te beschermen tegen een verscheidenheid aan verrassend slimme data-exfiltratiemethoden die CSS mogelijk maakt.

Als u inline script en stijl nodig heeft, kunt u dit inschakelen door 'unsafe-inline' toe te voegen als toegestane bron in een script-src of style-src richtlijn. Je kunt ook een nonce of een hasj gebruiken (zie hieronder), maar dat mag eigenlijk niet. Het verbieden van inline-script is de grootste veiligheidswinst die CSP biedt, en het verbieden van inline-stijl maakt uw applicatie ook moeilijker. Het kost vooraf wat moeite om ervoor te zorgen dat alles correct werkt nadat alle code uit de lijn is gehaald, maar dat is een afweging die de moeite waard is.

Als je het absoluut moet gebruiken

CSP Level 2 biedt achterwaartse compatibiliteit voor inline scripts doordat u specifieke inline scripts aan de toelatingslijst kunt toevoegen met behulp van een cryptografische nonce (nummer dat één keer wordt gebruikt) of een hash. Hoewel dit omslachtig kan zijn, is het in geval van nood handig.

Om een ​​nonce te gebruiken, geeft u uw scripttag een nonce-attribuut. De waarde ervan moet overeenkomen met die in de lijst met vertrouwde bronnen. Bijvoorbeeld:

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

Voeg nu de nonce toe aan uw script-src richtlijn, toegevoegd aan het trefwoord nonce- .

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

Houd er rekening mee dat nonces voor elk paginaverzoek opnieuw moeten worden gegenereerd en dat ze onraadbaar moeten zijn.

Hashes werken op vrijwel dezelfde manier. In plaats van code aan de scripttag toe te voegen, maakt u een SHA-hash van het script zelf en voegt u deze toe aan de script-src richtlijn. Stel dat uw pagina bijvoorbeeld dit bevatte:

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

Uw polis zou dit bevatten:

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

Er zijn een paar dingen waar u op moet letten. Het sha*- voorvoegsel specificeert het algoritme dat de hash genereert. In het bovenstaande voorbeeld wordt sha256- gebruikt. CSP ondersteunt ook sha384- en sha512- . Wanneer u de hash genereert, neem dan niet de <script> -tags op. Ook hoofdlettergebruik en witruimte zijn van belang, inclusief witruimte vooraan of achteraan.

Een Google-zoekopdracht naar het genereren van SHA-hashes leidt u naar oplossingen in een willekeurig aantal talen. Met Chrome 40 of hoger kunt u DevTools openen en vervolgens uw pagina opnieuw laden. Het tabblad Console bevat foutmeldingen met de juiste sha256-hash voor elk van uw inline-scripts.

Eva ook

Zelfs als een aanvaller het script niet rechtstreeks kan injecteren, kan hij/zij uw applicatie mogelijk misleiden om anderszins inerte tekst om te zetten in uitvoerbaar JavaScript en deze namens hem/haar uit te voeren. eval() , new Function() , setTimeout([string], ...) , en setInterval([string], ...) zijn allemaal vectoren waardoor geïnjecteerde tekst uiteindelijk iets onverwacht kwaadaardigs kan uitvoeren. De standaardreactie van CSP op dit risico is het volledig blokkeren van al deze vectoren.

Dit heeft meerdere gevolgen voor de manier waarop u applicaties bouwt:

• U moet JSON parseren via de ingebouwde JSON.parse , in plaats van te vertrouwen op eval . Native JSON-bewerkingen zijn sinds IE8 in elke browser beschikbaar en zijn volkomen veilig.
• Herschrijf alle setTimeout of setInterval aanroepen die u momenteel maakt met inline-functies in plaats van tekenreeksen. Bijvoorbeeld:

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

zou beter geschreven kunnen worden als:

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

• Vermijd inline-sjablonen tijdens runtime: veel sjabloonbibliotheken gebruiken new Function() royaal om het genereren van sjablonen tijdens runtime te versnellen. Het is een handige toepassing van dynamisch programmeren, maar het risico bestaat dat kwaadaardige tekst wordt geëvalueerd. Sommige raamwerken ondersteunen CSP out-of-the-box en vallen terug op een robuuste parser bij afwezigheid van eval . De ng-csp-richtlijn van AngularJS is hiervan een goed voorbeeld.

Een betere keuze zou echter een sjabloontaal zijn die precompilatie biedt ( Handlebars doet dat bijvoorbeeld). Het vooraf compileren van uw sjablonen kan de gebruikerservaring zelfs sneller maken dan de snelste runtime-implementatie, en het is ook veiliger. Als eval en zijn tekst-naar-JavaScript-broeders essentieel zijn voor uw toepassing, kunt u deze inschakelen door 'unsafe-eval' toe te voegen als toegestane bron in een script-src richtlijn, maar we raden dit ten zeerste af. Het verbieden van de mogelijkheid om tekenreeksen uit te voeren, maakt het voor een aanvaller veel moeilijker om ongeautoriseerde code op uw site uit te voeren.

Rapportage

Het vermogen van CSP om niet-vertrouwde bronnen aan de clientzijde te blokkeren is een enorme overwinning voor uw gebruikers, maar het zou heel nuttig zijn om een ​​soort melding teruggestuurd te krijgen naar de server, zodat u eventuele bugs die kwaadaardige injectie mogelijk maken, in de eerste instantie kunt identificeren en onderdrukken. plaats. Hiertoe kunt u de browser opdracht geven om schendingsrapporten in JSON-indeling POST op een locatie die is opgegeven in een report-uri instructie.

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

Deze rapporten zullen er ongeveer als volgt uitzien:

{
  "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"
  }
}

Dit bevat een flinke hoeveelheid informatie die u zal helpen de specifieke oorzaak van de overtreding op te sporen, inclusief de pagina waarop de overtreding heeft plaatsgevonden ( document-uri ), de verwijzende pagina van die pagina (merk op dat, in tegenstelling tot het HTTP-headerveld, de sleutel niet verkeerd gespeld), de bron die het beleid van de pagina heeft geschonden ( blocked-uri ), de specifieke richtlijn die deze heeft geschonden ( violated-directive ) en het volledige beleid van de pagina ( original-policy ).

Alleen rapport

Als u net begint met CSP, is het zinvol om de huidige status van uw applicatie te evalueren voordat u een draconisch beleid voor uw gebruikers implementeert. Als opstap naar een volledige implementatie kunt u de browser vragen een beleid te monitoren, overtredingen te melden maar de beperkingen niet af te dwingen. In plaats van een Content-Security-Policy header te verzenden, verzendt u een Content-Security-Policy-Report-Only header.

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

Het beleid dat is opgegeven in de modus 'Alleen rapporteren' blokkeert geen beperkte bronnen, maar stuurt wel overtredingsrapporten naar de locatie die u opgeeft. U kunt zelfs beide headers verzenden, waarbij u het ene beleid afdwingt terwijl u het andere in de gaten houdt. Dit is een geweldige manier om het effect van wijzigingen in de CSP van uw applicatie te evalueren: schakel rapportage in voor een nieuw beleid, controleer de overtredingsrapporten en repareer eventuele bugs die zich voordoen; Wanneer u tevreden bent met het effect ervan, begint u met het afdwingen van het nieuwe beleid.

Gebruik in de echte wereld

CSP 1 is redelijk bruikbaar in Chrome, Safari en Firefox, maar heeft zeer beperkte ondersteuning in IE 10. U kunt de details bekijken op caniuse.com . CSP Level 2 is beschikbaar in Chrome sinds versie 40. Grote sites zoals Twitter en Facebook hebben de header geïmplementeerd ( de casestudy van Twitter is het lezen waard), en de standaard is vrijwel klaar om op uw eigen sites te worden geïmplementeerd.

De eerste stap bij het opstellen van een beleid voor uw toepassing is het evalueren van de bronnen die u daadwerkelijk laadt. Zodra u denkt dat u grip heeft op hoe de zaken in uw app in elkaar zitten, kunt u een beleid opstellen op basis van die vereisten. Laten we een aantal veelvoorkomende gebruiksscenario's doornemen en bepalen hoe we deze het beste kunnen ondersteunen binnen de beschermende grenzen van CSP.

Gebruiksvoorbeeld #1: widgets voor sociale media

• De +1-knop van Google bevat een script van https://apis.google.com en sluit een <iframe> van https://plusone.google.com in. Om de knop in te sluiten, hebt u een beleid nodig dat beide oorsprongen omvat. Een minimaal beleid zou script-src https://apis.google.com; child-src https://plusone.google.com . U moet er ook voor zorgen dat het JavaScript-fragment dat Google levert, wordt uitgetrokken in een extern JavaScript-bestand. Als u een op niveau 1 gebaseerd beleid had met behulp van frame-src vereiste Niveau 2 dat u dit moest wijzigen in child-src . In CSP Niveau 3 is dit niet meer nodig.

• De Like-knop van Facebook heeft een aantal implementatiemogelijkheden. We raden aan om bij de <iframe> -versie te blijven, omdat deze veilig in de sandbox van de rest van uw site staat. Het vereist een child-src https://facebook.com om correct te functioneren. Houd er rekening mee dat de <iframe> -code die Facebook levert standaard een relatieve URL laadt, //facebook.com . Wijzig dat om HTTPS expliciet op te geven: https://facebook.com . Er is geen reden om HTTP te gebruiken als dat niet nodig is.

• De Tweet-knop van Twitter is afhankelijk van toegang tot een script en een frame, beide gehost op https://platform.twitter.com . (Twitter biedt eveneens standaard een relatieve URL; bewerk de code om HTTPS op te geven wanneer deze lokaal wordt gekopieerd/geplakt.) Je bent helemaal klaar met script-src https://platform.twitter.com; child-src https://platform.twitter.com , zolang je het JavaScript-fragment dat Twitter levert naar een extern JavaScript-bestand verplaatst.

• Andere platforms hebben vergelijkbare vereisten en kunnen op dezelfde manier worden aangepakt. We raden aan om gewoon een default-src van 'none' in te stellen en op uw console te kijken om te bepalen welke bronnen u moet inschakelen om de widgets te laten werken.

Het toevoegen van meerdere widgets is eenvoudig: combineer simpelweg de beleidsrichtlijnen en vergeet niet om alle bronnen van één type samen te voegen in één enkele richtlijn. Als je alle drie de sociale media-widgets zou willen, zou het beleid er als volgt uitzien:

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

Gebruiksscenario #2: afsluiting

Stel dat u een banksite beheert en er zeker van wilt zijn dat alleen de bronnen die u zelf heeft geschreven, kunnen worden geladen. Begin in dit scenario met een standaardbeleid dat absoluut alles blokkeert ( default-src 'none' ), en bouw vanaf daar verder op.

Laten we zeggen dat de bank alle afbeeldingen, stijl en script laadt vanaf een CDN op https://cdn.mybank.net en via XHR verbinding maakt met https://api.mybank.com/ om verschillende stukjes gegevens naar beneden te halen. Er worden frames gebruikt, maar alleen voor pagina's die lokaal op de site staan ​​(geen oorsprong van derden). Er is geen Flash op de site, geen lettertypen, geen extra's. De meest beperkende CSP-header die we kunnen verzenden is deze:

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'

Gebruiksscenario #3: Alleen SSL

Een beheerder van een trouwringdiscussieforum wil ervoor zorgen dat alle bronnen alleen via beveiligde kanalen worden geladen, maar schrijft niet echt veel code; het herschrijven van grote delen van de forumsoftware van derden, die tot de rand gevuld is met inline script en stijl, ligt buiten zijn mogelijkheden. Het volgende beleid zou effectief zijn:

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

Hoewel https: is opgegeven in default-src , nemen de script- en stijlrichtlijnen die bron niet automatisch over. Elke richtlijn overschrijft volledig de standaardwaarde voor dat specifieke type bron.

De toekomst

Inhoudsbeveiligingsbeleid niveau 2 is een aanbeveling van de kandidaat . De Web Application Security Working Group van het W3C is al begonnen met werken aan de volgende iteratie van de specificatie, Content Security Policy Level 3 .

Als je geïnteresseerd bent in de discussie rond deze aankomende functies, blader dan door de public-webappsec@ mailinglijstarchieven of doe zelf mee.

Feedback