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 verfügt, mit dem alle Gelder des Benutzers an den Angreifer überwiesen werden können – obwohl dies offensichtlich unrealistisch ist, ist es plausibel, dass die Seite einige interaktive Elemente hat, die eine sensible Operation ausführen.

Der Angreifer erstellt eine Webseite, die Folgendes enthält:

• 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 für die Seite sorgt der Angreifer dafür, 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 können):

Wenn der Benutzer versucht, auf „Klicken Sie hier für ein kostenloses Kätzchen!“ zu klicken, klickt er tatsächlich 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-Abwehrmaßnahmen

Einbettungen einschränken

Clickjacking hängt davon ab, dass die Zielwebsite innerhalb der Attrappen-Website des Angreifers in einem <iframe> eingebettet wird. Die Hauptverteidigung besteht darin, diese Fähigkeit zu verbieten oder zumindest einzuschränken.

Hierfür gibt es zwei relevante Werkzeuge:

• Die frame-ancestors-Direktive in einer Content Security Policy. Mit dieser Direktive können Sie genau steuern, welche anderen Dokumente Ihre einbetten dürfen.
• Der X-Frame-Options-HTTP-Header. Dieser Header ist weniger detailliert: Er ermöglicht es Ihnen nur, das Einbetten vollständig zu deaktivieren oder es nur für gleich-originäre Dokumente zu erlauben.

Die frame-ancestors-Direktive ist ein Ersatz für X-Frame-Options. Durch das Setzen von X-Frame-Options zusätzlich zu frame-ancestors können Sie das Einbetten in Browsern verhindern, die frame-ancestors nicht unterstützen. Da die Browser-Unterstützung für frame-ancestors sehr gut ist, ist dies kein großes Problem.

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

Einschränkung von Cross-Site-Cookies

Als weitere teilweise Abschwächung sollten Websites das Cookie-Attribut SameSite für 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 Abwehrmaßnahmen

• 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 dürfen.

• Setzen Sie das SameSite Cookie-Attribut für Sitzungs-Cookies auf Lax oder Strict.

Siehe auch

• Clickjacking Defense Cheat Sheet bei owasp.org