CSRF oder XSRF steht für Cross Site Request Forgery und bezeichnet die Fälschung von standortübergreifenden Anfragen. Bei dieser Methode manipulieren Angreifer Webanwendungen, indem sie die Rechte authentifizierter Anwender ausnutzten. In diesem Artikel erklären wir, wie sie dabei vorgehen, welche Varianten es gibt und wie Angreifer CSRF mit XSS (Cross Site Scripting) kombinieren können.
CSRF zielt primär auf Benutzer von Webanwendungen bzw. Webseiten ab. Mit dieser Methode können Angreifer eine Webanwendung so manipulieren, dass beim Opfer unerwünschte Transaktionen zugunsten des Angreifers ausgeführt werden.
Damit CSRF funktioniert, muss sich das Opfer in einem angemeldeten Zustand (authentifiziert) innerhalb der Webanwendung befinden. Im authentifizierten Zustand stehen mehr Funktionalitäten zur Verfügung als im nicht-authentifizierten Zustand. Diese Situation macht sich der Angreifer beim Cross Site Request Forgery zunutze.
Für eine Cross Site Request Forgery nutzen Angreifer in der Regel ein Formular (z. B. ein Inputfeld für eine Suche oder Anmeldung auf einer Webseite). Dieses Feld haben sie im Vorfeld so manipuliert, dass die eingegebenen Informationen über eine HTTP-Anfrage an einen anderen Empfänger gesendet werden. Bei diesem Angriff zielen sie auf Opfer ab, die eine aktuelle Nutzer-Session der Webanwendung und im Idealfall Administrator-Rechte besitzen.
Alternativ nutzen Angreifer CSRF, um Systembefehle auf dem jeweiligen Webserver (Zielsystem) auszuführen. Das funktioniert, weil der Browser oder die Anwendung die tatsächliche Herkunft der Anfrage nicht identifizieren kann. Dies stellt eine Schwäche heutiger Browser dar.
Wenn das Opfer eine aktuelle Nutzer-Session einer Webanwendung besitzt und zudem Administrator ist, dann können Angreifer im Namen des Opfers beispielsweise ein Benutzeraccount auf einem sensitiven System erstellen.
Eine weitere mögliche Auswirkungen der abgefangenen HTTP-Requests ist eine Benutzerrechte-Erweiterung sein. Dadurch können Angreifer Befehle ausführen, die vorher unzugänglich waren. Außerdem können vollständige Benutzer-Sitzungen einer Webanwendung in die Hände des Angreifers fallen (Session Hijacking / Session Riding).
Die Opfer bemerken einen solchen Angriff häufig nicht, weil die vom Angreifer gesteuerten Befehle meist im Hintergrund ausgeführt werden. Es ist jedoch für die Angreifer nicht möglich, CSRF unmittelbar auf dem Computersystem auszuführen. Dazu bedarf es weiterer Angriffsmethoden.
Der Angreifer kann eine manipulierten HTTP-Request (sprich: einen Link) erstellen und versuchen, dem Opfer diesen Link unterzujubeln. Diesen infizierten Link schickt er dann, meist mit präparierten Parametern an der URL verkettet, über eine sogenannte Phishing-Mail (Social Engineering) an das Opfer. Den vollständigen Link bzw. verdächtige Bestandteile eines Links mit Parametern kann er durch URL-Spoofing verschleiern, ohne dass es dem Opfer auffällt. Klickt das Opfer nun auf den Link in der Phishing-Mail, so wird die gewünschte Aktion zugunsten des Angreifers (Cross Site Request Forgery) ausgeführt.
Ein infizierter Link zum Erstellen eines neuen Benutzers auf einer Webanwendung durch das Opfer könnte wie folgt aussehen:
www.zielsystem.de/adminpanel.php?action=createUser&username= hacker&password=hacker
Basierend auf einer Phishing-Mail kann der Angreifer das Opfer ebenso auf eine infizierte Webseite leiten. Hierzu bedarf es nicht unbedingt einer Manipulation der Parameter in einer URL-Anfrage (GET-Parameter Manipulation). Es ist auch möglich, im Vorfeld manipulierte Elemente auf der Website zu implementieren. Ein Beispiel ist ein Bild mit einem verstecktem CSRF Befehl, der beim Anklicken im Hintergrund die gewünschte Aktion des Angreifers durch das Opfer ausführt.
Ein weiterer Anwendungsfall für CSRF kann ein bereits manipuliertes Formularfeld sein, welches die Daten nicht ans eigentliche Ziel, sondern an den Angreifer sendet. So leitet der Angreifer die Kompromittierung eines Benutzeraccounts ein.
Session Daten liegen im Cache des Browsers. Es ist der Anwendung überlassen, wie mit diesen Daten umgegangen wird. Beim Beenden des Browsers wird der Cache in der Regel geleert. Bestenfalls geschieht das aber durch die Anwendung.
Session Daten repräsentieren einen Zustand innerhalb einer Webanwendung. Dazu zählen beispielsweise der Fortschritt auf einer Shop-Seite (Warenkorbeinträge) oder die Information, ob ein Benutzer angemeldet ist oder nicht. Der Angreifer fokussiert sich in hierbei gezielt auf die wichtigsten Daten.
Es ist ein gewisses Know-How über das Zielsystem notwendig, um einen erfolgreichen CSRF-Angriff durchzuführen. Auf die oben beschriebenen Cache-Daten zielt der Angreifer ab, um sich ggfs. als Benutzer (Opfer) bei der Webanwendung anmelden zu können.
Folgende Browser Caches gibt es:
Eine weitere Variante von CSRF baut auf einer bestehenden Schwachstelle einer Webanwendung auf: dem Cross Site Scripting (XSS).
XSS beschreibt im Wesentlichen das Ausführen von JavaScript Code (Programmiersprache in der Webentwicklung) auf der Clientseite des Opfers, wird von aktuellen Browsern unterstützt und ist initial in jedem Browser aktiv. Mit JavaScript lassen sich aufeinander aufbauende Anweisungen programmieren, die es ermöglichen, komplexere Aufgaben innerhalb einer Webanwendung zu realisieren und zugunsten des Angreifers ausführen zu lassen. Hierbei kann nach dem Ausführen von XSS die gewünschte Aktion durch CSRF auf Opferseite umgesetzt werden.
Ein konkretes Beispiel: Durch die Kombination von CSRF und XSS kann ein Angreifer ein Anmeldeformular oder Benutzerprofil mit Zahlungsdaten so manipulieren, dass die Daten nicht ans eigentliche Ziel geleitet, sondern zum Angreifer versendet werden.
Computersysteme und darauf laufende Dienste können Sicherheitslücken beinhalten, die es dem Angreifer durch Ausnutzen gestatten, einen vollen Zugriff auf das System zu erhalten. Ist dieser Schritt getan, hat der Angreifer leichtes Spiel und muss anschließend eine Schadsoftware auf dem System installieren, um bei der nächsten Browserbenutzung die gewünschte Aktion auszuführen.
Dieser Angriff kann z. B. auch über das Installieren eines infizierten Browser Plugins vollzogen werden. Die Auswirkungen können dieselben sein wie in den zuvor beschriebenen Varianten.
Wir verwenden Cookies, und Google reCAPTCHA, das Google Fonts lädt und mit Google-Servern kommuniziert. Durch die weitere Nutzung unserer Website stimmen Sie der Verwendung von Cookies und unserer Datenschutzerklärung zu.