zurück zur Übersicht

Fasten Your Content: CSP in der Praxis

Eine korrekt eingerichtete CSP kann verhindern, dass die Webseite und die Reputation abbrennt.Schon mal einen Virus über die Firmenwebseite verbreitet?

Eine gehackte Webseite kann enormen Schaden anrichten. Dabei stehen nicht nur brisante Unternehmens- und Kundendaten auf dem Spiel (wie z.B. in unserem Artikel über Mossak & Fonseca oder den Lufthansa-Datenklau beschrieben).

Der Image-Schaden, wenn Kriminelle die eigene Webseite missbrauchen, um beispielsweise Schadcode an die Besucher zu verteilen, ist ebenso enorm.

Content-Injection- und speziell XSS-Angriffe (Cross-Site-Scripting) sind weitverbreitet. Eine Vielzahl von Ansätzen (Codeanalysetools, div. Frameworks, Code-Audits etc.) existiert, um dafür verantwortliche Sicherheitslücken zu erkennen und vor Inbetriebnahme der Applikationen zu entfernen. Sinnvoll für eine neue Web-App ist beispielsweise ein Web Application Health Check (Details dazu im Artikel hier). Dadurch ist eine gewisse Grundsicherheit durchaus proaktiv erreichbar.

Ein Quantum mehr Sicherheit

Die Realität zeigt allerdings, dass trotz all dieser Tools und Vorgehensweisen XSS-Lücken noch immer die häufigsten Sicherheitslücken in Web-Applikationen sind. Das Ziel, restlos alle XSS-Lücken vor dem Going-live zu finden, ist in der Praxis unerreichbar.

Einen alternativen Ansatz verfolgen sog. Content Security Policies (CSP) – dabei wird davon ausgegangen, dass nie alle XSS-Lücken geschlossen werden können und es deshalb besser ist, das Nachladen von Ressourcen (Code, Bilder, Forms) aus unbekannten Quellen generell zu unterbinden.

Konkret handelt es sich bei CSP um einen zusätzlichen HTTP Header welcher von allen gängigen Browsern unterstützt wird. Innerhalb dieses zusätzlichen Headers werden sog. „Directives“ angegeben, die festlegen woher z.B. Scripte, Bilder, Fonts, iFrames etc. nachgeladen werden dürfen.

Funktionsweise einer CSP im Detail

Doch wie geht man nun vor, um die eigene Web-Applikation mittels CSP abzusichern?

Zu aller erst ist zu beachten, dass bei CSP jegliche Art von Inline-Code als potentiell gefährlich angesehen und dementsprechend nicht ausgeführt wird. Dies ergibt sich aus dem Umstand, dass CSP einen Whitelisting-Ansatz verfolgt und es unmöglich ist, bei Inline-Code die tatsächliche Herkunft zu bestimmen. Dieses Verbot von Inline-Code kann bei bereits bestehenden Web-Applikationen einigen Anpassungsaufwand erfordern.

Alle zur Verfügung stehenden „Directives“ können unter https://content-security-policy.com/ eingesehen werden. Soll etwa sichergestellt werden, dass Scripts nur von cdn.it-cube.net nachgeladen werden dürfen, könnte eine sehr einfache CSP folgendermaßen aussehen:

Content-Security-Policy:
default-src ’none‘; base-uri ’self‘; script-src cdn.it-cube.net;

Die folgenden Code-Beispiele zeigen anschaulich die Funktionalität von CSPs. Der Einfachheit halber wird für die Beispiele das Bottle Python Web Framework verwendet. Ist dieses auf dem Rechner installiert, können die Code Snippets einfach in die Python Console kopiert und das Ergebnis durch Aufruf der URL http://localhost:8080/csptest in Augenschein genommen werden.

Die Webseite im Beispiel  zeigt sowohl das Logo des iT-CUBE Blogs an, führt aber auch den JavaScript  Code aus. Dieser JavaScript Code könnte z.B. im Rahmen eines Angriffs eingefügt worden sein.

from bottle import route, run
from bottle import response
@route(‚/csptest‘)
def hello():
return ‚<img src=“https://www.it-cube.net/cubespotter/wp-content/themes/itcube/images/blog.png“> <SCRIPT>alert(„Boom“)</SCRIPT>‘
run(host=’localhost‘, port=8080, debug=True)

Wird nun der CSP Header hinzugefügt, verhindert dies die Ausführung des JavaScript Codes.

Der eigentliche Angriff (Code Injection) war zwar erfolgreich, allerdings wird dieser Code niemals ausgeführt und kann somit keinen Schaden anrichten.

from bottle import route, run
from bottle import response
@route(‚/csptest‘)
def hello():
response.set_header(‚Content-Security-Policy‘, ‚default-src none; base-uri self; img-src data: *‘)
return ‚<img src=“https://www.it-cube.net/cubespotter/wp-content/themes/itcube/images/blog.png“> <SCRIPT>alert(„Boom“)</SCRIPT>‘
run(host=’localhost‘, port=8080, debug=True)

Ein äußerst nützliches Feature, sowohl bei der Erstellung von CSP-Regeln, als auch bei der Erkennung von Angriffsversuchen, ist CSP-Reporting. Hierbei wird eine URL hinterlegt an welche CSP-Reporting-Meldungen gesendet werden. So erfährt der Betreiber einer Webseite, wenn versucht wird gegen eine CSP-Directive zu verstoßen, also wenn z.B. ein externes Script geladen werden soll. Auch besteht die Möglichkeit CSP im „Report-Only“ Modus zu betreiben – in diesem Fall werden ausschließlich Reports versendet, die Policies aber nicht angewandt. Dieser Modus ist vor allem dann zu empfehlen, wenn nicht alle Datenquellen bekannt sind und erst identifiziert werden müssen.

Content-Security-Policies bieten einen äußerst effektiven Schutz gegen unterschiedlichste Arten von Content-Injection-Angriffen. Allerdings ist etwas Aufwand und Know-How nötig, um für eine Webseite die optimalen Direktiven zu definieren. Wer sich aber diese Mühe macht, kann eine riesige Bandbreite an hinterhältigen XSS-Attacken abwehren.

 


 

Bild: ©iT-CUBE SYSTEMS AG 2017

Schreibe einen Kommentar