blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
medium missing-x-frame-options

Seite ist einbettbar in fremde Webseiten

Ohne Einbettungsrichtlinie laden Angreifer Ihre Seite in ihrer eigenen und tricksen Klicks aus, die der Besucher nicht sieht. Der Header, der das verhindert.

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.

Das 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'

Das 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, sonst können feindselige Einbetter das Widget weiterhin für Clickjacking missbrauchen (etwa “Zahlung freigeben”, “Nachricht senden”).

Mehr dazu