EN

Richtlinie zur Inhaltssicherheit in der Cybersicherheit

In diesem Artikel:

Die Content Security Policy (CSP) ist ein Schutzstandard, der dazu beiträgt, Websites und Anwendungen vor verschiedenen Angriffen zu schützen, darunter Dateneinspeisung, Clickjacking und Cross-Site-Scripting-Angriffe. CSP setzt die Same-Origin-Policy um und stellt sicher, dass der Browser nur Code aus gültigen Quellen ausführt. Entwickler können genau definierte CSPs verwenden, um häufige Angriffsvektoren zu eliminieren, indem sie die Inhaltsquellen definieren. Dieser Artikel befasst sich mit einer Inhaltssicherheitsrichtlinie und damit, wie ein CSP-Header dazu beitragen kann, häufige Schwachstellen zu verhindern. 

Was ist eine Inhaltssicherheitsrichtlinie?

Richtlinien für die Inhaltssicherheit werden in HTTP-Antwort-Headern, den so genannten CSP-Headern, definiert. Die Anweisungen weisen den Browser auf vertrauenswürdige Inhaltsquellen hin und enthalten eine Liste von Quellen, die verhindert werden sollten. Darüber hinaus deklariert der Content-Security-Policy-Header Inhaltsbeschränkungen, indem er die Serverherkunft und Skript-Endpunkte angibt. 

CSP-Richtlinien fallen je nach Anwendungsfall und Inhaltsattribut in verschiedene Kategorien. Dazu gehören:

Fetch-Direktiven

Diese Direktiven geben die Quellen zum Laden bestimmter Ressourcentypen an. Zu den Fetch-Direktiven gehören:

  • child-src: definiert die Script-Quellen auf der Whitelist für den Browsing-Kontext, der in Frames und Web Workern geladen wird.
  • connect-src: legt die URLs fest, die mit Skripten geladen werden sollen
  • default-src: die Fallback-Direktive für alle Fetch-Direktiven. Diese Direktive definiert die Standard-Quellliste für andere Fetch-Direktiven.
  • object-src: definiert die zulässigen Quellen für <applet>, <embed> und <object> Elemente
  • style-src: enthält eine Liste der zulässigen Quellen für Cascading Style Sheets

Dokument-Richtlinien

Dokumentrichtlinien helfen bei der Steuerung der Eigenschaften der Arbeitsumgebung oder des Dokuments, in dem eine Richtlinie wirksam wird. Dazu gehören:

  • sandbox: bietet eine Sandbox für eine bestimmte Ressource, ähnlich wie bei Inline-Skriptelementen.
  • base-uri: legt die im Basiselement des Dokuments zulässigen URLs fest

Diese Richtlinien regeln die Stellen, an denen ein Formular eingegeben wird oder an denen das Dokument eine Navigation einleitet. Sie beinhalten:

  • form-action: legt die URLs fest, die als Ziele für die Übermittlung von Formularelementen dienen
  • frame-ancestors: schränkt die Eltern ein, die mit den Elementen <frame>, <object>, <iframe>, <applet> und <embed> in die Webseite eingebettet werden

Richtlinien für die Berichterstattung

Diese Richtlinien regeln, wie CSP-Verstöße dokumentiert und gemeldet werden. Sie umfassen:

  • report-to: löst ein Ereignis zur Verletzung der Sicherheitsrichtlinie aus
  • report-uri: eine Richtlinienanweisung, die die Client-Umgebung anweist, jeden Versuch einer Verletzung der CSP-Spezifikationen zu melden.

Andere Direktiven sind:

  • require-sri-for: erzwingt die Verwendung von Subresource Integrity (SRI) für das Stilattribut und die Seitenskriptquellen
  • trusted-types: wird verwendet, um eine Liste akzeptierter, nicht fälschbarer typisierter Werte zu spezifizieren und damit DOM-basierte XSS-Angriffe zu entschärfen
  • require-trusted-types-for: Diese Richtlinienanweisung erzwingt die trusted-types-Richtlinie für Skripte, die als Senken für DOM-basierte XSS fungieren
  • upgrade-insecure-requests: Bei Websites mit zahlreichen unsicheren Legacy-URLs weist diese Richtlinie den Browser an, jede unsichere URL so zu behandeln, als ob sie durch eine sichere HTTPS-URL ersetzt worden wäre.

