Angular Security Teil 3 – proaktiver XSS Schutz
mit CSP

Im letzten Beitrag ging es um Sicherheitslücken, die du mit iframe sandbox proaktiv eindämmen kannst. Doch nicht alle eingebundenen Inhalte haben nur einen praktischen Zweck – manchmal sorgen sie einfach für ein bisschen Spaß. Gerade willst du den Online-Shop verlassen, als plötzlich ein fröhliches, gelbes Quietsche-Entchen auf deinem Bildschirm erscheint. Als kleines Gimmick hat dein Lieblings-Online-Shop dies wohl eingebaut, damit du den Shop noch nicht verlässt und vielleicht doch noch etwas kaufst. Naja, ein Quietsche-Entchen kannst du dir ja mal auf den Bildschirm schwimmen lassen…

Die Story geht weiter

Die Angreifer geben nicht auf und wenden sich nun den übrigen Abhängigkeiten der Website zu. Besonders ins Visier nehmen sie das Quietsche-Entchen-Generator-Modul, das schon lange vernachlässigt wird und voller Sicherheitslücken steckt – dabei ist es für die Website unverzichtbar. Eine Neuentwicklung des Moduls kommt nicht in Frage, und der Einsatz von <iframe> ist aus technischen Gründen nicht möglich. Die Angreifer entdecken, dass in der CVE-Datenbank seit sechs Monaten eine XSS-Schwachstelle für das Modul vermerkt ist. Sie versuchen, diese auszunutzen, scheitern jedoch an der bereits implementierten Content Security Policy (CSP), die den Angriff blockiert.

Content Security Policy (CSP)

Du bist Entwickler:in: Du möchtest deine Webseite besser vor XSS-Angriffen schützen und setzt auf Content Security Policy (CSP).

CSP sind zusätzliche Regeln, die mittels der Header-Felder jeder HTTP-Anfrage übermittelt werden. Sie beeinflussen das Verhalten des Webbrowsers in Bezug auf die JavaScript-Ausführung und die Nutzung weiterer externer Ressourcen. Eine gute Ausgangsbasis für eine Policy wäre zum Beispiel:

Content-Security-Policy

default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';

Was passiert hier? Wir sehen eine Reihe von Einstellungen, die durch Semikolon getrennt sind. Diese setzen sich wie folgt zusammen: <Direktive> <Domain/Schlüsselwort>.

1. Direktiven

CSP arbeitet mit einer Reihe von Direktiven, die festlegen, welche Ressourcen geladen und ausgeführt werden dürfen. Gemeinsame Direktiven sind:

• default-src: Ist die Standardquelle für Ressourcen, wenn sie nicht von anderen Direktiven spezifiziert werden.
• script-src: Kontrolliert, aus welchen Quellen die Skripte ausgeführt werden können.
• style-src: Bestimmt, aus welchen Quellen die Stilen Gebrauch gemacht werden kann.
• img-src: Legt fest, von welchen Quellen Bilder geladen werden können.
• font-src: Steuert die Quellen von Schriftarten.
• connect-src: Gibt die Ursprünge an, zu denen die Anwendung Netzwerkanfragen (AJAX, WebSockets usw.) senden kann.
• frame-src: Definiert die Quellen für <frame> and <iframe>.

2. Schlüsselwörter

Direktiven können auf bestimmte Domains eingestellt werden, aber es gibt auch Schlüsselwörter, die verwendet werden können:

• 'self': Bezieht sich auf die aktuelle Herkunft und erlaubt das Laden von Ressourcen der gleichen Domain.
• 'none': Blockiert alle Ressourcen für diese Direktive.
• 'unsafe-inline': Ermöglicht Inline-Skripte oder -Stile. Verwende dies mit Vorsicht, da es die Sicherheit beeinträchtigen kann.
• 'unsafe-eval': Erlaubt die Verwendung von eval() und ähnlichen Funktionen. Ebenfalls riskant.
• 'strict-dynamic': Erlaubt die dynamische Erstellung von Skripten, aber nur aus vertrauenswürdigen Quellen.

Lass uns nochmal das Beispiel von vorhin mit dem neu gewonnenen Wissen betrachten:

• default-src 'self'; Für alle nicht in der Policy erwähnten Direktiven gilt: nur eigenen JavaScript laden.
• script-src 'self'; JavaScript nur aus eigener Quelle vertrauen.
• style-src 'self' 'qualityminds.com'; CSS-Styles aus eigener Quelle oder von „qualityminds.com“ vertrauen. Um subdomains einzuschließen ist wiederum style-src ’self‘ ‚*.qualityminds.com‘; notwendig.

Einrichten von CSP in nginx

Die in Angular geschriebene Anwendung häufig mittels des nginx-Webservers zum Kunden gebracht. Ist eine besondere Konfiguration notwendig, so bedarf diese einer Anpassung in der nginx-Konfigurationsdatei unter /etc/nginx/sites-available/ auf dem Linux-Server. Es kommt folgende Zeile hinzu:

add_header Content-Security-Policy "default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';"

Nach dem Serverneustart werden die CSP-Header mit den Policy-Änderungen automatisch bei jedem Nutzer heruntergeladen.

Einrichten von CSP in Angular

Du bist kein Fan von Serverkonfiguration oder es liegt nicht in deinem Zuständigkeitsbereich? Es gibt eine Möglichkeit, CSP-Header in Angular zu definieren. Dies geht mittels des <meta>-Tags in Angulars index.html Datei:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; style-src 'self'; script-src 'self' 'qualityminds.com';">

Stay tuned!

Updates sind nicht genug

Als Angreifer:in weißt du, dass viele Webseitenbetreiber auf Drittanbieter-Module setzen und diese oft Schwachstellen aufweisen. Du freust dich, dass du trotz Sandbox und CSP immer noch Angriffspunkte findest.

Nächster Beitrag

Dein für XSS-Angriffe anfälliger Quietsche-Entchen-Generator wurde gerade noch gerettet! Die Angreifer können keinen eigenen JavaScript-Code mit ihm ausführen. Aber die nächste Herausforderung kommt bestimmt. Erfahre im nächsten Beitrag, wie du deine Webanwendung noch besser gegen Angriffe absichern kannst. Bleib dran!