Clickjacking: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Clickjacking ist kein rein theoretischer Browser-Trick, sondern ein UI-basierter Angriffsvektor, bei dem eine legitime Anwendung in ein fremdes Dokument eingebettet wird. Das Opfer sieht dabei nicht zwingend die echte Zieloberfläche. Häufig wird die eingebettete Seite transparent gemacht, verschoben, skaliert oder mit Lockelementen überlagert. Ziel ist, dass ein Benutzer auf eine sichtbare Schaltfläche klickt, tatsächlich aber eine Aktion in der eingebetteten Anwendung ausführt. Entscheidend ist nicht nur, ob eine Seite in einem Frame geladen werden kann, sondern ob dadurch eine sicherheitsrelevante Benutzeraktion ausgelöst werden kann.

In realen Assessments taucht Clickjacking oft auf Seiten auf, die von Entwicklungsteams als „nicht kritisch“ eingestuft wurden: Profilseiten, Einstellungsdialoge, Zustimmungsbanner, Zahlungsfreigaben, OAuth-Consent-Seiten, Admin-Formulare oder interne Portale. Genau dort liegt das Problem. Eine Seite muss keine Remote Code Execution ermöglichen, um gefährlich zu sein. Wenn ein eingeloggter Benutzer durch einen manipulierten Klick E-Mail-Adressen ändert, MFA deaktiviert, API-Keys erzeugt oder Berechtigungen vergibt, ist der Schaden unmittelbar.

Der Angriff funktioniert nur unter bestimmten Voraussetzungen. Die Zielseite muss im Browser des Opfers in einem Frame oder iframe ladbar sein. Zusätzlich muss eine Aktion vorhanden sein, die ohne weitere starke Interaktion ausgelöst werden kann. Je weniger visuelle Rückmeldung die Anwendung gibt und je stärker sie auf einfache Klicks setzt, desto besser eignet sie sich für Clickjacking. Anwendungen mit klaren Bestätigungsdialogen, Re-Authentifizierung oder One-Time-Challenges sind deutlich robuster.

Technisch wird Clickjacking häufig zu eng betrachtet. Viele prüfen nur, ob der Header X-Frame-Options fehlt. Das ist zu kurz gedacht. Moderne Prüfungen müssen auch Content-Security-Policy mit frame-ancestors berücksichtigen, Unterschiede zwischen Endpunkten analysieren und verstehen, wie Redirects, Login-Flows, Single-Page-Apps und Reverse Proxies Header verändern. Für die praktische Arbeit mit Burp Suite ist deshalb ein sauberer Workflow entscheidend, beginnend mit Proxy, Scope-Definition und Response-Analyse. Wer Burp noch grundlegend strukturiert aufsetzen will, findet dafür eine passende Basis in Erste Schritte und im übergeordneten Workflow.

Ein weiterer häufiger Denkfehler: Nicht jede framable Seite ist automatisch ein valider Befund. Wenn eine Seite zwar eingebettet werden kann, aber keinerlei zustandsändernde Aktion enthält, ist die Auswirkung begrenzt. Umgekehrt wird eine kleine Konfigurationsseite mit einem einzigen „Speichern“-Button oft unterschätzt, obwohl sie im Kontext eines privilegierten Benutzers hochkritisch ist. Die Bewertung hängt also immer an der Kombination aus Framing-Möglichkeit, Session-Kontext, UI-Verhalten und erreichbarer Aktion.

Die klassische Schutzmaßnahme gegen Clickjacking ist X-Frame-Options. Typische Werte sind DENY und SAMEORIGIN. DENY verhindert das Einbetten vollständig, SAMEORIGIN erlaubt Framing nur durch dieselbe Origin. Historisch existierte auch ALLOW-FROM, das aber in modernen Browsern kaum zuverlässig unterstützt wird und in aktuellen Umgebungen nicht als belastbare Schutzmaßnahme gelten sollte.

Heute ist Content-Security-Policy mit frame-ancestors die präzisere und flexiblere Variante. Damit lässt sich definieren, welche Ursprünge eine Seite einbetten dürfen. Ein Beispiel wäre Content-Security-Policy: frame-ancestors 'none'; für vollständigen Schutz oder frame-ancestors 'self' https://portal.example.com; für kontrolliertes Framing. In modernen Anwendungen sollte frame-ancestors die primäre Schutzschicht sein. X-Frame-Options wird oft zusätzlich gesetzt, um ältere Browser abzudecken.

