Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.

CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.

Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.

Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:

• Wie sie funktionieren
• Warum sie so gefährlich sind
• Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.

Wie funktionieren CSRF-Angriffe?

Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.

Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.

Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.

Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.

Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.

Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.

Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.

Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.

Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.

Warum ist CSRF so gefährlich?

CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.

Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.

Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.

Wie kann ich CSRF-Attacken stoppen?

Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.

Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.

Eine noch einfachere Methode, die nicht viel Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu allen sensiblen Daten, wie z. B. Anfragen zur Änderung von Passwörtern oder Überweisungsaufträgen. Das kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Anfragende kein Roboter ist, oder in diesem Fall ein CSRF-Skript. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Herausforderung erhalten, ohne vorher etwas zu tun, wie z. B. eine Überweisungsanforderung zu stellen, werden wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmal-Passworts mit einem Token eines Drittanbieters, z. B. einem Smartphone, verwendet werden, je nachdem, wie sehr eine Organisation die Arbeit im Namen der Sicherheit verlangsamen möchte.

Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.

Die Tür für CSRF zuschlagen

Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.

Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.

Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.