Mit einer Content Security Policy (CSP) können Sie dafür sorgen, dass alle auf der Seite geladenen Inhalte vom Websiteinhaber als vertrauenswürdig eingestuft werden. CSPs verhindern Cross-Site-Scripting-Angriffe (XSS), da sie unsichere Skripts blockieren können, die von Angreifern eingeschleust werden. Die CSP kann jedoch leicht umgangen werden, wenn sie nicht streng genug ist. Weitere Informationen finden Sie unter Cross-Site-Scripting (XSS) mit einer strengen Content Security Policy (CSP) verhindern. Lighthouse erfasst CSPs, die im Hauptdokument erzwungen werden, und meldet Probleme vom CSP-Evaluator, wenn sie umgangen werden können.
<ph type="x-smartling-placeholder">
Erforderliche Praktiken für eine nicht umgehbare CSP
Implementieren Sie die folgenden Vorgehensweisen, damit Ihre CSP nicht umgangen werden kann. Wenn die CSP umgangen werden kann, gibt Lighthouse eine Warnung mit hohem Schweregrad aus.
CSP-Ziele XSS
Für ein Targeting auf XSS sollte eine CSP die Anweisungen script-src, object-src und base-uri enthalten. Die CSP sollte außerdem frei von Syntaxfehlern sein.
script-src und object-src schützen eine Seite vor unsicheren Skripts bzw. unsicheren Plug-ins. Alternativ kann default-src verwendet werden, um eine umfassende Richtlinie anstelle von vielen Anweisungen wie script-src und object-src zu konfigurieren.
base-uri verhindert das Einschleusen nicht autorisierter <base>-Tags, mit denen alle relativen URLs (z. B. Skripts) an eine von Angreifern kontrollierte Domain weitergeleitet werden können.
Die CSP verwendet Nonces oder Hashes, um zu vermeiden, dass Zulassungslisten umgangen werden
Eine CSP, die eine Zulassungsliste für script-src konfiguriert, geht davon aus, dass alle Antworten von einer vertrauenswürdigen Domain sicher sind und als Scripts ausgeführt werden können. Diese Annahme gilt jedoch nicht für moderne Anwendungen. Einige gängige, harmlose Muster wie das Offenlegen von JSONP-Schnittstellen und Hostingkopien der AngularJS-Bibliothek ermöglichen es Angreifern, die Grenzen der CSP zu umgehen.
Auch wenn es für Anwendungsautoren nicht offensichtlich ist, können die meisten script-src-Zulassungslisten von einem Angreifer mit einem XSS-Fehler umgangen werden und bieten wenig Schutz vor Script-Injection. Im Gegensatz dazu treten bei den nonce-basierten und hashbasierten Ansätzen diese Probleme nicht auf und sie erleichtern die Einführung und Pflege einer sichereren Richtlinie.
In diesem Code wird beispielsweise ein JSONP-Endpunkt verwendet, der auf einer vertrauenswürdigen Domain gehostet wird, um ein von Angreifern kontrolliertes Skript einzufügen:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Um eine Umgehung zu vermeiden, sollte eine CSP Scripts einzeln zulassen, die Nonces oder Hashes verwenden, und „strict-dynamic“ verwenden. statt auf eine Zulassungsliste.
Zusätzliche Empfehlungen für eine sichere CSP
Implementieren Sie die folgenden Best Practices, um die Sicherheit und Kompatibilität zu erhöhen. Wenn die CSP eine der Empfehlungen nicht befolgt, gibt Lighthouse eine Warnung mit mittlerem Schweregrad aus.
CSP-Berichterstellung konfigurieren
Wenn Sie ein Ziel für die Berichterstellung konfigurieren, können Sie Fehler leichter im Blick behalten. Sie können das Ziel für die Berichterstellung mit der Anweisung report-uri oder report-to festlegen. report-to wird derzeit nicht von allen modernen Browsern unterstützt. Es wird daher empfohlen, beide oder nur report-uri zu verwenden.
Wenn Inhalte gegen die CSP verstoßen, sendet der Browser eine Meldung an das konfigurierte Ziel. Stellen Sie sicher, dass an diesem Ziel eine Anwendung konfiguriert ist, die diese Berichte verarbeitet.
CSP in einem HTTP-Header definieren
Eine CSP kann in einem Meta-Tag so definiert werden:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Sie sollten jedoch nach Möglichkeit eine CSP in einem HTTP-Antwortheader definieren. Eine Einschleusung vor dem Meta-Tag umgeht die CSP. Außerdem werden frame-ancestors, sandbox und Berichte in Meta-Tag-CSPs nicht unterstützt.
Achten Sie darauf, dass die CSP abwärtskompatibel ist
Nicht alle Browser unterstützen CSP-Nonces/-Hashes. Wir empfehlen daher, unsafe-inline als Fallback für nicht konforme Browser hinzuzufügen. Wenn der Browser Nonces/Hashes unterstützt, wird unsafe-inline ignoriert.
Ebenso wird strict-dynamic nicht von allen Browsern unterstützt. Es wird empfohlen, eine Zulassungsliste als Fallback für nicht konforme Browser festzulegen. Die Zulassungsliste wird in Browsern ignoriert, die strict-dynamic unterstützen.
Strenge CSP entwickeln
Im Folgenden finden Sie ein Beispiel für die Verwendung einer strikten CSP mit einer Nonce-basierten Richtlinie.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 wäre ein beliebiger serverseitig generierter Base64-String, wenn die Seite geladen wird. unsafe-inline und https: werden in modernen Browsern aufgrund der Nonce und strict-dynamic ignoriert. Weitere Informationen zur Implementierung einer strikten CSP finden Sie im Leitfaden zu strikten CSPs.
Mit Lighthouse und CSP-Evaluator können Sie eine CSP auf potenzielle Umgehungen prüfen. Wenn Sie eine neue CSP testen möchten, ohne die Gefahr von Problemen mit vorhandenen Seiten zu bestehen, definieren Sie die CSP im Berichtsmodus, indem Sie Content-Security-Policy-Report-Only als Headernamen verwenden. Dadurch werden CSP-Verstöße an alle Berichtsziele gesendet, die Sie mit report-to und report-uri konfiguriert haben. Die CSP wird aber nicht tatsächlich erzwungen.