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](https://developer.chrome.com/static/docs/privacy-security/csp/image/console-error-refused-l-524026adbb83a.png?authuser=9&hl=de)
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 überfont-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 aufchild-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 vonscript-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 wieeval
. (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 aufeval
. Native JSON-Vorgänge sind verfügbar in alle Browser seit IE8 und sie sind auf der sicheren Seite. - Alle
setTimeout
- odersetInterval
-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, fallseval
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>
vonhttps://plusone.google.com
Sie benötigen eine Richtlinie, die beides enthält mit dem Sie die Schaltfläche einbetten können. Eine Mindestrichtlinie wärescript-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 mitframe-src
hatten Bei Ebene 2 musste es inchild-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 einechild-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 mitscript-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.