2. X-Frame-Options Header

Das HTTP-Header-Feld X-Frame-Options zeigt eine Richtlinie an, die angibt, ob der Browser die übertragene Ressource innerhalb eines <frame> oder <iframe> rendern soll. Server können diese Richtlinie im Header ihrer HTTP-Antworten deklarieren, um Clickjacking-Angriffe zu verhindern und sicherzustellen, dass ihr Inhalt nicht in andere Websites eingebettet wird.

2.1 Syntax

Der Name des Header-Feldes ist:

X-Frame-Options

Es gibt drei verschiedene Werte für das Header-Feld. Diese schließen sich gegenseitig aus; das heißt, das Header-Feld MUSS auf genau einen der drei Werte gesetzt werden.

DENY

Ein Browser, der Inhalt mit diesem Header-Feld empfängt, DARF NICHT diesen Inhalt in irgendeinem Frame anzeigen.

SAMEORIGIN

Ein Browser, der Inhalt mit diesem Header-Feld empfängt, DARF NICHT diesen Inhalt in einem Frame von einer Seite mit anderem Ursprung als dem Inhalt selbst anzeigen. Wenn ein Browser oder Plugin nicht zuverlässig feststellen kann, ob der Ursprung des Inhalts und des Frames gleich sind, MUSS dies als "DENY" behandelt werden.

Bitte beachten Sie, dass aktuelle Implementierungen in der Interpretation dieses Kriteriums variieren. In einigen ist es nur erforderlich, dass der Ursprung des Top-Level-Browsing-Kontexts mit dem Ursprung des Inhalts übereinstimmt, der die X-Frame-Options-Direktive verwendet; in anderen muss dieses Kriterium für alle Vorfahren-Browsing-Kontexte erfüllt sein. Für weitere Details zur Verschachtelung von Frames und Variationen im Verhalten dieses Header-Feldes in verschiedenen Browsern siehe Abschnitt 2.3.2.2. Siehe außerdem Abschnitt 4, Absatz 2 für die daraus resultierenden potenziellen Sicherheitsprobleme.

ALLOW-FROM (gefolgt von einem serialisierten Ursprung [RFC6454])

Ein Browser, der Inhalt mit diesem Header-Feld empfängt, DARF NICHT diesen Inhalt in einem Frame von einer Seite anzeigen, deren Top-Level-Browsing-Kontext einen anderen Ursprung als den angegebenen Ursprung hat. Obwohl dieser Header-Wert möglicherweise eingeschränkte Unterstützung hat, wird er in modernen Browsern veraltet.

Beachten Sie, dass das X-Frame-Options-Header-Feld als HTTP-Header-Feld gesendet werden MUSS und Browser Instanzen, die im <meta http-equiv>-Tag gefunden werden, ausdrücklich ignorieren.

2.2 Erweiterte Backus-Naur-Form (ABNF)

Die RFC 5234 ABNF [RFC5234] des X-Frame-Options-Header-Feldwerts ist wie folgt:

id-name                = "X-Frame-Options"
X-Frame-Options        = "DENY"
                        / "SAMEORIGIN"
                        / ( "ALLOW-FROM" RWS serialized-origin )

RWS                    = 1*( SP / HTAB )
                        ; required whitespace

serialized-origin      = scheme "://" host [ ":" port ]
                        ; <scheme>, <host>, <port> as per RFC 6454

wobei "serialized-origin" wie in RFC 6454 [RFC6454], Abschnitt 6.2 definiert ist. Die Produktion "serialized-origin" impliziert, dass die serialisierte Ursprungszeichenfolge keine Leerzeichen enthalten darf.

2.2.1 Beispiele für X-Frame-Options

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/

2.3 Designfragen

2.3.1 HTML-Inhalt von anderen Domains aktivieren

Es gibt eine Reihe von Hauptvektoren, die HTML-Inhalt von anderen Domains ermöglichen, zum Beispiel:

<frame>-Elemente
<iframe>-Elemente
<object>-Elemente
<applet>-Elemente
<embed>-Elemente

