Content Security Policy

Joe Medley
Joe Medley
GitHub

Das Sicherheitsmodell des Internets basiert Same-Origin-Richtlinie. Code aus https://mybank.com sollte nur Zugriff auf https://mybank.com haben und https://evil.example.com sollte auf keinen Fall Zugriff erhalten. Jeder Ursprung wird vom Rest des Webs isoliert, sodass Entwickler Sandbox zu erstellen und zu spielen. Theoretisch ist das absolut genial. In haben Angreifer auf intelligente Weise Möglichkeiten gefunden, das System zu umkehren.

Cross-Site-Scripting (XSS) etwa dieselbe Ursprungsrichtlinie umgehen, indem eine Website die zusammen mit den beabsichtigten Inhalten Schadcode liefern. Das ist ein da Browser dem gesamten Code, der auf einer Seite angezeigt wird, die legitim als Teil des Sicherheitsursprungs dieser Seite sind. Die XSS auf einen Blick ist ein alter, aber repräsentativer Querschnitt der Methoden, die ein Angreifer nutzen könnte diese Vertrauenswürdigkeit zu verletzen, indem sie bösartigen Code einschleusen. Wenn ein Angreifer erfolgreich war Beliebigen Code einschleust, ist das so ziemlich das Spiel: Die Sitzungsdaten und Informationen, die geheim gehalten werden sollten, werden an die The Bad Leute. Natürlich möchten wir das natürlich verhindern, wenn möglich.

Diese Übersicht zeigt eine Schutzmaßnahmen, die das Risiko erheblich reduzieren Auswirkungen von XSS-Angriffen auf moderne Browser: Content Security Policy (CSP)

Kurzfassung

  • Über Zulassungslisten teilen Sie dem Kunden mit, was erlaubt ist und was nicht.
  • Informationen zu den verfügbaren Anweisungen.
  • Lernen Sie die verwendeten Keywords kennen.
  • Inline-Code und eval() gelten als schädlich.
  • Melden Sie Richtlinienverstöße vor dem Erzwingen an Ihren Server.

Zulassungslisten für Quellen

Das Problem, das von XSS-Angriffen ausgenutzt wird, besteht darin, dass der Browser nicht zwischen zwischen Skript, das Teil Ihrer Anwendung ist, und dem Skript, von Dritten bösartig eingeschleust wurden. Die Google +1-Schaltfläche auf der Seite auf dieser Seite wird Code aus folgendem Bereich geladen und ausgeführt: https://apis.google.com/js/plusone.js im Kontext des Ursprungs dieser Seite. Mi. Wir können jedoch nicht erwarten, dass der Browser diesen Code selbst findet. von apis.google.com ist genial, während Code von apis.evil.example.com genial ist wahrscheinlich nicht. Der Browser lädt problemlos jeden Code einer Seite herunter und führt ihn aus. unabhängig von der Quelle.

Anstatt allem, was ein Server liefert, blind zu vertrauen, definiert die CSP die Content-Security-Policy-HTTP-Header, mit dem Sie eine Zulassungsliste für Quellen vertrauenswürdiger Inhalte und weist den Browser an, Ressourcen aus diesen Quellen. Selbst wenn ein Angreifer ein Loch finden kann, durch das einschleusen müssen, entspricht es nicht der Zulassungsliste. ausgeführt haben.

Da wir uns darauf verlassen, dass apis.google.com gültigen Code liefert, vertrauen wir uns selbst Lassen Sie uns dazu eine Richtlinie definieren, die die Ausführung des Skripts stammt aus einer dieser beiden Quellen:

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

Wie Sie wahrscheinlich vermutet haben, ist script-src eine Anweisung, steuert eine Reihe skriptbezogener Berechtigungen für eine bestimmte Seite. Wir haben angegeben, 'self' als gültige Skriptquelle und https://apis.google.com als eine andere. Der Browser lädt JavaScript ordnungsgemäß von der apis.google.com über HTTPS sowie vom Ursprung der aktuellen Seite.

