Wann schützt eine Content-Security-Policy vor eingeschleusten Skripten?

Die CSP begrenzt den Schaden eingeschleuster Skripte

Gelangt fremder Code in Ihre Seite, etwa über ein Kommentarfeld, eine Suchfunktion oder eine angegriffene Erweiterung, führt der Browser ihn aus wie Ihren eigenen. Er kann Eingaben in Formularen mitlesen, Zahlungsfelder verändern oder Besucher auf eine andere Seite schicken. Eine Content-Security-Policy setzt dem eine zweite Grenze: der Browser führt nur Skripte aus, die die Richtlinie erlaubt. Die eigentliche Lücke schließt sie nicht, aber sie verhindert, dass eingeschleuster Code läuft.

Gemessen wird, was die Richtlinie für Skripte erlaubt

Die Prüfung liest die Kopfzeile Content-Security-Policy in der Antwort jeder Seite des Laufs und dort die Angabe script-src, ohne sie default-src. Drei Freigaben nennt der Bericht. 'unsafe-inline' erlaubt jedes Skript, das direkt im Quelltext steht, und damit genau die Form, in der eingeschleuster Code meist ankommt. 'unsafe-eval' erlaubt, Code aus Zeichenketten zu erzeugen. Ein Stern oder https: als Quelle erlaubt Skripte von jedem Server, auch von einem, den ein Angreifer betreibt. Der Befund zeigt die Kopfzeile, wie Ihr Server sie geschickt hat. Schickt der Server keine CSP, gehört das zum Prüfpunkt der Sicherheitskopfzeilen.

Nonce, Hash und strict-dynamic geben Skripte einzeln frei

Eine Nonce ist ein Zufallswert, den der Server bei jedem Seitenaufruf neu erzeugt. Er steht in der Kopfzeile und an jedem eigenen Skript; ein eingeschleustes Skript kennt ihn nicht und bleibt blockiert. Ein Hash ist die Prüfsumme eines bestimmten Skripts im Quelltext und eignet sich für Skripte, die sich nie ändern. Mit 'strict-dynamic' dürfen freigegebene Skripte weitere Skripte nachladen, etwa ein Tag-Manager seine Dienste. Steht eine Nonce oder ein Hash in der Richtlinie, beachten heutige Browser 'unsafe-inline' nicht mehr; steht 'strict-dynamic' darin, beachten sie Quellen wie https: nicht mehr. Beides darf deshalb als Rückfall für alte Browser stehen bleiben, und die Prüfung wertet es dann nicht.

Die Umstellung beginnt im Beobachtungsmodus

Eine strenge Richtlinie kann Teile der Seite sperren, die bisher funktionierten, etwa ein Formular oder eine Karte. Deshalb liefert der Server sie zuerst als Content-Security-Policy-Report-Only aus: der Browser meldet dann, was er blockieren würde, und blockiert noch nichts. Sind alle gemeldeten Skripte freigegeben, wird daraus die Kopfzeile Content-Security-Policy. Steht die Beobachtung neben einer schwachen Richtlinie, nennt der Bericht das als eigenen Befund. Wie viel Arbeit die Umstellung macht, hängt vom System ab: viele Content-Management-Systeme und Erweiterungen schreiben Skripte direkt in den Quelltext.

Tipps aus der Praxis

• Die Nonce entsteht bei jeder Antwort neu, mit mindestens 128 Bit Zufall.
• Seiten aus dem Zwischenspeicher bekommen einen Hash, weil dort keine neue Nonce entsteht.
• Setzt eine Erweiterung eine zweite Richtlinie, gelten beide. Jede weitere kann nur einschränken.

Mehr zu diesem Thema

• Google Tag Manager und Content-Security-Policy: wie geht beides?Google empfiehlt für den Tag Manager eine Nonce in der CSP. Sie gibt auch alles frei, was er nachlädt. Was das für Variablen und Adressen bedeutet.