Mit einer Content Security Policy (CSP) wird sichergestellt, dass alle auf der Seite geladenen Inhalte vom Websiteinhaber als vertrauenswürdig eingestuft werden. CSPs mindern 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) eindämmen. Lighthouse erfasst die CSPs, die im Hauptdokument erzwungen werden, und meldet Probleme vom CSP Evaluator, wenn sie umgangen werden können.
Erforderliche Praktiken für eine CSP, die nicht umgangen werden kann
Implementieren Sie die folgenden Best Practices, damit Ihre CSP nicht umgangen werden kann. Wenn die CSP umgangen werden kann, gibt Lighthouse eine Warnung mit hohem Schweregrad aus.
CSP zielt auf XSS ab
Für das 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 anstelle von vielen Anweisungen wie script-src und object-src verwendet werden, um eine umfassende Richtlinie zu konfigurieren.
base-uri verhindert das Einschleusen nicht autorisierter <base>-Tags, mit denen alle relativen URLs (wie Skripts) an eine von Angreifern kontrollierte Domain weitergeleitet werden können.
Die CSP verwendet Nonces oder Hashes, um das Umgehen der Zulassungsliste zu vermeiden
Ein CSP, der eine Zulassungsliste für script-src konfiguriert, geht davon aus, dass alle Antworten von einer vertrauenswürdigen Domain sicher sind und als Script ausgeführt werden können. Diese Annahme trifft jedoch nicht auf moderne Anwendungen zu. Einige gängige harmlose Muster wie die Offenlegung von JSONP-Schnittstellen und Hosting-Kopien der AngularJS-Bibliothek ermöglichen Angreifern, den Grenzen der CSP zu entkommen.
In der Praxis mag es für Anwendungsentwickler vielleicht nicht offensichtlich sein, die meisten script-src-Zulassungslisten können jedoch von einem Angreifer mit einem XSS-Fehler umgangen werden und bieten wenig Schutz vor Script-Injection. Im Gegensatz dazu treten die nonce- und Hash-basierten Ansätze nicht an diesen Problemen und erleichtern die Einführung und Verwaltung 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 einzuschleusen:
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 ein CSP Skripts einzeln zulassen, die Nonces oder Hashes verwenden, und „strict-dynamisch“ anstelle einer Zulassungsliste verwenden.
Zusätzliche Empfehlungen für einen sicheren CSP
Implementieren Sie die folgenden Vorgehensweisen, um die Sicherheit und Kompatibilität zu erhöhen. Wenn die CSP einer der Empfehlungen nicht folgt, 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 erkennen. Sie können das Ziel für die Berichterstellung mithilfe der Anweisungen report-uri oder report-to festlegen. report-to wird derzeit nicht von allen modernen Browsern unterstützt. Daher wird 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 Sie an diesem Ziel eine Anwendung konfiguriert haben, die diese Berichte verarbeitet.
CSP in einem HTTP-Header definieren
Eine CSP kann in einem Meta-Tag wie folgt 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 Injektion vor dem Meta-Tag umgeht die CSP. Außerdem werden frame-ancestors, sandbox und Berichterstellung in Meta-Tag-CSPs nicht unterstützt.
Sicherstellen, dass die CSP abwärtskompatibel ist
Nicht alle Browser unterstützen CSP-Nonces/Hashes. Daher wird empfohlen, unsafe-inline als Fallback für nicht konforme Browser hinzuzufügen. Wenn der Browser Nonces/Hashes unterstützt, wird unsafe-inline ignoriert.
Außerdem wird strict-dynamic nicht von allen Browsern unterstützt. Es wird empfohlen, für nicht konforme Browser eine Zulassungsliste als Fallback festzulegen. In Browsern, die strict-dynamic unterstützen, wird die Zulassungsliste ignoriert.
So entwickeln Sie eine strikte CSP
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 base64-String, der bei jedem Laden der Seite serverseitig generiert wird. unsafe-inline und https: werden in modernen Browsern aufgrund der Nonce und strict-dynamic ignoriert. Weitere Informationen zur Verwendung einer strikten CSP finden Sie im Leitfaden für strikte CSPs.
Sie können einen CSP mit Lighthouse und dem CSP Evaluator auf mögliche Umgehungen prüfen. Wenn Sie eine neue CSP testen möchten, ohne dass vorhandene Seiten beeinträchtigt werden, definieren Sie die CSP im „Nur Bericht“-Modus und verwenden Sie Content-Security-Policy-Report-Only als Headernamen. Dadurch werden CSP-Verstöße an alle Berichtsziele gesendet, die Sie mit report-to und report-uri konfiguriert haben. Die CSP wird jedoch nicht erzwungen.