Konsolenfehler: Das Skript "http://evil.example.com/evil.js" soll nicht geladen werden da sie gegen die folgende Content Security Policy-Anweisung verstößt: script-src 'self' https://apis.google.com

Ist diese Richtlinie definiert, gibt der Browser stattdessen einfach einen Fehler aus. das Laden des Scripts aus einer anderen Quelle. Wenn es einem cleveren Angreifer gelingt, in Ihre Website einschleusen, werden sie eher zu einer Fehlermeldung weitergeleitet, als der erwartete Erfolg.

Die Richtlinie gilt für eine Vielzahl von Ressourcen

Auch wenn Skriptressourcen die offensichtlichsten Sicherheitsrisiken darstellen, bietet die CSP zahlreiche eine Reihe von Richtlinienanweisungen, die eine relativ detaillierte Kontrolle über die Ressourcen ermöglichen dass eine Seite geladen werden darf. Du hast script-src schon gesehen. Das Konzept sollte klar sein.

Gehen wir kurz die übrigen Ressourcenanweisungen durch. In der Liste unten stellt den Status der Anweisungen auf Ebene 2 dar. Eine Spezifikation der Stufe 3 wurde veröffentlicht, ist aber in den Hauptversionen weitgehend nicht implementiert. Browser.

  • Mit base-uri werden die URLs eingeschränkt, die im <base>-Element einer Seite angezeigt werden können.
  • child-src listet die URLs für Worker und eingebettete Frame-Inhalte auf. Für Beispiel: child-src https://youtube.com ermöglicht das Einbetten von Videos von YouTube, aber nicht von anderen Quellen.
  • connect-src schränkt die Ursprünge ein, zu denen Sie eine Verbindung herstellen können (über XHR, WebSockets und EventSource).
  • font-src gibt die Quellen an, aus denen Webschriftarten bereitgestellt werden können. Das Web von Google Schriftarten können über font-src https://themes.googleusercontent.com aktiviert werden.
  • form-action listet gültige Endpunkte für die Übermittlung von <form>-Tags auf.
  • frame-ancestors gibt die Quellen an, in die die aktuelle Seite eingebettet werden kann. Diese Anweisung gilt für <frame>-, <iframe>-, <embed>- und <applet>-Tags. Diese Anweisung kann nicht in <meta>-Tags verwendet werden und gilt nur für Nicht-HTML-Tags Ressourcen.
  • frame-src wurde in Level 2 eingestellt, wird aber in Level 3 wiederhergestellt. Falls nicht wird weiterhin wie zuvor auf child-src zurückgesetzt.
  • img-src definiert die Ursprünge, aus denen Bilder geladen werden können.
  • media-src schränkt die Quellen ein, die für die Übermittlung von Video- und Audioinhalten zulässig sind.
  • object-src ermöglicht die Steuerung von Flash und anderen Plug-ins.
  • plugin-types begrenzt die Arten von Plug-ins, die eine Seite aufrufen kann.
  • Mit report-uri wird eine URL angegeben, an die ein Browser Berichte sendet, wenn ein Content Security Policy verletzt wird. Diese Anweisung kann in <meta> nicht verwendet werden Tags.
  • style-src ist das Gegenstück für Stylesheets von script-src.
  • upgrade-insecure-requests weist User-Agents an, URL-Schemas umzuschreiben. von HTTP zu HTTPS geändert. Diese Anweisung gilt für Websites mit einer großen Anzahl die neu geschrieben werden müssen.
  • worker-src ist eine CSP-Anweisung der Stufe 3, mit der die URLs eingeschränkt werden, als Worker, freigegebener Worker oder Service Worker geladen werden. Seit Juli 2017 hat eine eingeschränkte Implementierungen.

Standardmäßig sind Anweisungen weit offen. Wenn Sie für eine Beispiel: font-src, verhält sich diese Anweisung standardmäßig wie obwohl Sie * als gültige Quelle angegeben haben (Sie könnten z. B. Schriftarten aus überall und uneingeschränkt).

