Coders Conquer Security: Share & Learn Serie – Cross-Site Request Forgery

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 Zugangsdaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Schwachstellen ignorieren sollten, da die Erstattung gestohlener Gelder bei einem rein finanziellen Angriff letztendlich in der Verantwortung der Hosting-Website mit dem unsicheren Code liegen kann. Und wenn der betroffene Benutzer seine Zugangsdaten verliert oder sein Passwort unwissentlich geändert wird, könnte ein Krimineller mit dieser gestohlenen Identität großen Schaden anrichten, insbesondere wenn das Opfer über privilegierte Zugriffsrechte verfügt.

CSRF-Angriffe sind ziemlich komplex und erfordern mehrere Ebenen, um erfolgreich zu sein. Mit anderen Worten: Damit sie funktionieren, muss eine ganze Reihe von Dingen zugunsten des Angreifers schiefgehen. Dennoch sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt auf das Konto eines Hackers überweisen oder ihm ermöglichen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach Plan des Hackers läuft, erfährt der betroffene Benutzer möglicherweise nie, dass er Opfer eines Angriffs geworden ist.

Die gute Nachricht ist, dass es aufgrund der vielen Voraussetzungen für einen erfolgreichen CSRF-Angriff einige hervorragende Verteidigungstechniken gibt, die diese Angriffe wirksam stoppen können.

Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen erörtern:

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

Wie funktionieren CSRF-Angriffe?

Da erfolgreiche CSRF-Angriffe die Möglichkeit bieten, direkt Geld, Waren oder Zugangsdaten von betroffenen Benutzern zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung erforderlich ist, sehr beliebt. Und da sie häufig 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-Angriffe. Aber es handelt sich in jedem Fall um CSRF-Angriffe, und die Techniken zu ihrer Abwehr sind identisch.

Ein CSRF-Angriff kann stattfinden, wenn ein Benutzer bei einer Website angemeldet ist, um Geschäfte zu tätigen oder zu arbeiten. Der entscheidende Punkt ist, dass der Benutzer bei einer Website oder Anwendung angemeldet und aktiv authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft nutzen Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie zu einer kompromittierten 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 Benutzerpassworts oder das Überweisen von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer stammen. Warum sollte sie auch etwas anderes annehmen? Der Benutzer hat sich bereits authentifiziert und alle für den Zugriff auf die Website erforderlichen Passwörter bereitgestellt. Er befindet sich möglicherweise sogar innerhalb eines Geofence und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Gelder überweisen möchte, gibt es keinen Grund, daran zu zweifeln, dass er selbst die Anfrage stellt.

Wenn man die Elemente des Angriffs aufschlüsselt, wird deutlich, warum dieser für den Angreifer so schwer durchzuführen ist. Zunächst einmal muss der Benutzer aktiv bei der Website authentifiziert sein, auf der der Angriff stattfindet. 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 zudem gezwungen, eine Menge Aufklärung über die Ziel-Website zu betreiben, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jedes Feedback der Website geht an das Opfer, nicht an den Angreifer. Wenn der Angreifer nicht in der Lage ist, Beweise für den Erfolg seines Angriffs zu sehen, wie etwa plötzlich auf seinem Konto erscheinendes Geld, wird er nicht einmal sofort wissen, ob er erfolgreich war.

Innerhalb der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet sein muss und man wissen muss, welche Skripte die Ziel-Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website variiert.

Nehmen wir an, 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 senden, 100 $ an einen Benutzer namens NancySmith12 zu überweisen.

Wenn der betroffene Benutzer jedoch eine E-Mail erhält, die möglicherweise so getarnt ist, als käme sie von einem Kollegen, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet sein:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Könntest du kurz über diesen Quartalsbericht schauen?<a></a></a>

Wenn der betroffene Benutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, würde sein Browser die Anwendung anweisen, 100.000 $ auf das Konto von ShadyLady15 zu überweisen.

Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sieht, das den Browser aber dennoch dazu veranlassen kann, die Anfrage zu senden, etwa so:

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

Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff bemerkt.