In der Praxis entstehen viele Fehler nicht durch völliges Fehlen, sondern durch inkonsistente Implementierung. Ein Reverse Proxy setzt Header auf HTML-Seiten, aber nicht auf Fehlerseiten. Ein CDN cached alte Antworten ohne CSP. Eine React- oder Angular-Anwendung liefert den Shell-Response mit Schutzheadern aus, lädt aber sensitive Teilansichten über andere Endpunkte ohne Schutz. Ein SSO-Flow leitet über mehrere Subdomains um, von denen nur ein Teil korrekt abgesichert ist. Genau diese Brüche machen Clickjacking in produktiven Umgebungen realistisch.

Wichtig ist auch das Zusammenspiel mit anderen Browsermechanismen. SameSite-Cookies verhindern nicht automatisch Clickjacking. Sie beeinflussen, ob Cookies in bestimmten Cross-Site-Kontexten gesendet werden, aber ein Frame kann je nach Navigations- und Browserkontext trotzdem mit gültiger Session arbeiten. Ebenso schützt CSRF-Schutz nicht zwingend gegen Clickjacking. Wenn ein Benutzer legitime Aktionen über die echte Anwendung ausführt, werden CSRF-Tokens oft korrekt mitgesendet. Clickjacking missbraucht die Benutzeroberfläche, nicht primär den Request-Aufbau.

• X-Frame-Options: DENY blockiert Framing vollständig.
• X-Frame-Options: SAMEORIGIN erlaubt Framing nur durch dieselbe Origin.
• Content-Security-Policy: frame-ancestors ist die modernere und granularere Kontrolle.
• Fehlende Konsistenz über Redirects, Fehlerseiten und Subdomains ist ein typischer Schwachpunkt.

Ein belastbarer Test betrachtet deshalb nie nur einen einzelnen Response. Es müssen Login-Seiten, Post-Login-Dashboards, Einstellungsseiten, Formular-Submits, Fehlerzustände und alternative Renderpfade geprüft werden. Wer Burp für solche Header- und Response-Prüfungen strukturiert einsetzen will, arbeitet typischerweise mit Proxy History, Repeater und sauber gesetztem Scope.

Ein sauberer Clickjacking-Test beginnt nicht mit einem PoC-HTML, sondern mit einer kontrollierten Datenerhebung. Zuerst wird Burp so eingerichtet, dass alle relevanten Requests und Responses vollständig sichtbar sind. Dazu gehören Browser-Proxy-Konfiguration, Zertifikatsinstallation für HTTPS-Traffic und eine klare Scope-Definition. Ohne sauberen Scope landet zu viel Rauschen in der History, und kritische Endpunkte gehen unter. Für die technische Basis sind Proxy Einrichten und Zertifikat Installieren die zentralen Bausteine.

Im nächsten Schritt wird die Anwendung nicht nur oberflächlich besucht, sondern gezielt entlang sicherheitsrelevanter Workflows durchlaufen: Login, Passwortänderung, Profilverwaltung, Rollen- oder Teamverwaltung, API-Key-Erstellung, Zahlungsfreigaben, Consent-Dialoge und administrative Einstellungen. Jede dieser Seiten kann ein Clickjacking-Kandidat sein. In Burp werden die Responses gesammelt und nach HTML-Dokumenten, Redirects und Headern gefiltert. Besonders wichtig sind Antworten mit Content-Type: text/html, aber auch JSON-basierte Anwendungen dürfen nicht vorschnell ausgeschlossen werden, wenn sie HTML-Shells oder eingebettete Dialoge verwenden.

Ein häufiger Fehler in Assessments ist, nur GET-Endpunkte zu prüfen. Viele kritische Oberflächen werden jedoch erst nach einem POST, einem Redirect oder einer asynchronen Navigation sichtbar. Deshalb muss der gesamte Ablauf nachvollzogen werden. Burp Proxy Intercept ist dabei nützlich, um Übergänge zu verstehen, aber für reproduzierbare Analysen ist die History oft wertvoller als permanentes Intercepting. Responses sollten markiert, kommentiert und bei Bedarf an Repeater gesendet werden.

Für größere Anwendungen lohnt sich ein systematisches Raster. Zuerst werden alle HTML-Antworten identifiziert. Danach wird geprüft, welche davon Schutzheader tragen. Anschließend werden die Seiten nach Kritikalität priorisiert: zustandsändernde Formulare, privilegierte Aktionen, Zahlungs- oder Sicherheitsfunktionen zuerst. Erst danach wird ein PoC gebaut. Dieser Ablauf spart Zeit und verhindert, dass Energie in unkritische framable Seiten fließt.