Sie können dieses Standardverhalten überschreiben, indem Sie einen default-src angeben. . Mit dieser Anweisung werden die Standardwerte für die meisten Anweisungen, die Sie nicht angeben. Im Allgemeinen gilt dies für alle Anweisungen, die endet mit -src. Wenn default-src auf https://example.com gesetzt ist und Sie fehlschlagen font-src-Anweisung verwenden, können Sie Schriftarten aus nur https://example.com. Wir haben in unserer Tabelle nur script-src angegeben vorherigen Beispielen, was bedeutet, dass Bilder, Schriftarten usw. aus irgendwoher.

default-src wird in den folgenden Anweisungen nicht als Fallback verwendet. Denken Sie daran: wenn sie nicht festgelegt werden, ist es gleichbedeutend, alles zuzulassen.

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

Sie können so viele oder so wenige dieser Anweisungen verwenden, wie für Ihre Anwendung finden, indem ihr sie einfach im HTTP-Header auflistet mit Semikolons. Achten Sie darauf, alle erforderliche Ressourcen eines bestimmten Typs in einer einzelnen Anweisung enthalten. Wenn Sie geschrieben haben, etwa script-src https://host1.com; script-src https://host2.com die die zweite Anweisung, wird einfach ignoriert. In etwa müssen beide Ursprünge korrekt als gültig sein:

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

