IT Security in Web Anwendungen VIII – Content Security Policy (CSP) und Cross-Origin Resource Sharing (CORS)

Doğan Uçar

In dem achten Teil der Blogserie „IT Security in Web Anwendungen“ gehen wir tiefer auf Content Security Policy (kurz: CSP) und Cross-Origin Resource Sharing (CORS) ein. Anhand konkreter Beispiele wollen wir die wichtigsten Punkte im Bezug auf IT-Security im Bezug auf CSP und CORS aufzeigen und Best Practices auflisten.

In unserem ersten Post dieser Blogserie sind wir das Thema „Injections“ angegangen und haben gezeigt, wie diese zustandekommen bzw. zu verhindern sind. In dem zweiten Teil der Serie sind wir auf  File Up-/Download und Storage eingegangen und haben allgemeine Sicherheitsrisiken sowie Prävention und Alternativen aufgelistet. In dem dritten Teil thematisieren wir Sessions und Session Hijacking-Attacken sowie einen möglichen Schutz gegen solcher Attacken. Der vierte Teil thematisierte das HTTP(S)-Protokoll im Allgemeinen und ist auf sicherheitsrelevante Aspekte eingegangen. In dem fünften Teil beschäftigten wir uns mit Datenbanken und wie man sicher mit ihnen kommuniziert, der sechste Teil addressierte das Thema „IT-Security in Web-Server“ und der siebte Teil ging näher auf Cross-Site Request Forgery (kurz: CSRF) ein.

Alle Posts dieser Blogserie sind unabhängig voneinander und das Lesen der vorherigen Posts ist keine Voraussetzung. Zu dem besseren Verständnis zu dem Thema „IT-Security“ empfehlen wir jedoch bei Post #1 anzufangen. Da alle vorangegangenen Posts im Web-Umfeld thematisiert werden, ist es empfehlenswert zumindest die Grundkenntnisse zu haben.

In den vergangenen Posts der Blogserie haben wir uns tiefergehend mit den verschiedenen Bereichen der IT Security beschäftigt. In insgesamt neun Blogposts möchten gehen wir auf verschiedene Szenarien ein, präsentieren mögliche Schutzmechanismen und demonstrieren diese – wenn möglich – durch praxisnahe Beispiele. Nach Blogpost #9 werden wir diese Serie und weitere Tipps und Tricks als PDF zur Verfügung stellen. Sie können sich unter dem nachfolgenden Formular zum Newsletter anmelden, um das PDF zu erhalten:

[newsletters_subscribe form=3]

CORS und CSP zum Schutz von Webanwendungen
CORS und CSP zum Schutz von Webanwendungen – Bild: Pawel Czerwinski/@Unsplash

Sicherheit ist ein entscheidender Faktor bei der Entwicklung von Webanwendungen. Zwei wichtige Sicherheitsmechanismen, die bei der Entwicklung von Webanwendungen berücksichtigt werden sollten, sind Cross-Origin Resource Sharing (CORS) und Content Security Policy (CSP). Diese Mechanismen helfen, Webanwendungen vor verschiedenen Arten von Angriffen zu schützen, einschließlich Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF) – auf die letzten beiden Bedrohungen sind wir in #1 und #7 eingegangen.

Was ist Cross-Origin Resource Sharing (CORS)

CORS ermöglicht dem Server Clients aus anderen Domänen, bestimmte Ressourcen zur Verfügung zu stellen („Cross-Origin-Request“). Moderne Webbrowser blockieren i.d.R. „Cross-Origin“-Anfragen – also Anfragen an eine Webanwendung, die sich in einer anderen Domäne befindet. Dies ist als Sicherheitsmechanismus in nahezu allen modernen Browsern implementiert. Durch CORS ermöglicht der Server, Ressourcen über HTTP auch für Clients anderer Domäne zur Verfügung zu stellen. Dabei kann entschieden werden, ob bspw. nur einige HTTP-Header oder -Methoden erlaubt sind.

CORS-Sicherheitsrichtlinien werden vom Server in der HTTP-Antwort angegeben und umfassen die zulässigen Domänen, von denen Anfragen akzeptiert werden sollen. Diese können entweder global für alle Ressourcen auf dem Server oder speziell für bestimmte Ressourcen definiert werden.

Angenommen, wir haben eine Webanwendung auf der Domain „www.dev.null“, die auf eine API auf der Domain „api.dev.null“ zugreifen muss. Ohne einer gültigen CORS-Richtlinie würde der Browser die Anfrage blockieren, da sie die Subdomain als andere Domäne gewertet und somit abgelehnt wird.

Um dieses Problem zu lösen, kann die API auf „api.dev.null“ CORS aktivieren und angeben, dass Anforderungen von der Domäne „www.dev.null“ zulässig sind. Zu diesem Zweck kann der Server die folgende HTTP-Antwort zurückgeben:

Access-Control-Allow-Origin: www.dev.null

Diese Antwort teilt dem Webbrowser mit, dass Anfragen von der Domäne „www.dev.null“ zulässig sind und Ressourcen von der API unter „api.dev.null“ abgerufen werden können. Doch Vorsicht! Auch das www in der Domäne zählt!

Definition Content Security Policy (CSP)