Burp Scanner kann in manchen Editionen Hinweise auf fehlende Framing-Schutzheader liefern, aber die manuelle Verifikation bleibt Pflicht. Scanner erkennen nicht zuverlässig, ob eine konkrete Benutzeraktion praktisch missbrauchbar ist. Genau dieser Unterschied trennt einen formalen Header-Fund von einem belastbaren Sicherheitsbefund. Wer Burp in solchen Prüfungen tiefer nutzt, kombiniert oft Scanner Passiv mit manueller Analyse in Repeater Anleitung und Response-Vergleichen über Comparer.

Bei der Analyse von Clickjacking-Schutzheadern reicht es nicht, nur auf das Vorhandensein eines Feldes zu schauen. Entscheidend ist, welche finale Antwort der Browser rendert. Redirect-Ketten, 302-Übergänge und Login-Weiterleitungen können dazu führen, dass ein erster Response Schutzheader enthält, die letztlich dargestellte Seite aber nicht. In Burp sollte deshalb immer die vollständige Kette betrachtet werden.

Ein typischer Prüfablauf in Repeater beginnt mit einem Request auf die Zielseite. Danach werden Session-Cookies, Authentifizierungszustand und Redirects nachvollzogen. Relevant ist die endgültige HTML-Antwort. Diese wird auf X-Frame-Options, Content-Security-Policy und gegebenenfalls widersprüchliche Header geprüft. Widersprüche sind nicht selten: Ein Proxy setzt X-Frame-Options: SAMEORIGIN, während die Anwendung eine CSP mit zu weitem frame-ancestors liefert oder umgekehrt.

Auch Caching und Variantenbildung spielen eine Rolle. Manche Anwendungen liefern je nach Sprache, User-Agent, Authentifizierungsstatus oder Feature-Flag unterschiedliche Header aus. Deshalb sollten Tests nicht nur anonym, sondern auch authentifiziert und mit verschiedenen Rollen durchgeführt werden. Gerade Admin-Oberflächen liegen oft hinter anderen Middleware-Komponenten als öffentliche Seiten und verhalten sich anders.

Ein weiterer Punkt ist die Fehlerbehandlung. 403-, 404- oder 500-Seiten werden häufig vergessen. Wenn eine Anwendung sensitive Informationen oder Aktionsbuttons auf Fehlerseiten rendert und dort kein Framing-Schutz aktiv ist, kann das relevant sein. Ebenso problematisch sind Dialoge oder eingebettete Teilseiten, die über alternative Pfade ausgeliefert werden, etwa /settings/modal, /confirm oder /consent.

Ein minimalistisches Beispiel für eine zu prüfende Antwort sieht so aus:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'
X-Frame-Options: DENY
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

Fehlt frame-ancestors oder X-Frame-Options, ist das ein erster Hinweis. Kritischer wird es, wenn eine Seite explizit Framing erlaubt oder wenn Header nur auf Teilbereichen vorhanden sind. In Burp lassen sich solche Unterschiede gut mit Comparer Anwendung nachvollziehen, etwa zwischen Benutzer- und Admin-Rolle oder zwischen anonymem und authentifiziertem Zustand.

Ein Clickjacking-PoC ist nur dann wertvoll, wenn er die reale Benutzerinteraktion glaubwürdig nachbildet. Ein bloßer iframe-Nachweis zeigt nur, dass Framing möglich ist. Für eine belastbare Bewertung muss gezeigt werden, dass ein Benutzer mit hoher Wahrscheinlichkeit eine sicherheitsrelevante Aktion ausführt. Dazu wird die Zielseite in ein kontrolliertes HTML-Dokument eingebettet und die Position des iframes so angepasst, dass ein sichtbares Lockelement exakt über dem echten Ziel-Button liegt.

Ein einfacher Startpunkt sieht so aus:

<html>
<head>
  <style>
    body { margin:0; overflow:hidden; }
    #bait {
      position:absolute;
      top:120px;
      left:180px;
      width:220px;
      height:60px;
      z-index:2;
      background:#2d89ef;
      color:#fff;
      border:none;
      font-size:20px;
      cursor:pointer;
    }
    #target {
      position:absolute;
      top:-340px;
      left:-520px;
      width:1400px;
      height:1200px;
      opacity:0.01;
      z-index:1;
      border:none;
    }
  </style>
</head>
<body>
  <button id="bait">Video starten</button>
  <iframe id="target" src="https://target.example/account/security"></iframe>