Wenn Sie z. B. eine Anwendung haben, die alle ihre Ressourcen aus einer (z. B. https://cdn.example.net) und wissen, dass Sie keine geframeten Inhalte oder Plug-ins benötigen, etwa so:

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

Implementierungsdetails

Sie sehen die Header X-WebKit-CSP und X-Content-Security-Policy in verschiedenen Tutorials finden. Sie sollten diese Präfixe in Zukunft ignorieren. Header. Moderne Browser (mit Ausnahme von IE) unterstützen die Methode ohne Präfix Content-Security-Policy-Header. Das ist die Überschrift, die Sie verwenden sollten.

Unabhängig von der verwendeten Kopfzeile wird die Richtlinie auf Seite für Seite definiert: müssen Sie den HTTP-Header zusammen mit jeder Antwort senden, die Sie damit Ihre Daten geschützt sind. Das bietet ein hohes Maß an Flexibilität, da Sie Ihre für bestimmte Seiten entsprechend ihren Anforderungen anpassen. Vielleicht eine Reihe von auf Ihrer Website eine +1-Schaltfläche hat, andere dies jedoch nicht: Sie könnten den nur bei Bedarf geladen werden.

Die Quellenliste in den einzelnen Anweisungen ist flexibel. Sie können Quellen angeben, indem Sie Schema (data:, https:) oder eine Angabe mit einer Genauigkeit von „Nur Hostname“ (example.com, was jedem Ursprung auf diesem Host entspricht: jedes Schema, jeder Port) zu Ein voll qualifizierter URI (https://example.com:443, der nur mit HTTPS übereinstimmt, nur example.com und nur Port 443). Platzhalter werden akzeptiert, aber nur als Schema, einen Port oder an der Position ganz links im Hostnamen: *://*.example.com:* würde Übereinstimmung mit allen Subdomains von example.com (aber nicht von example.com selbst) mit in jedem Schema auf jedem Port verwenden.

Die Quellenliste akzeptiert außerdem vier Keywords:

  • Für 'none' liegen keine Übereinstimmungen vor.
  • 'self' stimmt mit dem aktuellen Ursprung überein, aber nicht mit seinen Subdomains.
  • In 'unsafe-inline' ist Inline-JavaScript und -CSS zulässig. (Wir kommen später noch etwas genauer erläutern.)
  • 'unsafe-eval' ermöglicht Text-in-JavaScript-Mechanismen wie eval. (Wir erhalten hinzufügen.)

Diese Keywords erfordern einfache Anführungszeichen. Beispiel: script-src 'self' (mit Anführungszeichen) autorisiert die Ausführung von JavaScript vom aktuellen Host aus; script-src self (keine Anführungszeichen) erlaubt JavaScript von einem Server namens "self" (und nicht aus dem aktuellen Host), was wahrscheinlich nicht das ist, was Sie gemeint haben.

Sandbox-Technologie

Es gibt noch eine weitere Anweisung, über die wir gesprochen werden sollten: sandbox. Es ist ein wenig von denen, die wir uns angesehen haben, sind, da hier Aktionen eingeschränkt werden, statt Ressourcen, die geladen werden können. Wenn die sandbox-Anweisung vorhanden ist, wird die Seite so behandelt, als wäre sie geladen worden innerhalb einer <iframe> mit einem sandbox-Attribut. Dies kann viele verschiedene Auswirkungen auf die Seite: Erzwingen einer eindeutigen Quelle für die Seite und Verhindern von Formularen zu übermitteln. Das würde den Rahmen dieses Artikels sprengen, aber Sie umfassende Details zu gültigen Sandboxing-Attributen finden Sie „Sandbox-Technologie“ der HTML5-Spezifikation.

Das Meta-Tag

Der bevorzugte Übermittlungsmechanismus von CSPs ist ein HTTP-Header. Es kann jedoch nützlich sein, , um direkt im Markup eine Richtlinie auf einer Seite festzulegen. Dazu verwenden Sie ein <meta>-Tag mit ein http-equiv-Attribut:

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

Dies kann nicht für frame-ancestors, report-uri oder sandbox verwendet werden.

Inline-Code gilt als schädlich

Es sollte deutlich werden, dass die CSP auf den Ursprüngen der Zulassungsliste basiert, da dies eine eindeutige Methode, den Browser anzuweisen, bestimmte Ressourcengruppen zu verarbeiten und den Rest ablehnen. ursprungsbasierte Zulassungslisten hingegen lösen Sie jedoch die größte Bedrohung durch XSS-Angriffe: Inline-Script-Injection. Wenn ein Angreifer ein Skript-Tag einschleusen kann, das direkt schädliche Nutzlast (<script>sendMyDataToEvilDotCom();</script>), verfügt der Browser über keinen Mechanismus, um diesen von einem legitimen Inline-Skript-Tags. Die CSP löst dieses Problem, indem Inline-Skripts vollständig gesperrt werden: ist das die einzige Möglichkeit.

Diese Sperre gilt nicht nur für Skripts, die direkt in script-Tags eingebettet sind, Inline-Event-Handler und javascript:-URLs. Sie müssen den Inhalt der script-Tags in eine externe Datei und ersetzen Sie javascript:-URLs und <a ... onclick="[JAVASCRIPT]"> durch entsprechende addEventListener()-Aufrufe. Beispiel: könnten Sie Folgendes umformulieren aus:

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

in etwa so aussehen:

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

Der umgeschriebene Code hat eine Reihe von Vorteilen, die über die gute CSP; unabhängig von der Nutzung der CSP bereits bewährt wurde. Inline-Anzeige JavaScript vermischt Struktur und Verhalten auf genau die Art und Weise, wie Sie es nicht tun sollten. Externe Ressourcen können von Browsern einfacher im Cache gespeichert werden und sind für und kompilieren und komprimieren. Bessere Texte verfassen wenn Sie Code in externe Ressourcen verschieben.

Inline-Stile werden gleich behandelt: Das Attribut style und style sollten in externen Stylesheets konsolidiert werden, um Überraschend clever Methoden zur Daten-Exfiltration, die CSS ermöglicht.

Wenn Sie Inline-Script und -stil benötigen, können Sie diese Funktion aktivieren Fügen Sie dazu 'unsafe-inline' als zulässige Quelle in einem script-src- oder style-src-Element hinzu . Sie können auch eine Nonce oder einen Hash verwenden (siehe unten), sollten das aber unbedingt tun. Das Sperren von Inline-Script ist der größte Sicherheitsgewinn, den CSP bietet, und Durch das Sperren von Inline-Style wird Ihre Anwendung ebenfalls gehärtet. Es ist ein wenig um sicherzustellen, dass alles ordnungsgemäß funktioniert, nachdem der gesamte Code aber das ist ein Kompromiss, denen es wert ist.

Wenn Sie es unbedingt verwenden müssen

CSP Level 2 bietet Abwärtskompatibilität für Inline-Skripts, da Sie Folgendes tun können: bestimmte Inline-Skripts mit einer kryptografischen Nonce (Nummer einmal verwendet) oder ein Hash. Das mag umständlich sein, ist aber nützlich, knacken.

Wenn Sie eine Nonce verwenden möchten, müssen Sie Ihrem Script-Tag ein Nonce-Attribut zuweisen. Der Wert muss mit eins übereinstimmen in der Liste der vertrauenswürdigen Quellen. Beispiel:

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

Fügen Sie nun die Nonce der script-src-Anweisung hinzu, die an das Keyword nonce- angehängt wird.

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

Nonces müssen für jede Seitenanforderung neu generiert werden die nicht zu erraten sind.

Hashes funktionieren fast auf die gleiche Weise. Anstatt dem Skript-Tag Code hinzuzufügen, Erstellen Sie einen SHA-Hash-Wert des Skripts selbst und fügen Sie ihn der script-src-Anweisung hinzu. Nehmen wir beispielsweise an, Ihre Seite enthielt Folgendes:

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

Ihre Richtlinie würde Folgendes enthalten:

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

Hier sind einige Dinge zu beachten. Das Präfix sha*- gibt den Algorithmus an der den Hash generiert. Im obigen Beispiel wird sha256- verwendet. CSP unterstützt sha384- und sha512-. Geben Sie beim Generieren des Hash-Werts nicht den Parameter <script>-Tags. Auch Groß- und Kleinschreibung sowie Leerzeichen sind von Bedeutung, Leerzeichen am Zeilenende.

Eine Google-Suche zum Generieren von SHA-Hashes führt Sie zu Lösungen in Sprachen verfügbar. In Chrome 40 oder höher können Sie die Entwicklertools öffnen und aktualisieren Sie die Seite. Der Tab mit der Konsole enthält Fehlermeldungen sha256-Hash für jedes Inline-Script.

Auch bewerten

Auch wenn ein Angreifer das Skript nicht direkt einschleusen kann, könnte er Umwandlung von ansonsten inaktivem Text in ausführbares JavaScript und führt es in ihrem Namen aus. eval(), neu Function() , setTimeout([string], ...) und setInterval([string], ...) sind alle Vektoren, über die führt möglicherweise zu unerwartet schädlichen Inhalten. CSP-Standardeinstellung als Reaktion auf dieses Risiko besteht darin, alle diese Vektoren vollständig zu blockieren.

Dies hat mehr als nur einige Auswirkungen auf die Art und Weise, wie Sie Anwendungen erstellen:

  • Sie müssen JSON über die integrierte JSON.parse parsen, anstatt sich auf eval. Native JSON-Vorgänge sind verfügbar in alle Browser seit IE8 und sie sind auf der sicheren Seite.
  • Alle setTimeout- oder setInterval-Anrufe umschreiben, die du gerade machst mit Inline-Funktionen anstelle von Strings. Beispiel:
setTimeout("document.querySelector('a').style.display = 'none';", 10);

besser geschrieben als:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);
  • Vermeiden Sie Inline-Vorlagen zur Laufzeit: Viele Vorlagenbibliotheken verwenden new Function() großzügig, um die Vorlagenerstellung während der Laufzeit zu beschleunigen. Es ist ein Anwendung der dynamischen Programmierung, birgt jedoch das Risiko, schädliche Texte bewerten. Einige Frameworks unterstützen CSP sofort, auf einen robusten Parser zurückgreifen, falls eval nicht vorhanden ist. ng-csp-Anweisung von AngularJS ist ein gutes Beispiel dafür.

Eine bessere Wahl wäre jedoch eine Vorlagensprache, Vorkompilierung (Handlebars tut, . Durch Vorkompilierung der Vorlagen wird die User Experience sogar noch schneller als die schnellste Laufzeitimplementierung. Außerdem ist es sicherer. Wenn eval und die Text-in-JavaScript-Bibliothek für Ihre Anwendung essenziell sind, können Sie Aktivieren Sie sie, indem Sie 'unsafe-eval' als zulässige Quelle in einer script-src hinzufügen. Wir raten jedoch dringend davon ab. Ausführung von Aktionen sperren Zeichenfolgen erschweren es Angreifern, nicht autorisierte Aktionen Code auf Ihrer Website.

Berichterstellung

Die Fähigkeit der CSP, nicht vertrauenswürdige Ressourcen clientseitig zu blockieren, ist ein großer Vorteil für Ihr Es wäre aber hilfreich, eine Art Benachrichtigung zu erhalten, an den Server zurückgesendet, damit Sie Fehler, die eine schädliche Injektion an. Zu diesem Zweck können Sie das Browser wird POST Verstoß im JSON-Format an einen Standort gemeldet in einer report-uri-Anweisung angegeben ist.

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

Diese Berichte sehen in etwa so aus:

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

Darin finden Sie viele nützliche Informationen, Die spezifische Ursache des Verstoßes, einschließlich der Seite, auf der der Verstoß vorliegt (document-uri), die Referrer-URL dieser Seite. Beachten Sie, dass im Gegensatz zur HTTP- Header eingegeben wurde, ist der Schlüssel nicht falsch geschrieben), die Ressource, die gegen Richtlinie der Seite (blocked-uri), die spezifische Anweisung, gegen die sie verstoßen hat (violated-directive) und die vollständige Richtlinie der Seite (original-policy).

Nur Bericht

Wenn Sie gerade erst mit der CSP beginnen, ist es sinnvoll, die aktuellen bevor Sie eine drakonische Richtlinie für Ihre Nutzer einführen. Als Sprungbrett für eine vollständige Einrichtung können Sie den Browser bitten, einer Richtlinie, die Verstöße melden, aber die Einschränkungen nicht durchsetzen. Anstelle von Content-Security-Policy-Header senden, senden Sie einen Content-Security-Policy-Report-Only-Header.

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

Durch die Richtlinie, die im Modus „Nur Berichterstellung“ festgelegt ist, werden keine eingeschränkten Ressourcen blockiert, aber werden Berichte über Verstöße an den von Ihnen angegebenen Standort gesendet. Sie können sogar beiden Headern und setzt dabei eine Richtlinie durch, während eine andere überwacht wird. Das ist ein großartiger So können Sie die Auswirkungen von Änderungen an der CSP Ihrer Anwendung bewerten: Aktivieren zu melden, die Verstöße zu überwachen und Fehler zu beheben, lauter machen; Wenn Sie mit den Auswirkungen zufrieden sind, können Sie mit der Durchsetzung der neuen Richtlinie beginnen.

Nutzung in der Praxis

CSP 1 lässt sich in Chrome, Safari und Firefox recht gut verwenden, hat aber nur IE 10 unterstützt. Sie können ausführliche Informationen finden Sie auf caniuse.com. CSP-Level 2 ist seitdem in Chrome verfügbar Version 40. Große Websites wie Twitter und Facebook haben den Header bereitgestellt. (Die Fallstudie von Twitter ist eine Lektüre wert) und der Standard ist bereits damit Sie mit der Bereitstellung auf Ihren eigenen Websites beginnen können.

Der erste Schritt zur Erstellung einer Richtlinie für Ihre Anwendung besteht darin, die die tatsächlich geladen werden. Wenn Sie der Meinung sind, dass Sie in Ihrer App zusammengestellt haben, richten Sie auf dieser Grundlage eine Richtlinie ein, Anforderungen. Sehen wir uns einige häufige Anwendungsfälle innerhalb der Datenschutzgrenzen der CSP am besten unterstützt werden.

Anwendungsfall 1: Social-Media-Widgets

  • +1-Schaltfläche von Google enthält ein Skript aus https://apis.google.com und bettet eine <iframe> von https://plusone.google.com Sie benötigen eine Richtlinie, die beides enthält mit dem Sie die Schaltfläche einbetten können. Eine Mindestrichtlinie wäre script-src https://apis.google.com; child-src https://plusone.google.com. Außerdem benötigen Sie damit das von Google bereitgestellte JavaScript-Snippet eine externe JavaScript-Datei. Wenn Sie eine Richtlinie der Ebene 1 mit frame-src hatten Bei Ebene 2 musste es in child-src geändert werden. Dies ist nicht mehr erforderlich in CSP-Level 3.

  • Gefällt mir-Schaltfläche von Facebook bietet eine Reihe von Implementierungsoptionen. Sie sollten sich an die <iframe>-Version, da sie sicher in einer Sandbox vom Rest Ihrer Website ausgeführt wird. Es Für eine korrekte Funktionsweise ist eine child-src https://facebook.com-Anweisung erforderlich. Hinweis dass der von Facebook bereitgestellte <iframe>-Code standardmäßig ein relatives URL, //facebook.com. Ändern Sie die Einstellung, um HTTPS explizit anzugeben: https://facebook.com Wenn es notwendig ist, gibt es keinen Grund, HTTP zu verwenden.

  • Tweet-Schaltfläche von Twitter Zugriff auf ein Skript und einen Frame, die beide https://platform.twitter.com Twitter stellt ebenfalls eine relative URL zur Verfügung, default; beim lokalen Kopieren/Einfügen den Code so ändern, dass HTTPS angegeben wird.) Sie können mit script-src https://platform.twitter.com; child-src https://platform.twitter.com fertig sein, solange Sie das JavaScript-Snippet verschieben. die Twitter in einer externen JavaScript-Datei bereitstellt.

  • Andere Plattformen haben ähnliche Anforderungen und können auf ähnliche Weise angegangen werden. Wir empfehlen, default-src von 'none' festzulegen und die Konsole auf ermitteln, welche Ressourcen aktiviert werden müssen, damit die Widgets funktionieren.

Es ist ganz einfach, mehrere Widgets einzubinden: Kombiniere einfach die Richtlinien. alle Ressourcen eines Typs in einer einzigen . Wenn Sie alle drei Social-Media-Widgets nutzen möchten, wie hier:

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

Anwendungsfall 2: Sperren

Nehmen wir für einen Moment an, dass Sie eine Bank-Website betreiben und sicherstellen möchten, dass können nur die Ressourcen geladen werden, die Sie selbst geschrieben haben. In diesem Szenario Beginnen Sie mit einer Standardrichtlinie, die absolut alles blockiert (default-src 'none'), und bauen Sie darauf auf.

Die Bank lädt alle Bilder, Stile und Skripts aus einem CDN, https://cdn.mybank.net und verbindet sich über XHR mit https://api.mybank.com/ nach verschiedene Datenelemente herunterziehen. Frames werden verwendet, aber nur für Seiten in der Nähe des Website (keine Drittanbieterquellen). Es gibt weder Flash noch Schriftarten Extras. Der restriktivste CSP-Header, den wir senden könnten, lautet:

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'

Anwendungsfall 3: Nur SSL

Ein Administrator eines Ehering-Diskussionsforums möchte sicherstellen, dass alle Ressourcen nur über sichere Kanäle geladen, aber nicht wirklich viel Code schreibt; umformulieren der Forensoftware von Drittanbietern, die so umfangreich sind, Inline-Skript und Inline-Style überschreiten seine Fähigkeiten. Die folgende Richtlinie wäre effektiv:

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

Obwohl https: in default-src angegeben ist, werden das Skript und der Stil erben nicht automatisch diese Quelle. Jede Anweisung vollständig überschreibt den Standardwert für diesen spezifischen Ressourcentyp.

Die Zukunft

Content Security Policy Level 2 ist ein Kandidatenempfehlung. Arbeitsgruppe zur Sicherheit von Webanwendungen des W3C an der nächsten Iteration der Spezifikation begonnen hat, Content Security Policy Level 3

Wenn Sie an der Diskussion über diese neuen Funktionen interessiert sind, überfliegen Sie die Archive der Mailingliste "public-appsec@", oder schließen Sie sich selbst an.

Feedback