blueredix logo
medium missing-x-frame-options

Seite kann in fremden Webseiten eingebettet werden

Ohne Einbettungs-Policy kann ein Angreifer Ihre Seite in eine eigene Seite laden und Besucher:innen dazu bringen, Buttons zu klicken, die sie nie klicken wollten. Klassisches Clickjacking-Setup.

Worum es geht

Browser können eine Webseite in einer anderen einbetten, über ein sogenanntes iframe. Vergleichbar mit dem Bild-im-Bild eines Fernsehers. Sauber genutzt erscheinen so YouTube-Videos und Google-Maps-Karten in fremden Seiten. Bösartig genutzt kann ein Angreifer Ihre Seite in seine eigene laden, sie unter einer transparenten Folie verstecken und Besucher:innen dazu bringen, auf Buttons Ihrer Seite zu klicken, die sie nie klicken wollten.

Ihre Seite schickt derzeit keine Anweisung, die das verhindert. Wer auch immer eine Webseite betreibt, kann Ihre darin einbetten.

Warum das wichtig ist

Das Angriffsmuster heißt Clickjacking. Der Ablauf:

  1. Der Angreifer hostet eine eigene Webseite mit einem verführerischen Button: “Klick zum Gewinnen”, “Weiter”, was auch immer.
  2. Er lädt ihre-seite.de/konto/loeschen (oder /geld-ueberweisen, /zugriff-gewähren) in einem transparenten iframe direkt unter dem Cursor.
  3. Die Person klickt den Köder-Button. Der Klick landet aber auf der versteckten Variante Ihrer Seite, die ihn als völlig legitimen Request einer eingeloggten Kundin sieht.

Funktioniert, weil Cookies für Ihre Seite bei jedem Request mitgehen, auch aus dem iframe des Angreifers. Den Cookie selbst sieht der Angreifer nie, das ist auch nicht nötig. Er braucht nur, dass der Klick an der richtigen Stelle landet.

Varianten gibt es auf Mobilgeräten (Tapjacking), in sozialen Netzwerken (Likejacking) und bei Formularfeldern (Eingabe in ein gefälschtes Feld über einem echten).

Eine Frame-Blocking-Anweisung schließt den effizientesten Auslieferungsweg dieser Angriffsfamilie.

So beheben Sie das

Wer Ihren Webserver verwaltet, ergänzt eine einzelne Anweisung. Zwei Varianten erledigen denselben Job. Moderne Browser bevorzugen die erste, die zweite funktioniert aber überall und ist als Einzeiler einfacher zu setzen:

Variante A (modern, empfohlen):

Content-Security-Policy: frame-ancestors 'none'

Sagt dem Browser: “keine andere Webseite darf diese Seite in einem iframe laden”. Wenn Ihre eigene Seite sich selbst einbettet (häufig bei Admin-Dashboards), 'self' verwenden. Für bestimmte Partner: 'self' https://partner.example.

Variante B (Einzeiler, sehr breite Kompatibilität):

X-Frame-Options: DENY

Oder SAMEORIGIN, falls Sie sich selbst iframen.

Übliche Server-Snippets:

nginx:

add_header Content-Security-Policy "frame-ancestors 'none'" always;
add_header X-Frame-Options DENY always;

Apache:

Header always set Content-Security-Policy "frame-ancestors 'none'"
Header always set X-Frame-Options DENY

Nach dem Deployment prüfen mit:

curl -I https://ihre-domain.de/ | grep -iE "frame-ancestors|x-frame-options"

Wenn Ihr Produkt selbst eingebettet wird

Ist Ihr Produkt ein einbettbares Widget (Chat, Zahlung, Share-Buttons), dann setzen Sie frame-ancestors auf eine konkrete Liste der Kunden-Origins, die Sie einbetten dürfen. Nicht offen lassen, feindselige Einbetter können sonst weiterhin Ihr Widget clickjacken (etwa “Zahlung freigeben”, “Nachricht senden”).

Mehr dazu