</body>
</html>

Der eigentliche Aufwand liegt nicht im HTML, sondern in der Ausrichtung. Die Koordinaten müssen so gewählt werden, dass der sichtbare Köder genau über dem echten Button liegt. Responsive Layouts, Zoom-Stufen, Browserleisten und dynamische Inhalte erschweren das. In realen Tests wird deshalb oft mit Browser-Entwicklertools, schrittweiser Positionsanpassung und mehreren Viewports gearbeitet. Ein PoC, der nur auf einem einzigen Bildschirmmaß funktioniert, ist schwächer als einer, der unter typischen Bedingungen reproduzierbar bleibt.

Wichtig ist außerdem die Frage, ob die Zielaktion einen einzelnen Klick benötigt oder mehrere Interaktionen. Mehrstufige Clickjacking-Angriffe sind möglich, aber deutlich unzuverlässiger. Wenn zuerst ein Tab aktiviert und danach ein Bestätigungsbutton getroffen werden muss, sinkt die praktische Ausnutzbarkeit. Ebenso relevant sind Hover-Effekte, Scrollzwang, modale Dialoge und Fokuswechsel. Jede zusätzliche Hürde reduziert die Erfolgswahrscheinlichkeit.

Ein guter PoC dokumentiert deshalb nicht nur „framable ja/nein“, sondern mindestens folgende Punkte: Zielrolle, Zielseite, konkrete Aktion, Anzahl nötiger Klicks, notwendige Vorbedingungen, Stabilität der Positionierung und sichtbare Benutzerhinweise. Genau daraus ergibt sich später die Risikobewertung. Wer solche Prüfungen in einen größeren Testkontext einordnet, verbindet sie oft mit Themen wie Session Management oder Login Testing, weil die Sessionlage direkt bestimmt, ob der Angriff praktisch funktioniert.

Die häufigste Fehlkonfiguration ist das vollständige Fehlen von Framing-Schutz auf einzelnen Endpunkten. Das passiert oft, wenn Header zentral auf Webserver-Ebene gesetzt werden, aber bestimmte Pfade über einen anderen Upstream, ein Legacy-System oder einen separaten Application-Server laufen. Besonders anfällig sind Admin-Bereiche, SSO-Komponenten, Upload-Dialoge und eingebettete Hilfeseiten.

Ebenso verbreitet ist eine scheinbar korrekte, aber faktisch wirkungslose Konfiguration. Beispiele sind falsch geschriebene Headernamen, ungültige CSP-Syntax, mehrere widersprüchliche CSP-Header oder ein frame-ancestors, das durch Copy-and-Paste zu weit gefasst wurde. In Multi-Tenant-Umgebungen findet sich oft ein Muster wie frame-ancestors *.example.com, obwohl einzelne Subdomains von Dritten kontrolliert oder schwächer abgesichert sind. Damit wird Clickjacking nicht verhindert, sondern nur auf den internen Namensraum verschoben.

Ein weiterer Klassiker ist die Annahme, dass JavaScript-Framebuster ausreichend Schutz bietet. Historische Skripte wie if (top !== self) top.location = self.location; sind kein verlässlicher Ersatz für Browser-seitige Header. Sie können durch Sandbox-Kontexte, Timing, Browserverhalten oder restriktive Policies beeinträchtigt werden und sind in modernen Sicherheitskonzepten nur noch ergänzend zu betrachten.

• Header werden nur auf Hauptseiten gesetzt, nicht auf modalen Teilansichten oder Fehlerseiten.
• CSP ist vorhanden, enthält aber kein frame-ancestors oder eine zu breite Freigabe.
• Legacy-Komponenten liefern HTML ohne zentrale Security-Header aus.
• Entwicklungsteams verlassen sich auf JavaScript-Framebuster statt auf Browser-Policies.

Auch Produktentscheidungen führen zu Schwachstellen. Manche Teams wollen bewusst Framing erlauben, etwa für Partnerportale, Widgets oder interne Portalintegration. Dann wird aus Bequemlichkeit global SAMEORIGIN entfernt oder eine breite Allowlist definiert. Das Problem ist nicht die Geschäftsanforderung selbst, sondern die fehlende Segmentierung. Wenn Framing für einen einzelnen Report-Viewer nötig ist, darf daraus keine globale Freigabe für Konto- und Sicherheitsseiten werden.