Warum ist CSRF so gefährlich?

CSRF-Angriffe sind heute aus demselben Grund beliebt wie Ransomware-Attacken: Sie erfordern nur sehr wenige Schritte zwischen dem Angreifer und dem Geld des Opfers. Bei Ransomware werden Systeme verschlüsselt und Benutzer zur Zahlung erpresst, um die Daten zu entschlüsseln. Bei einem CSRF-Angriff sind noch weniger Schritte nötig. Wenn sie funktionieren, überweisen die Opfer das Geld einfach 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 genutzt werden, um ein Netzwerk über legitime Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit nutzen, um das Passwort eines Administrators zu ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Backdoors zu installieren.

Obwohl es viel Arbeit und bis zu einem gewissen Grad auch Glück erfordert, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem eigentlichen Ziel einem Lottogewinn gleichkommen. Bei einem Netzwerkangriff erfordern fast alle anderen Methoden monatelange, unauffällige Aufklärung, um unter dem Radar von SIEM und Sicherheitsteams zu bleiben. Ein einzelner CSRF-Angriff hingegen kann viele Schritte der Cyber-Kill-Chain überspringen und den Angreifer sehr nah an sein Ziel bringen.

Wie stoppe ich CSRF-Angriffe?

Im Gegensatz zu den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer entwickelt haben, um einen Browser zu Anfragen zu zwingen, die der Benutzer nicht möchte und von denen er vielleicht nicht einmal etwas weiß. Aber man kann sie abwehren.

Eine der besten Methoden besteht darin, dass Entwickler bei jeder neuen Sitzung ein CSRF-Token zur Identität des Benutzers hinzufügen. Es sollte aus einer Zeichenfolge eindeutiger, zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie dann die CSRF-Token-Anfrage als verstecktes Feld in Formulare ein, die vom Server bei jeder neuen Anfrage geprüft werden. Angreifer, die Anfragen über den Browser eines Benutzers senden, kennen das versteckte Token-Feld nicht und können es erst recht nicht herausfinden, sodass alle ihre Anfragen fehlschlagen.

Eine noch einfachere Methode, die kaum Programmierung erfordert, ist das Hinzufügen einer Captcha-Abfrage für sensible Vorgänge wie Passwortänderungen oder Überweisungsaufträge. Es kann so einfach sein, den Benutzer auf eine Schaltfläche klicken zu lassen, um zu bestätigen, dass der Anfragende kein Roboter oder in diesem Fall ein CSRF-Skript ist. Angreifer können keine Antwort auf die Abfrage skripten, und Benutzer, die plötzlich eine CAPTCHA-Abfrage erhalten, ohne selbst eine Überweisung getätigt zu haben, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung von Einmalpasswörtern über einen Drittanbieter-Token, wie ein Smartphone, verwendet werden, je nachdem, wie sehr ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.

Schließlich verfügen viele Browser wie Microsoft Edge oder Google Chrome, auch wenn dies kein absolut sicherer Schutz ist, mittlerweile über Same-Origin-Policy-Beschränkungen, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Benutzer dazu zu zwingen, Ihre Website mit den aktuellsten Versionen dieser Browser zu nutzen, kann helfen, eine weitere Ebene der CSRF-Sicherheit aufzubauen, ohne die Entwicklungsteams zu belasten.

CSRF den Riegel vorschieben

Angesichts des hohen potenziellen Gewinns werden CSRF-Angriffe wahrscheinlich nie ganz verschwinden, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie dauerhaft aus Ihrem Netzwerk verbannen können.

Für weiterführende Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendiges Dokument diese Schwachstelle in ihrer Entwicklung verfolgt. Wenn Sie Ihr Sicherheitswissen vertiefen möchten, können Sie lernen, diese und viele weitere Bedrohungen zu besiegen, indem Sie den Secure Code Warrior Blog besuchen.

Bereit, Ihr neues Verteidigungswissen auf die Probe zu stellen? Testen Sie noch heute die kostenlose Demo der Secure Code Warrior-Plattform.