Dipl.-Inform. Carsten Eilers

Bisher haben Sie erfahren, wie Sie mit der CSP das Einbinden von Skripten von unerwünschten Servern verhindern und den gefährlichen Inline-Code ausschalten können. Damit legen Sie den Angreifern schon einige gewaltige Steine in den Weg. Unter Umständen enthält Ihre Anwendung aber auch einen geheimen Tunnel unter allen Steinen hindurch: Funktionsaufrufe wie eval(), setTimeout([string], ...), setInterval([string], ...) oder new Function() können genutzt werden, auf den ersten Blick harmlosen Text in bösartigen Code umzuwandeln. Und zwar, indem der Angreifer diesen Funktionen JavaScript-Code unterschiebt, der dann ausgeführt wird.

Das würde den Schutz durch die CSP natürlich unterlaufen, weshalb diese Funktionen auch von der CSP gesperrt werden. Das hat natürlich Auswirkungen auf den vorhandenen Code. Wenn Sie zum Beispiel JSON-Daten über eval() auswerten, funktioniert das bei aktivierter CSP nicht mehr. Stattdessen können Sie die Auswertung aber problemlos über JSON.parse durchführen.

Aufrufe von setTimeout() und setInterval() mit Strings müssen in Aufrufe mit Inline-Funktionen umgewandelt werden. Aus zum Beispiel

setTimeout("alert('Das ist schlecht!')", 10);

wird dann beispielsweise

setTimeout(function () {
   alert('Das ist gut!')
}, 10);

(für setInterval() funktioniert das genauso), und aus

new Function("return irgendwas");

wird zum Beispiel

function() { 
   return irgendwas
};

CSP aushebeln

Falls Sie auf eine der unsicheren Funktionen angewiesen sind, können Sie sie ebenso wie den unsicheren Inline-Code bei Bedarf einschalten. Zuständig dafür ist das Schlüsselwort 'unsafe-eval' als zulässige Quelle in der Anweisung script-src:

Content-Security-Policy: script-src 'unsafe-eval'

Aber denken Sie dabei daran: Sie unterlaufen damit einen Teil der Schutzfunktionen der CSP. Wäre ich fies, würde ich schreiben "Wenn Sie 'unsafe-inline' oder 'unsafe-eval' einschalten, können Sie die CSP auch genau so gut gleich ganz ausschalten!". Aber ich bin ja nicht fies. Oh, was steht denn da?

Spass beiseite, denken Sie einfach daran: Jede Ausnahme, die Sie Ihrer Anwendung einräumen, kann ein Angreifer gegen Ihre Anwendung und deren Benutzer ausnutzen. Das wollen Sie doch bestimmt nicht?

CSP zum Bericht, bitte

Die CSP arbeitet komplett auf der Client-Seite und schützt Ihre Benutzer. Das ist schön und auch so gewollt. Manchmal wäre es aber ganz gut, wenn man wüsste, was denn da auf dem Client blockiert wurde. Und das ist in der Tat über die Anweisung report-uri möglich. Wird die gesetzt, sendet der Browser JSON-Formatierte Berichte über blockierte URI und ähnliches. Aktiviert wird der Bericht über

Content-Security-Policy: default-src 'self'; ...; report-uri http://anwendung.example/pfad/zum/parser;

Sie müssen die gesendeten natürlich auch entgegen nehmen, im Beispiel mit dem Skript unter http://anwendung.example/pfad/zum/parser. Die gesendeten Berichte sehen dann zum Beispiel so aus:

{
  "csp-report": {
    "document-uri": "http://anwendung.example/eine/seite.html",
    "referrer": "http://boeser-server.example/",
    "blocked-uri": "http://boeser-server.example/boeses.js",
    "violated-directive": "script-src 'self'",
    "original-policy": "script-src 'self' report-uri http://anwendung.example/pfad/zum/parser;"
  }
}

Der Bericht enthält folgende Informationen:

• Die Seite, auf der ein Regelverstoß festgestellt wurde (document-uri),
• den Referrer der Seite (referrer),
• die Ressource, die gegen die CSP verstoßen hat und deshalb blockiert wurde (blocked-uri),
• die Anweisung, gegen die verstoßen wurde (violated-directive) und
• die komplette CSP der Seite (original-policy)

CSP im reinen Berichts-Modus

Zu Testzwecken ist es oft wünschenswert, zwar über alle Regelverstöße und blockierten Ressourcen informiert zu werden, aber ohne dass dabei die Client-seitige Anwendung durch Fehler lahm gelegt wird. Für diesen Zweck kann die CSP in einen Berichts-Modus versetzt werden. Wenn Sie statt des Content-Security-Policy-Headers einen Content-Security-Policy-Report-Only-Header mit genau den gleichen Anweisungen senden, wird die CSP zwar theoretisch beachtet und Regelverstöße an den Server gesendet, die geforderten Einschränkungen aber praktisch nicht durchgesetzt:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri http://anwendung.example/pfad/zum/parser;

Wie Sie oben schon bemerkt haben, wird im Bericht auch die Original-Policy angegeben. Praktischerweise ist es möglich, sowohl Content-Security-Policy-Header als auch Content-Security-Policy-Report-Only-Header zu senden und damit eine Policy durchzusetzen und gleichzeitig eine andere zu testen. Das bietet sich zum Beispiel an, wenn Sie eine funktionierende Policy haben, aber zum Beispiel nach Änderungen am Code eine neue Policy testen möchten.

Damit ist das Thema "Content Security Policy" abgeschlossen. Ab der nächsten Folge geht es um Schutzmaßnahmen gegen Angriffe auf/über Pufferüberlauf-Schwachstellen.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4

Schutzmaßnahmen: Der Pufferüberlauf im Überblick

Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen

Schutzmaßnahmen: ASLR kann unterlaufen werden

Schutzmaßnahmen: Weitere Angriffe trotz ASLR