Warum ist der CSP-Header für die Cybersicherheit von Bedeutung?

Ein Content-Security-Policy-Header bietet Entwicklern einen Rahmen für die Kontrolle von Berechtigungen und das Laden von Ressourcen für den Anwendungsprozess. Er trägt dazu bei, das Risiko von Angriffen zu verringern, die die Notwendigkeit des Ladens von Ressourcen in einem bösartigen Kontext ausnutzen. Mit ordnungsgemäß formulierten CSPs können die Entwickler auf einen Berichtsmechanismus zugreifen, um Sicherheitslücken, die in der Produktion ausgenutzt werden, zu erkennen und zu dokumentieren. Alle wichtigen Browser unterstützen CSPs, was den Standard-Header zu einer wesentlichen zusätzlichen Ebene der Anwendungssicherheit macht.

CSPs ermöglichen eine granulare Kontrolle über:

  • Inline-Script-Ausführung
  • die Anwendung von Inline-Styles
  • Ausführung von dynamischem Code

Schwachstellen, die Sie mit CSP verhindern können

CSPs schützen Webanwendungen vor verschiedenen Schwachstellen und Angriffen, darunter:

XSS-Angriffe

CSPs bilden die erste Verteidigungslinie gegen XSS-Angriffe, da sie die Ausführung bösartiger Skripte blockieren, die von nicht vertrauenswürdigen Quellen eingespeist werden. Um die Angriffsfläche für XSS-Angriffe zu verringern, schränken Entwickler das Laden von Ressourcen mit der script-src-Direktive „self“ ein. Diese Direktive erlaubt es der Seite nur, Skripte zu laden, die von demselben Server stammen, der die Seite hostet. Die Anweisung script-src <allowed-web-url> ermöglicht es der Seite, Skripte von einer bestimmten Domain zu laden. Neben der Whitelist für die Herkunft von Ressourcen helfen CSPs auch dabei, XSS-Angriffe mit Hashes und Nonces zu entschärfen.

Ein Nonce ist ein Zufallswert, der in der CSP angegeben wird, damit er zum Laden von Skripten in einem Tag verwendet wird. Die CSP prüft die Nonce-Match-Quellliste und stellt sicher, dass die Werte übereinstimmen; andernfalls wird das Skript ausgeführt. Eine Hash-Algo-Komponente des Inhalts eines vertrauenswürdigen Skripts kann auch in einer CSP-Direktive angegeben werden. Das Skript wird nur ausgeführt, wenn der Hash des eigentlichen Skripts mit dem Wert in der CSP-Richtlinie übereinstimmt.

Clickjacking-Angriffe

Die CSP-Direktive frame-ancestors ’self‘ regelt, dass nur Seiten mit dem exakten Ursprung die Seite der Richtlinie einrahmen können. Mit der Richtlinie frame-ancestors ’none‘ können Entwickler das Framing auch gänzlich verhindern. CSPs können zusammen mit dem X-Frame-Options-Header verwendet werden, um Clickjacking-Angriffe zu verhindern. CSPs sind effektiver, da sie die Angabe mehrerer Domänen ermöglichen. Die Richtlinie validiert auch jede externe Ressource in der übergeordneten Framehierarchie, was einen stärkeren Schutz gegen Frame-Hijacking-Angriffe ermöglicht.

Dangling Markup-Angriffe

CSPs schützen vor „Dangling Markup“-Angriffen, indem sie die Herkunft der zu ladenden Bilder auf der Seite einschränken. Die Richtlinie img-src ’self‘ erlaubt nur das Laden von Bildern aus dem exakten Ursprung. Die Direktive img-src <allowed-web-url> regelt, dass die Seite Bilder von einer bestimmten Domain lädt. Das img-Tag trägt dazu bei, Dangling-Markup-Angriffe zu verhindern, da es die Erfassung von Eingabedaten mit minimaler Benutzerinteraktion erleichtert.

Andere Angriffe, die durch CSPs abgeschwächt werden, sind Framing-Angriffe, Code-Injection-Angriffe und Cross-Site Request Forgery (CSRF).

Testen der Content-Security-Policy

