Content Security Policy – Erfahrungsbericht

Hostsharing hat die Content Security Policy (CSP) zum Schutz vor Cross-Site-Scripting (XSS) eingebaut – im ersten Wurf nicht ohne Nebenwirkung. Das Mozilla Observatory Ranking bewertet hostsharing.net jetzt mit A+.

CSP eingebaut, Safari bzw. Google Chrome reagierten zickig

Als einzige Apple Userin im Linux begeisterten Hostsharing Team hatte ich am Samstag ein PDF über unsere Webseite aufrufen wollen und war überrascht. Statt des gewünschten PDFs bekam ich einen dunklen Bildschirm zu sehen. Apples Safari wie auch Google Chrome zeigten an, dass aufgrund eines blockierten Plug-Ins die Seite nicht angezeigt wird.

War womöglich unsere PDF-Erzeugung nicht mehr mit aktualisierten Browsern kompatibel? Es begann eine fieberhafte Suche. Michael vom Hostsharing-Team fand die Lösung. Der Fehler lag in der Konfiguration der CSP (Content Security Policy).

Die CSP (Content Security Policy) wird als Sicherheitskonzept, mit dem sich XSS (Cross-Site-Scripting) und weitere Angriffsmethoden abwehren lassen, vom World Wide Web Consortium empfohlen. Ursprünglich von der Mozilla Foundation entworfen, wurde sie zunächst von Firefox und später von allen Browsern unterstützt.

Wie funktionieren Angriffe durch XSS?

Die als XSS bezeichnete Angriffsmethode nutzen Hacker, um über Sicherheitslücken in Webanwendungen Phishing oder Injection Angriffe Informationen zu beschaffen. Meist wird für den Angriff JavaScript verwendet, es eignet sich aber jede Skriptsprache, die von Browsern interpretiert werden kann. In Webanwendungen, die Angriffsmöglichkeiten für Cross-Site-Scripting bieten, kann ein Angreifer sein Skript per Injektion in die Webanwendung integrieren. Ist der Angriff erfolgreich, fügt die Webanwendung den injizierten Schadcode in den vertrauenswürdigen Code der Website ein und liefert diesen an die Website-Nutzer aus. Ein XSS-Angriff richtet sich also unter Ausnutzung von Schwachstellen der serverseitigen Webanwendung gegen Websitebesucher.

Im Browser von Besuchern der manipulierten Seite wird der Schadcode ausgeführt, wenn diese neu geladen oder gewechselt wird (deshalb „Cross-Site“). Das passiert allerdings nur dann, wenn eine Website oder ein Webshop Benutzereingaben aus dem Browser ohne Prüfung des Inhalts an den Server weitersendet. So gelangt der Schadcode beim erneuten Laden der Website vom Server auf den Client und damit den Rechner der vom Angriff betroffenen Website-Besucher.

Das einfachste Beispiel ist die Injektion von Schadcode über das Kommentarfeld eines Blogs, wenn diese Eingaben unzureichend geprüft werden. Der Schadcode kann dann an alle Betrachter der Kommentare ausgeliefert werden.

Nur wenn eine Webanwendung ohne ausreichende Überprüfung Code weitergibt, können Angreifer Skripte an die Ziel-Browser der Besucher einer Webanwendung senden und auf deren Rechner ihren Angriff realisieren. Bei dynamischen Websites können beispielsweise Phishing-, Malware- oder Man-In-The-Middle-Angriffe durch die Parameterübergabe an ein Skript (CMS oder Plug-In), das auf dem Server der Website liegt und diese erzeugt durchgeführt werden.

Wie kann CSP diese Angriffe abwehren?