In Burp lassen sich solche Inkonsistenzen gut sichtbar machen, wenn Responses nach Pfaden, Hosts und Headerprofilen gruppiert werden. Gerade in großen Umgebungen ist das oft der schnellste Weg, um zu erkennen, welche Komponenten aus dem Sicherheitsstandard herausfallen. Ergänzend lohnt sich ein Blick auf Dashboard und Einstellungen, um die Arbeitsumgebung für längere Analysen sauber zu halten.

Die Schwere eines Clickjacking-Befunds hängt fast nie allein am fehlenden Header. Entscheidend ist, welche Aktion im Session-Kontext des Opfers ausgelöst werden kann. Eine framable Marketing-Seite ohne Interaktion ist meist niedrig zu bewerten. Eine framable Seite zum Deaktivieren von MFA, zum Ändern der Recovery-E-Mail oder zum Erzeugen eines API-Tokens ist dagegen hochkritisch, selbst wenn technisch „nur“ ein Klick missbraucht wird.

Für eine belastbare Bewertung müssen mehrere Faktoren zusammen betrachtet werden. Erstens: Welche Rolle ist betroffen? Ein Angriff gegen normale Benutzer ist anders zu bewerten als gegen Administratoren oder Abrechnungsverantwortliche. Zweitens: Wie viele Interaktionen sind nötig? Ein einzelner Klick ist deutlich realistischer als ein komplexer Mehrschrittprozess. Drittens: Gibt es visuelle oder technische Hürden wie Re-Authentifizierung, Captcha, WebAuthn-Bestätigung oder Transaktionssignatur? Viertens: Wie stabil lässt sich die Oberfläche ausrichten?

Auch die Angriffsoberfläche spielt eine Rolle. Eine interne Anwendung mit restriktivem Zugriff ist nicht automatisch sicher, aber die Exponierung ist geringer als bei einem öffentlich erreichbaren SaaS-Portal. Umgekehrt kann ein scheinbar kleiner Befund in einer stark genutzten B2B-Anwendung enorme Auswirkungen haben, wenn privilegierte Benutzer regelmäßig eingeloggt sind und selten ausgeloggt werden.

Ein praxisnaher Bewertungsansatz fragt nicht nur „kann geframed werden?“, sondern „welche geschäftskritische Aktion lässt sich mit welcher Erfolgswahrscheinlichkeit auslösen?“. Daraus ergibt sich ein viel präziseres Bild als aus rein formalen Header-Checks. In Berichten sollte deshalb immer die konkrete missbrauchbare Aktion benannt werden: Rollenänderung, Zustimmungsfreigabe, Zahlungsbestätigung, Sicherheitsoption ändern, Token erzeugen oder Datenexport starten.

Wenn Clickjacking mit anderen Schwächen kombiniert wird, steigt die Relevanz weiter. Beispiele sind schwache Sitzungsverwaltung, fehlende Re-Authentifizierung vor sensiblen Änderungen oder unzureichende Bestätigungsmechanismen. In solchen Fällen ist Clickjacking nicht isoliert zu betrachten, sondern als Verstärker anderer Designprobleme. Verwandte Prüfbereiche sind etwa Csrf, Cookies und Authentication Bypass, weil dort oft dieselben Schutzannahmen sichtbar werden.

Die primäre Gegenmaßnahme ist klar: sensitive HTML-Seiten dürfen nicht beliebig eingebettet werden. In modernen Anwendungen sollte dafür Content-Security-Policy mit frame-ancestors 'none' oder einer eng definierten Allowlist verwendet werden. Zusätzlich kann X-Frame-Options: DENY oder SAMEORIGIN gesetzt werden, um ältere Browser abzudecken. Wichtig ist die konsistente Auslieferung über alle relevanten Pfade, Hosts und Fehlerseiten hinweg.

Wenn legitimes Framing geschäftlich erforderlich ist, muss segmentiert werden. Nicht die gesamte Anwendung wird freigegeben, sondern nur die wirklich benötigte Komponente. Das gelingt über getrennte Pfade, Subdomains oder dedizierte Render-Endpunkte mit enger frame-ancestors-Policy. Sicherheitskritische Funktionen wie Kontoänderungen, Rollenverwaltung oder Zahlungsfreigaben bleiben davon strikt getrennt.

Zusätzlich sollte das UI-Design sensible Aktionen absichern. Re-Authentifizierung vor sicherheitsrelevanten Änderungen, explizite Bestätigungsdialoge, WebAuthn-Prompts, Transaktionszusammenfassungen und serverseitige Plausibilitätsprüfungen reduzieren die praktische Ausnutzbarkeit erheblich. Solche Maßnahmen ersetzen Framing-Schutz nicht, bilden aber eine wichtige zweite Verteidigungslinie.