Zum Testen der CSP gehört die Untersuchung des CSP-Meta-Elements Content-Security-Policy HTTP Response Header in einem Proxy-Tool. Zu den zu untersuchenden unsicheren Konfigurationen gehören:

  • Die unsafe-eval-Direktive, die die Verwendung von eval() in der Anwendung erlaubt
  • Unsafe-inline-Event-Handler, die zur Einschleusung bösartiger Inhalte in den Webserver führen können
  • Alle Ressourcen, die mit Hilfe der Wildcard (*)-Quelle von einem beliebigen Ursprung geladen werden können
  • Verwendung eines Platzhalters (*) für die frame-ancestors-Direktive, die Framing für alle Herkünfte ermöglicht
  • Sicherstellen, dass eine strenge Richtlinie für geschäftskritische Anwendungen angewendet wird

Der Sicherheitsforscher kann auch verfügbare Tools wie die Crashtest Security Suite verwenden, um die Stärke seiner Sicherheitsrichtlinien zu überprüfen. 

Beispiele für CSP-Header

Ein paar Beispiele für HTTP-Header sind:

Beschränkung des Inhalts auf den Ursprung der Website

Um sicherzustellen, dass alle Inhalte vom Ursprung der Website stammen, verwendet der Webentwickler/Administrator die Richtlinie Default-Src:

Content-Security-Policy: default-src 'self'

Aktivieren von Bildern aus beliebigen Quellen

CSP ermöglicht die Angabe mehrerer Richtlinien für eine Ressource, indem sie durch Semikolons getrennt werden. So kann der Entwickler beispielsweise festlegen, dass Benutzerinhalte Bilder beliebiger Herkunft enthalten, Audio/Video einschränken und externe Skripte von einem bestimmten vertrauenswürdigen Server laden dürfen (siehe Abbildung):

Content-Security-Policy: default-src 'self'; img-src *; media-src darwin1.com darwin2.com; script-src darwincripts.example.com

Sicherstellen, dass alle Inhalte über TLS geladen werden

Entwickler können verhindern, dass Angreifer Client-Anfragen abhören, indem sie dafür sorgen, dass der gesamte Inhalt einer Website über TLS geladen wird. Dies wird mit der unten stehenden Sicherheitsrichtlinie erreicht:

Content-Security-Policy: default-src https://darwin.site.com

Diese Richtlinie stellt sicher, dass der Server nur den Zugriff auf Dokumente zulässt, die über den Single-Origin https:darwin.site.com über HTTPS geladen werden.

Häufig gestellte Fragen

Wie füge ich CSP-Richtlinien zu meiner Website hinzu?

Es gibt zwei Möglichkeiten, CSP auf eine Webseite zu laden: das HTTP-Response-Header-Feld oder das HTML-Meta-Element. 

Die Syntax für den HTTP-Header ist ähnlich wie folgt:

Content-Security-Policy: [directive] [resource type] e.g Content-Security-Policy: default-src https:

Die Syntax für das HTML-Meta-Element wäre etwa so:

<meta http-equiv="Content-Security-Policy" content="[Richtlinie] [Ressourcentyp]"> z.B. <meta http-equiv="Content-Security-Policy" content="default-src https:">

Wie kann ich die Implementierung von CSP vereinfachen?

CSP ist ein beliebter Standard, der von den meisten Server-Frameworks und Webbrowsern unterstützt wird. Die Implementierung von CSP für ein dynamisches Webprojekt ist jedoch mühsam, so dass Webadministratoren einen CSP-Manager für eine einfachere Verwaltung der Inhaltssicherheit benötigen. Tools wie die Crashtest Security Suite ermöglichen es Entwicklern und Administratoren, Tags und Inhalte durch automatisches Scannen zu verfolgen. Die Suite umfasst eine Bestandsaufnahme und einen Kontext verschiedener Domänen, um eine Datenbank mit standardmäßigen und sicheren Inhaltsquellen zu erstellen. Der automatisierte Scanner fragt auch eine Datenbank mit blockierten Servern ab, um Angriffe von bekannten Bedrohungsakteuren zu vermeiden.

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit http://example.com
Wir scannen derzeit http://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 27/05/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Ihren Bericht anfordern
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.