Clickjacking

Ein Clickjacking-Beispiel

Angenommen, die Website der Bank des Benutzers ist https://my-bank.example.com. Der Benutzer bleibt normalerweise auf dieser Seite angemeldet. Zur Vereinfachung nehmen wir an, dass die Seite ber einen Button verfgt, mit dem alle Gelder des Benutzers an den Angreifer berwiesen werden knnen obwohl dies offensichtlich unrealistisch ist, ist es plausibel, dass die Seite einige interaktive Elemente hat, die eine sensible Operation ausfhren.

[Screenshot einer Bankwebsite, die einen Button mit der Aufschrift Transferiere all mein Geld? zeigt.]

Der Angreifer erstellt eine Webseite, die Folgendes enthlt:

• ein <button>-Element, dessen Inhalt den Benutzer zum Klicken ermutigt
• ein <iframe>-Element, das die Bankseite einbettet.

<button id="fake-button">Click here for a free kitten!</button>
<iframe width="800" height="200" src="https://my-bank.example.com"></iframe>

In dem CSS fr die Seite sorgt der Angreifer dafr, dass:

• das <iframe> verborgen wird, zum Beispiel durch Setzen der opacity auf null
• der Button so positioniert wird, dass er an derselben Stelle ist wie der Transferiere all dein Geld?-Button.

iframe {
  opacity: 0;
}

#fake-button {
  position: absolute;
  top: 185px;
  left: 90px;
}

Das Ergebnis sieht dann so aus (wir haben die <iframe>-Deckkraft auf 0.1 gesetzt, damit Sie die berlagerung sehen knnen):

[Screenshot einer Clickjacking-Website, welche die Bank-Website eingebettet zeigt.]

Wenn der Benutzer versucht, auf Klicken Sie hier fr ein kostenloses Ktzchen! zu klicken, klickt er tatschlich auf den unsichtbaren Transferiere all dein Geld?-Button auf der Bank-Website. Ist der Benutzer bereits angemeldet, dann wird die Anfrage, die dadurch an den Bank-Server gesendet wird, die echten Anmeldedaten des Benutzers beinhalten und die Anfrage wird erfolgreich sein.

Clickjacking-Abwehrmanahmen

Einbettungen einschrnken

Clickjacking hngt davon ab, dass die Zielwebsite innerhalb der Attrappen-Website des Angreifers in einem <iframe> eingebettet wird. Die Hauptverteidigung besteht darin, diese Fhigkeit zu verbieten oder zumindest einzuschrnken.

Hierfr gibt es zwei relevante Werkzeuge:

• Die frame-ancestors-Direktive in einer Content Security Policy. Mit dieser Direktive knnen Sie genau steuern, welche anderen Dokumente Ihre einbetten drfen.
• Der X-Frame-Options-HTTP-Header. Dieser Header ist weniger detailliert: Er ermglicht es Ihnen nur, das Einbetten vollstndig zu deaktivieren oder es nur fr gleich-originre Dokumente zu erlauben.

Die frame-ancestors-Direktive ist ein Ersatz fr X-Frame-Options. Durch das Setzen von X-Frame-Options zustzlich zu frame-ancestors knnen Sie das Einbetten in Browsern verhindern, die frame-ancestors nicht untersttzen. Da die Browser-Untersttzung fr frame-ancestors sehr gut ist, ist dies kein groes Problem.

Wenn sowohl frame-ancestors als auch X-Frame-Options gesetzt sind, ignorieren Browser, die frame-ancestors untersttzen, X-Frame-Options.

Einschrnkung von Cross-Site-Cookies

Als weitere teilweise Abschwchung sollten Websites das Cookie-Attribut SameSite fr Sitzungs-Cookies auf Lax oder Strict setzen. Anfragen aus eingebetteten Kontexten wie <iframe>-Elementen, die nicht gleichseitig mit dem obersten Dokument sind, werden diese Cookies nicht enthalten, und der Server wird die Anfrage daher nicht als von einem angemeldeten Benutzer kommend behandeln.

Zusammenfassung der Abwehrmanahmen

• Setzen Sie die frame-ancestors CSP-Direktive und den X-Frame-Options HTTP-Antwort-Header, um zu verhindern, dass andere Websites Ihre als <iframe> einbetten, oder um streng zu kontrollieren, welche Sites sie einbetten drfen.

• Setzen Sie das SameSite Cookie-Attribut fr Sitzungs-Cookies auf Lax oder Strict.

Siehe auch

• Clickjacking Defense Cheat Sheet bei owasp.org