Neben diesen können andere Elemente genutzt werden, um Aktionen in den übergeordneten Frames auszuführen, die zu einem Clickjacking-ähnlichen Angriff beitragen können, einschließlich des <script>-Tags, des <form>-Tags und des <button>-Tags, unter anderem. Das X-Frame-Options-Header-Feld bietet einen Mechanismus, durch den Website-Betreiber anzeigen können, dass ihre Seiten nicht in Frames von anderen Domains eingebettet werden sollten, und sich dadurch gegen Clickjacking-Angriffe verteidigen können.

2.3.2 Browser-Verhalten und -Verarbeitung

2.3.2.1 Verletzung von X-Frame-Options

Wenn ein Browser einen X-Frame-Options-Header erkennt, der verhindert, dass die Seite in einem Frame gerendert wird, MUSS der Browser sofort das Rendern des Dokuments beenden.

Die Seite muss so behandelt werden, als hätte der Benutzer die Anfrage zum Laden des Dokuments abgebrochen. Dies ähnelt der Art und Weise, wie der User Agent die "204 No Content"-Antwort verarbeitet, obwohl letztere nicht zu einer Fehlerbedingung führt.

Wenn der Browser bereits begonnen hat, Bilder oder andere in der Seite enthaltene Ressourcenanfragen herunterzuladen, SOLLTE der Browser versuchen, den Download dieser Ressourcen so schnell wie möglich zu stoppen.

2.3.2.2 Variation im aktuellen Browser-Verhalten

Browser unterscheiden sich in ihrer Interpretation der Frame- und Browsing-Kontext-Prüfung, die erforderlich ist, wenn das SAMEORIGIN-Header-Feld verwendet wird. Das beabsichtigte Verhalten ist, dass der User Agent die Seite NUR in einem Frame rendern MUSS, wenn dieser Frame im gleichen Ursprung wie die geframte Seite ist.

Die Browser-Implementierungen unterscheiden sich jedoch. Einige Implementierungen durchlaufen den gesamten Vorfahrenbaum der Browsing-Kontexte und verlangen, dass jeder Vorfahre im gleichen Ursprung ist. Andere überprüfen nur, dass der Top-Level-Browsing-Kontext (das Fenster) vom gleichen Ursprung stammt.

Dies bedeutet, dass für Seiten, die durch mehrere Zwischenseiten "geframt" werden (d.h. ein Frame in einem Frame in einem Frame), die Menge der Seiten, die erfolgreich gerendert werden, restriktiver sein kann (in Implementierungen, die die gesamte Vorfahrenkette prüfen) oder weniger restriktiv (in Implementierungen, die nur den Top-Level-Frame prüfen) als die Spezifikation beabsichtigt.

Website-Betreiber sollten sich dieser potenziellen Verhaltensunterschiede bewusst sein und das Rendering in ihrer erwarteten Browser-Basis testen, um die Einhaltung ihrer Anti-Clickjacking-Richtlinien sicherzustellen.

2.3.2.3 Verwendungsdesignmuster und Beispielszenario für den ALLOW-FROM-Parameter

Aufgrund schwacher Unterstützung und unterschiedlicher Implementierungen in verschiedenen Browsern wurde die ALLOW-FROM-Option veraltet. Website-Betreiber SOLLTEN stattdessen die Verwendung der frame-ancestors-Direktive der Content Security Policy [CSP2] in Betracht ziehen, die eine bessere Kontrolle über Frame-Einbettungsrichtlinien bietet und eine bessere Browser-Unterstützung hat.

2.3.2.4 Kein Caching des X-Frame-Options-Headers

Browser MÜSSEN den Wert des X-Frame-Options-Header-Feldes für jede HTTP-Antwort verarbeiten, unabhängig von Cache-Direktiven, die in dieser HTTP-Antwort oder zuvor zwischengespeicherten Antworten vorhanden sind. Das Header-Feld wird zum Navigationszeitpunkt ausgewertet und DARF NICHT zwischengespeichert werden. Dies stellt sicher, dass die aktuellste Richtlinie durchgesetzt wird.