Clickjacking eindämmen – auf die DevSecOps-Art!

In den vergangenen Wochen haben wir über unser Bug-Bounty-Programm einige Meldungen erhalten, dass interne Domains von uns für Clickjacking-Angriffe anfällig sind. Natürlich war unsere Hauptwebsite von Anfang an geschützt, doch bei einigen kleinen Subdomains fehlte dieser Schutz. Das Problem zu beheben war einfach. Wir wollten jedoch noch einen Schritt weitergehen, alle unsere Endpunkte schützen und uns künftig keine Gedanken mehr darüber machen müssen. Sehen wir uns an, wie wir das umgesetzt haben.

Was ist Clickjacking?

Laut der Definition von OWASP:

„Clickjacking, auch bekannt als „UI-Redress-Angriff“, liegt vor, wenn ein Angreifer mehrere transparente oder undurchsichtige Ebenen verwendet, um einen Benutzer dazu zu bringen, auf einer anderen Seite auf eine Schaltfläche oder einen Link zu klicken, obwohl er eigentlich auf die oberste Seite klicken wollte. So „kapert“ der Angreifer Klicks, die für seine Seite bestimmt waren, und leitet sie auf eine andere Seite um, die höchstwahrscheinlich einer anderen Anwendung, Domain oder beidem gehört.“

Das ist ein ziemlich schwerwiegender Angriff. Häufig erstellt der Angreifer eine Website und bettet die Zielseite in ein iframe ein. So kann er ganz einfach einen Clickjacking-Angriff starten und ahnungslose Benutzer dazu verleiten, auf der schädlichen Website zu klicken.

Clickjacking eindämmen

Wie oben gezeigt, wird für den Angriff meist ein iframe verwendet. Wir müssen dem Browser also nur mitteilen, dass unsere Website nicht in einem iframe geladen werden darf, und schon ist dieser Angriff abgewehrt! Zum Glück gibt es genau dafür einen Header: x-frame-options. Wir müssen ihn also nur setzen – und fertig!

Es gibt jedoch ein kleines Problem: Woher wissen wir, welche unserer Endpunkte diesen Header haben und welche nicht? Snyk verfügt über zahlreiche Endpunkte, und es ist sehr schwierig, den Überblick über sie alle zu behalten. Wir brauchen ein Tool, das uns dabei hilft!

OWASP AMASS im Einsatz

OWASP AMASS ist ein Tool von OWASP, das „detailliertes Mapping der Angriffsfläche und das Auffinden von Assets“ ermöglicht – genau das, was wir brauchen. Zu den Funktionen gehört die DNS-Aufzählung, bei der alle DNS-Einträge für eine bestimmte Domain gefunden werden. Die Anwendung ist ganz einfach:

amass enum -d <domain> -o out.txt

Damit werden alle relevanten Einträge gesucht und in out.txt ausgegeben. Jetzt müssen wir nur noch die Liste durchgehen und bei jedem DNS-Eintrag prüfen, ob der Header x-frame-options vorhanden ist. Dafür verwenden wir ein Tool, das passenderweise Security Headers Checker heißt.

Security-Header scannen

Security Headers Checker ist ein Python-Tool, das eine bestimmte URL auf verschiedene Sicherheitsprobleme untersuchen kann. Dazu gehören fehlende Security-Header wie x-frame-options. Es bietet viele nützliche Funktionen. Besonders hilfreich: In der README-Datei sind alle erkennbaren Probleme und ihre Bedeutung ausführlich dokumentiert. Für diesen Anwendungsfall ist vor allem relevant, dass das Tool eine Datei mit einer URL-Liste akzeptiert – etwa die von AMASS erstellte. Wir müssen also nur Folgendes ausführen:

python ./securityheaders/securityheaders.py out.txt --checkers HeaderMissingChecker --format json  --flatten --file ./result

Wir übergeben die Ausgabe von amass und beschränken die Prüfung auf HeaderMissingChecker, denn genau darum geht es uns. Als Nächstes folgt das Format. Ich wähle JSON, es werden aber viele weitere Formate unterstützt.

Jetzt haben wir eine Datei mit allen anfälligen URLs. Mit einem kurzen JQ-Trick filtern wir daraus nur die URLs ohne x-frame-options-Header heraus, denn Security Headers meldet auch viele andere interessante Header. Das geht ganz einfach:

jq 'map(select(.header == "x-frame-options"))’ ./result/1.csv 

Ja, die Ausgabedatei hat die Endung csv – das ist ein Fehler :)

Jetzt haben wir die Liste. Was noch fehlt, ist die eigentliche Arbeit: die Liste durchzugehen und alle anfälligen Endpunkte zu korrigieren. Als Nächstes führen wir den Vorgang täglich aus, damit keine neuen Endpunkte ohne x-frame-option-Header hinzukommen. Außerdem müssen wir sicherstellen, dass es sich bei allen gefundenen URLs tatsächlich um Websites handelt – APIs benötigen keinen Clickjacking-Schutz.

Fazit

Dieser Vorfall zeigt, wie wichtig ein Bug-Bounty-Programm ist: Es ermöglicht Sicherheitsforschern, Schwachstellen in Ihrem System zu melden. Noch wichtiger ist jedoch der richtige Umgang mit diesen Meldungen. Es reicht nicht, das Problem zu beheben. Ohne einen Test, der den Fehler reproduziert, können Sie nicht sicherstellen, dass er nicht erneut auftritt. Wir sind alle Menschen und machen Fehler. Sorgen wir dafür, dass unser Code uns dabei hilft, denselben Fehler nicht noch einmal zu machen!