Mit dem Content-Security-PolicyMeta-Tag können Sie das Risiko von XSS- Angriffen verringern, indem Sie festlegen, wo Ressourcen geladen werden können, und verhindern, dass Browser Daten von anderen Orten laden. Dies macht es für einen Angreifer schwieriger, schädlichen Code in Ihre Site einzufügen.
Ich schlug meinen Kopf gegen eine Mauer, um herauszufinden, warum ich nacheinander CSP-Fehler bekam, und es schien keine präzisen, klaren Anweisungen zu geben, wie das funktioniert. Hier ist mein Versuch, einige Punkte von CSP kurz zu erklären , wobei ich mich hauptsächlich auf die Dinge konzentriere, die ich schwer zu lösen fand.
Der Kürze halber werde ich nicht in jedem Beispiel das vollständige Tag schreiben. Stattdessen zeige ich nur die contentEigenschaft. Ein Beispiel mit der Aufschrift content="default-src 'self'"bedeutet Folgendes:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
1. Wie erlaube ich mehrere Quellen?
Sie können Ihre Quellen nach einer Anweisung einfach als durch Leerzeichen getrennte Liste auflisten:
content="default-src 'self' https://example.com/js/"
Beachten Sie, dass es keine anderen Anführungszeichen für Parameter als die speziellen gibt, wie z 'self'. Außerdem steht :nach der Direktive kein Doppelpunkt ( ). Nur die Direktive, dann eine durch Leerzeichen getrennte Liste von Parametern.
Alles, was unter den angegebenen Parametern liegt, ist implizit zulässig. Das bedeutet, dass im obigen Beispiel dies gültige Quellen wären:
https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js
Diese wären jedoch nicht gültig:
http://example.com/js/file.js
^^^^ wrong protocol
https://example.com/file.js
^^ above the specified path
2. Wie werden verschiedene Richtlinien verwendet, was tun sie jeweils?
Die häufigsten Richtlinien sind:
default-src Die Standardrichtlinie zum Laden von Javascript, Bildern, CSS, Schriftarten, AJAX-Anforderungen usw.script-src definiert gültige Quellen für Javascript-Dateienstyle-src definiert gültige Quellen für CSS-Dateienimg-src definiert gültige Quellen für Bilderconnect-srcDefiniert gültige Ziele für XMLHttpRequest (AJAX), WebSockets oder EventSource. Wenn ein Verbindungsversuch zu einem Host unternommen wird, der hier nicht zulässig ist, emuliert der Browser einen 400Fehler
Es gibt andere, aber diese sind diejenigen, die Sie am wahrscheinlichsten brauchen.
3. Wie verwende ich mehrere Anweisungen?
Sie definieren alle Ihre Anweisungen in einem Meta-Tag, indem Sie sie mit einem Semikolon ( ;) beenden :
content="default-src 'self' https://example.com/js/; style-src 'self'"
4. Wie gehe ich mit Ports um?
Alles außer den Standardports muss explizit zugelassen werden, indem die Portnummer oder ein Sternchen nach der zulässigen Domäne hinzugefügt wird:
content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"
Das Obige würde führen zu:
https://ajax.googleapis.com:123
^^^^ Not ok, wrong port
https://ajax.googleapis.com - OK
http://example.com/free/stuff/file.js
^^ Not ok, only the port 123 is allowed
http://example.com:123/free/stuff/file.js - OK
Wie bereits erwähnt, können Sie auch ein Sternchen verwenden, um alle Ports explizit zuzulassen:
content="default-src example.com:*"
5. Wie gehe ich mit verschiedenen Protokollen um?
Standardmäßig sind nur Standardprotokolle zulässig. Um beispielsweise WebSockets ws://zuzulassen, müssen Sie dies explizit zulassen:
content="default-src 'self'; connect-src ws:; style-src 'self'"
^^^ web sockets are now allowed on all domains and ports
6. Wie erlaube ich das Dateiprotokoll file://?
Wenn Sie versuchen, es als solches zu definieren, funktioniert es nicht. Stattdessen erlauben Sie es mit dem filesystemParameter:
content="default-src filesystem"
7. Wie verwende ich Inline-Skripte und Stildefinitionen?
Sofern nicht ausdrücklich erlaubt, können Sie keine Inline-Stildefinitionen, Code in <script>Tags oder in Tag-Eigenschaften wie verwenden onclick. Sie erlauben ihnen so:
content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"
Sie müssen auch explizit Inline-Base64-codierte Bilder zulassen:
content="img-src data:"
8. Wie erlaube ich eval()?
Ich bin sicher, dass viele Leute sagen würden, dass Sie dies nicht tun, da "Eval ist böse" und die wahrscheinlichste Ursache für das bevorstehende Ende der Welt. Diese Leute würden sich irren. Sicher, Sie können mit eval definitiv große Lücken in die Sicherheit Ihrer Site schlagen, aber es gibt absolut gültige Anwendungsfälle. Sie müssen nur klug sein, wenn Sie es verwenden. Sie erlauben es so:
content="script-src 'unsafe-eval'"
9. Was genau bedeutet 'self'das?
Sie können 'self'localhost, lokales Dateisystem oder irgendetwas auf demselben Host meinen. Es bedeutet keines davon. Dies bedeutet, dass Quellen dasselbe Schema (Protokoll), denselben Host und denselben Port wie die Datei haben, in der die Inhaltsrichtlinie definiert ist. Bereitstellen Ihrer Site über HTTP? Dann kein https für Sie, es sei denn, Sie definieren es explizit.
Ich habe 'self'in den meisten Beispielen verwendet, da es normalerweise sinnvoll ist, es aufzunehmen, aber es ist keineswegs obligatorisch. Lass es weg, wenn du es nicht brauchst.
Aber Moment mal! Kann ich es nicht einfach benutzen content="default-src *"und damit fertig sein?
Nein. Zusätzlich zu den offensichtlichen Sicherheitslücken funktioniert dies nicht wie erwartet. Obwohl einige Dokumente behaupten, dass es alles erlaubt, stimmt das nicht. Inlining oder Auswertungen sind nicht zulässig. Um Ihre Website wirklich besonders anfällig zu machen, verwenden Sie Folgendes:
content="default-src * 'unsafe-inline' 'unsafe-eval'"
... aber ich vertraue darauf, dass du es nicht wirst.
Weiterführende Literatur:
http://content-security-policy.com
http://en.wikipedia.org/wiki/Content_Security_Policy