Auch organisatorisch ist Konsistenz entscheidend. Security-Header sollten nicht in einzelnen Controllern oder Templates verteilt gepflegt werden, sondern zentral in Reverse Proxy, Middleware oder Security Gateway definiert und automatisiert getestet werden. Regressionen entstehen oft nach Framework-Upgrades, CDN-Änderungen oder dem Einbinden neuer Legacy-Komponenten.

• Standardmäßig frame-ancestors 'none' für sensitive Seiten setzen.
• Legitimes Framing nur für klar abgegrenzte Komponenten erlauben.
• Vor kritischen Aktionen Re-Authentifizierung oder starke Bestätigung verlangen.
• Header zentral ausrollen und automatisiert gegen Regression prüfen.

Für Teams, die Burp in wiederkehrenden Prüfungen einsetzen, lohnt sich ein standardisierter Testkatalog: anonyme Seiten, Login, Kontoeinstellungen, Admin-Funktionen, Fehlerseiten, SSO-Übergänge und eingebettete Komponenten. So werden Schutzlücken nicht nur einmalig, sondern dauerhaft erkannt. In größeren Umgebungen kann das mit Automatisierung und klar definierten Prüfpfaden im Web Pentest verankert werden.

Ein robuster Workflow für Clickjacking-Tests mit Burp Suite folgt einer klaren Reihenfolge. Zuerst wird die Anwendung vollständig durchlaufen und der relevante Traffic gesammelt. Danach werden HTML-Responses identifiziert und auf Framing-Schutzheader geprüft. Anschließend werden nur die Seiten priorisiert, die sicherheitsrelevante Aktionen enthalten. Erst dann folgt der PoC-Bau. Diese Reihenfolge verhindert Aktionismus und sorgt dafür, dass der Bericht später nicht aus isolierten Header-Funden besteht, sondern aus nachvollziehbaren, reproduzierbaren Ergebnissen.

In der Praxis hat sich ein Vier-Phasen-Modell bewährt. Phase eins ist Discovery: Scope setzen, Anwendung kartieren, Rollen verstehen. Phase zwei ist Header-Analyse: Welche Seiten sind framable, welche nicht, wo gibt es Inkonsistenzen? Phase drei ist Exploitability: Lässt sich eine konkrete Aktion mit realistischem Aufwand auslösen? Phase vier ist Reporting: technische Ursache, betroffene Endpunkte, reproduzierbarer PoC, geschäftliche Auswirkung und konkrete Abhilfe.

Burp Repeater ist in Phase zwei und drei besonders wertvoll, weil Requests dort stabil reproduziert und Varianten schnell verglichen werden können. Proxy History liefert den Überblick, Comparer hilft bei Header-Differenzen, und bei größeren Anwendungen kann passives Scanning zusätzliche Kandidaten markieren. Entscheidend bleibt aber die manuelle Bewertung. Ein fehlender Header ohne missbrauchbare Aktion ist nicht dasselbe wie ein framable Sicherheitsdialog mit Ein-Klick-Bestätigung.

Ein typischer Ablauf kann so aussehen:

1. Anwendung authentifiziert und anonym durchlaufen
2. HTML-Responses in Proxy History filtern
3. X-Frame-Options und CSP frame-ancestors vergleichen
4. Kritische Seiten an Repeater senden
5. Finale Render-Responses nach Redirects prüfen
6. PoC für priorisierte Seiten bauen
7. Klickpfad, Vorbedingungen und Erfolgswahrscheinlichkeit dokumentieren

Gerade bei komplexen Anwendungen lohnt sich Disziplin in der Dokumentation. Jeder Kandidat sollte mit URL, Rolle, Headerstatus, Aktionsart und Teststatus erfasst werden. So bleibt auch nach mehreren Stunden klar, welche Seiten nur formal auffällig waren und welche tatsächlich ausnutzbar sind. Wer Burp bereits für andere Schwachstellen nutzt, kann Clickjacking sauber in denselben Prüfprozess integrieren, etwa neben Xss, Idor oder Ssrf.

Ein sauberer Befund endet nicht bei „Header fehlt“. Er zeigt, welche Seite betroffen ist, welche Aktion missbraucht werden kann, wie der Angriff praktisch funktioniert und welche Gegenmaßnahme die Ursache wirklich beseitigt. Genau das trennt oberflächliche Tool-Nutzung von belastbarer Pentest-Arbeit.