Sicherheits-Ratgeber
Clickjacking, verständlich erklärt
Ein Angreifer braucht kein Passwort, wenn er Ihren Besucher dazu bringt, unbemerkt die richtige Schaltfläche zu drücken. Dieser Ratgeber erklärt, wie der Angriff funktioniert, welche zwei Header ihn verhindern und welcher davon heute noch nötig ist.
01 Warum es wichtig ist
Der Klick, der woanders landet
Clickjacking lädt Ihre Website in einen unsichtbaren Frame auf einer Seite, die der Angreifer kontrolliert. Ihre Seite lädt ganz normal, der Besucher ist darin bereits angemeldet, sie wird dann durchsichtig gestellt und genau unter etwas geschoben, das er wirklich anklicken will: eine Abspielschaltfläche, einen Gewinn, einen Cookie-Hinweis. Der Klick ist echt, die Sitzung ist echt, und er landet auf Ihrer Schaltfläche. Konto löschen, Überweisung bestätigen, Zugriff erteilen: Was auf Ihrer Website ein einzelner Klick auslösen kann, löst nun jemand aus, der es nie gesehen hat.
Hinterher sieht auf Ihrer Seite nichts falsch aus. Die Anfrage trug eine gültige Sitzung, kam aus einem echten Browser und tat, was ihr gesagt wurde, also haben weder Ihre Logdateien noch Ihre Betrugsregeln etwas zu beanstanden. Deshalb wird das gelöst, indem man das Einbetten grundsätzlich verweigert, und nicht, indem man den Angriff erkennt.
02 Die Header
Zwei Header, eine Entscheidung
X-Frame-Options: DENY
Was er bewirkt. Weist den Browser an, Ihre Seite in keinem Frame und keinem Iframe darzustellen, auch nicht in einem auf Ihrer eigenen Website.
Warum er wichtig ist. Der stärkste und einfachste Wert. Wenn nichts auf Ihrer Website die eigenen Seiten einbetten muss, ist das die Einstellung der Wahl, und sie erspart Ihnen jede Abwägung, welchen Domains Sie trauen.
add_header X-Frame-Options "DENY" always; X-Frame-Options: SAMEORIGIN
Was er bewirkt. Erlaubt das Einbetten, aber nur durch Seiten derselben Domain wie die eingebettete Seite.
Warum er wichtig ist. Der richtige Wert, wenn Ihre eigene Anwendung eigene Seiten einbettet, etwa in einer Vorschau oder einem Editor. Alles von außen wird weiterhin abgelehnt.
add_header X-Frame-Options "SAMEORIGIN" always; X-Frame-Options: ALLOW-FROM
Was er bewirkt. Sollte einmal eine einzelne Domain benennen, die die Seite einbetten darf. Kein aktueller Browser setzt das um.
Warum er wichtig ist. Den Wert zu setzen schränkt nichts ein: Ein Browser, der ihn nicht versteht, ignoriert den Header vollständig, eine scheinbar geschützte Seite ist damit ungeschützt. Wenn Sie einen bestimmten Partner erlauben müssen, ist frame-ancestors dafür da.
add_header X-Frame-Options "ALLOW-FROM https://partner.example" always; frame-ancestors 'none'
Was er bewirkt. Die Direktive der Content Security Policy, die X-Frame-Options ablöst. Sie listet die Domains auf, die die Seite einbetten dürfen; none erlaubt es niemandem.
Warum er wichtig ist. Liegen beide Header vor, folgen Browser dieser Direktive, und nur sie kann mehr als eine einzelne Domain nennen. Senden Sie sie als Teil Ihrer Richtlinie, auch wenn Sie X-Frame-Options bereits setzen.
add_header Content-Security-Policy "frame-ancestors 'none'" always; frame-ancestors 'self' https://partner.example
Was er bewirkt. Erlaubt Ihre eigene Domain und die Domains, die Sie nennen, und weist alle anderen ab.
Warum er wichtig ist. Genau der Fall, den ALLOW-FROM abdecken sollte, nur auf eine Art, die tatsächlich funktioniert. Nennen Sie jede Domain vollständig, samt Protokoll.
add_header Content-Security-Policy "frame-ancestors 'self' https://partner.example" always;03 Einführung
Beides senden, einmal entscheiden
Klären Sie zuerst die Antwort: Bettet irgendetwas Ihre Seiten berechtigt ein, und wenn ja, von welchen Domains? Senden Sie dann frame-ancestors für aktuelle Browser und X-Frame-Options mit dem passenden Wert für ältere Clients. Dass die beiden übereinstimmen, ist wichtiger als die Frage, welchen Sie für den führenden halten, denn eine Abweichung ist genau der Grund, aus dem eine Partner-Einbindung in einem Browser bricht und im anderen nicht.
server { add_header X-Frame-Options "DENY" always; add_header Content-Security-Policy "frame-ancestors 'none'" always; }Der Header schützt nur die Seite, die ihn sendet, er gehört also in jede Antwort und nicht nur auf die Login-Seite. Senden Sie bereits eine Content-Security-Policy, ergänzen Sie frame-ancestors in dieser bestehenden Richtlinie, statt eine zweite zu senden. Und prüfen Sie das Ergebnis an der laufenden Website: Ein Reverse Proxy oder ein CDN, das selbst ein X-Frame-Options ergänzt, hinterlässt den Header doppelt, und manche Browser werten ihn dann als ungültig.
04 Fragen
Was zu Clickjacking gefragt wird
Ist X-Frame-Options überholt, seit die CSP frame-ancestors kennt?
Abgelöst, nicht nutzlos. Liegen beide vor, folgen Browser frame-ancestors. X-Frame-Options zusätzlich zu senden kostet eine Zeile und deckt Clients ab, die die Direktive nicht auswerten, und deshalb erwartet unser Scan beides.
Deckt SAMEORIGIN auch eine Subdomain ab?
Nein. Dieselbe Domain bedeutet dasselbe Protokoll, denselben Host und denselben Port; eine Seite auf der einen Subdomain kann unter SAMEORIGIN keine Seite auf einer anderen einbetten. Dieser Fall braucht frame-ancestors mit beiden Domains.
Wir betten unsere Website in ein Partnerportal ein. Was setzen wir?
frame-ancestors mit Ihrer eigenen und der Partner-Domain, dazu X-Frame-Options: SAMEORIGIN. Alte Clients lehnen den Partner-Frame ab, und es gibt keinen funktionierenden Weg, über X-Frame-Options eine fremde Domain zu erlauben: genau daran ist ALLOW-FROM gescheitert.
Verhindert ein CSRF-Token nicht schon Clickjacking?
Nein. Die eingebettete Seite ist Ihre eigene und trägt deshalb ein gültiges Token wie jede andere geöffnete Seite. Das Token belegt, dass die Anfrage von Ihrer Seite kam, und das tat sie in diesem Angriff tatsächlich. Es hilft nur, den Frame zu verweigern.
05 Im Detail
Verwandte Sicherheitsthemen
Das Einbetten ist eine Art, eine Seite gegen ihre Besucher zu wenden. Diese Ratgeber behandeln die anderen.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
SPF, DMARC und DNSSEC
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, ob Ihre Website eingebettet werden kann
Unser kostenloser Quickscan prüft X-Frame-Options und frame-ancestors an Ihrer ausgelieferten Antwort, zusammen mit dem Rest Ihrer Security-Header, und erklärt jeden Befund verständlich.