Auf der anderen Seite ist Content Security Policy (kurz: CSP) der als Sicherheitsmechanismus einer Webanwendung erlaubt, den Inhalt von geladenen Ressourcen zu kontrollieren und zu überwachen. Dieser Mechanismus eignet sich insbesondere um Cross-Site-Scripting (kurz: XSS)-Angriffe zu verhindern.

Eine CSP-Richtlinie wird von dem Server in dem HTTP-Header festgelegt und listet auf, welche Ressourcen aus welchen Quellen geladen werden dürfen. Die nachfolgend unvollständige Liste an Richtlinie kann genutzt werden:

  • self: setzt fest, dass die geladene Ressource nur an die selbe Domäne geladen wird, in der die Webanwendung gehostet wird.
  • unsafe-inline: erlaubt Inline-Skripte – dies gilt als unsicher und sollte mit Vorsicht eingesetzt werden.
  • unsafe-eval: erlaubt gefährliche Funktionen wie eval(). Dies ist ebenfalls unsicher und von dem Einsatz ist dringend abzuraten.

In der Praxis könnte der Einsatz von CSP wie folgt aussehen: Angenommen, eine Webanwendung wird unter „www.dev.null“ gehostet und versucht ein Skript von einer fremden Domän „cdn.null.dev“ herunterzuladen. Um sicherzustellen, dass das Skript nicht aus einer ungewollten Quelle stammt, kann eine CSP-Richtlinie definiert werden, die das Laden von Skripten explizit nur für „cdn.null.dev“ erlaubt:

Content-Security-Policy: script-src 'self' cdn.null.dev;

Wird versucht ein Skript von einer anderen Quelle herunterzuladen, blockiert der Browser das Laden des Skripts.

Was sollte bei CORS und CSP beachtet werden?

Die vorangegangenen Beispiele zeigen, wie CORS und CSP effektiv eingesetzt werden können, um die Sicherheit von Webanwendungen zu erhöhen, indem der Zugriff auf Ressourcen streng kontrolliert wird. Nachfolgend möchten wir noch ein paar nützliche Tipps zu dem Einsatz von CORS und CSP geben:

  1. Erstellen und Pflegen Sie Whitelists: Erlauben Sie nur bestimmten Domänen den Zugriff auf Ihre Resourcen. Reviewen Sie diese Liste in bestimmten Zeitabständen und entfernen Sie Domäne, die nicht mehr aktuell sind.
  2. „Weniger ist Mehr“: Verwenden Sie strenge CSP-Richtlinien, um das Risiko von unseriösen und böswilligen Angreifern zu minimieren. Vermeiden Sie um jeden Preis den den Einsatz von Inline-Skripten und Eval-Funktionen. Reviewen Sie die Richtlinien in bestimmten Zeitabständen und aktualisieren Sie sie falls nötig.
  3. Aktivieren Sie den Berichtsmodus: Aktivieren Sie den Berichtsmodus für CSP, um Berichte über Richtlinienverletzungen zu erhalten. Diese Berichte können helfen, Angriffe zu erkennen und Gegenmaßnahmen zu ergreifen.
  4. Testen Sie Ihre Implementierung: Tools wie OWASP Zed Attack Proxy (ZAP) oder das Content Security Policy Test Tool von Google helfen, Ihre Richtlinien und Implementierungen zu prüfen.

CORS und CSP können zur Erhöhung Ihres Sicherheitstandards beitragen und Sie vor verschiedenen Arten von Angriffen schützen. Denken Sie jedoch daran, dass es keine absolute Sicherheit gibt, und dass es daher wichtig ist, sie regelmäßig zu überprüfen und zu aktualisieren, um auf neue Bedrohungen zu reagieren.

IT Security mit Ucar Solutions

Sie sind auf der Suche nach Profis um Ihre Webanwendungen noch sicherer zu machen? Wir bieten Ihnen vollumfänglichen System- und Source-Code Audit zum Absichern Ihrer Datenbanken, Server und Anwendungen gegen eine Vielzahl potenzieller Sicherheitsrisiken und weiteren sicherheitsrelevanten Aspekten – darunter auch den richtigen Umgang mit CORS, CSP oder auch CSRF. Durch automatisierte und manuelle Prozesse helfen wir Ihnen, Ihre sensiblen und geschäftskritischen Informationen zu schützen und die geltenden Gesetze einzuhalten.

Unsere automatisierten Tests beinhalten u.a. Penetrationtests, toolbasierte Codeanalyse und -dokumentation. Darauf aufbauend analysieren wir den Source-Coden persönlich, versuchen die Architektur zu verstehen und mögliche Probleme bzw. Vorschläge in dem Zusammenhang zu identifizieren bzw. unterbreiten.

Des Weiteren agieren wir auch als „Software-as-a-Service“ (kurz SaaS) Vendor und bieten Ihnen verschiedene Teil- oder Vollkomponenten als Software-Service an, welche vollumfänglich, unter Berücksichtigung aller o.g. sicherheitsrelevanten ununterbrochen zur Verfügung stehen. So können Sie sich um Ihre Anwendung kümmern während wir Teilbereiche zur Verfügung stellen.

Nutzen Sie das nachfolgende Kontaktformular und kontaktieren Sie uns heute noch für ein unverbindliches Erstgespräch. Wir freuen uns darauf!