Eingesetzt wird die CSP als HTTP-Header »Content-Security-Policy«. Diese Header sind allein per Injektion für Angreifer nicht manipulierbar. Die CSP kann dann XSS unterbinden, indem sie die zulässigen Quellen für Erweiterungen des HTML-Dokuments (z.B. JavaScript) einschränkt. Erfolgt diese Einschränkung restriktiv und schließt Quellen aus, in die möglicherweise Schadcode injiziert werden könnte, also insbesondere Inline-JavaScript, so würde dieser Schadcode zwar ausgeliefert, aber vom Webbrowser nicht ausgeführt.

Die CSP ist daher nicht als erste Verteidigungslinie gegen Sicherheitslücken im Zusammenhang mit Content-Injection durch XSS gedacht. Stattdessen wirkt sie bei restriktiver Handhabung als zweite Verteidigungslinie um Schäden, die böswillige Injection Angriffe verursachen können, zu verringern, wenn die Eingabeprüfung bereits versagt hat. Dabei wird angenommen, dass injizierter Schadcode zumindest gegen ene restriktive CSP verstößt und deshalb vom Browser der Seitenbesucher blockiert wird, sofern dieser CSP unterstützt. Die Content Security Policy ersetzt jedoch nicht die sorgfältige Eingabevalidierung und Ausgabecodierung als erste Verteidigungslinie.

Einige Stunden zuvor hatte Michael die CSP konfiguriert

Ein Kommentar auf Heise, hatte Michael am Freitag darauf aufmerksam gemacht, dass die Website von Hostsharing beim Ranking des Mozilla Observatory wesentlich besser abschneiden müsste.

In diesem Kontext ist zu bemerken, dass die Hostsharing-Website statisch generiert wird und somit ohnehin gegen XSS immun ist, da sie keine Daten von Benutzern zur Integration in die Website entgegennimmt. Da das Mozilla Ranking nach allgemeinen Kriterien erfolgt, wird die Besonderheit von statischen Websites nicht berücksichtigt. Dennoch nahm Michael die Herausforderung an und ergriff die Chance, Hostsharing mit der Content Security Policy im Mozilla-Ranking zu verbessern.

Die Policy war schnell implementiert und Michael startete die CSP zunächst mit restriktiven Default Policy »none«. Dazu verwendete er die Chromium Developer Tools und ließ nur die benötigten Quellen zu. Diese sind bei uns übersichtlich, die Hostsharing Website ist - nicht zuletzt wegen unserer Datenschutz Policy - so konstruiert, dass sie keine externen Elemente zulässt.

Problem erkannt - PDF in Chrome und Safari inline gerendert als HTML-Object

Wie aber hing das jetzt mit meinem Problem zusammen, die PDF Dateien nicht mehr im Browser lesen zu können? Der Zusammenhang zwischen den CSP-Einstellungen und der Weigerung einiger Browser, die PDFs zu rendern war nicht so leicht herzuleiten. Michael verwendet regulär weder Safari noch Chrome als Browser, deshalb hatte er das Problem nicht gleich bemerkt. Die Chrome Developer Tools zeigten allerdings auch keine CSP-Verletzung an; mit der kleinen Nebenwirkung, dass das Inline-PDF-Rendering von Chrome und Safari kurz streikte. PDF-Dateien wurden wegen des Inline-Renderings nicht angezeigt, sondern konnten nur herunter geladen werden.

Überraschenderweise stellte sich heraus, dass das Inline-Rendering von Chrome und Safari die PDF-Dateien so behandelt, als wären diese in Form eines HTML-Object-Tags eingebunden. Michael hatte den Fehler nach dieser Erkenntnis gefixt, indem er die CSP so erweiterte, dass die CSP den eigenen Webserver als Quelle von Objekt-Daten nun zulässt: object-src: ‘self’.

Ende gut, alles gut

Das Ergebnis ist erfreulich. Das Mozilla Ranking vergibt jetzt brav ein A+ für unsere Website und unsere Besucher sind noch besser geschützt. Die Browser-Ansicht der PDFs funktioniert auch wieder - mit allen Browsern. Dank für den Hinweis geht an die Heise Redaktion und die Kommentatoren.