Cross-Site Request Forgery
Anzeige Hier werben
Verwandte Angriffe:
Kurze Beschreibung:
Bei der Art des Angriffs wird eine HTTP-Anfrage gesendet oder eine URL aufgerufen, soweit der Nutzer die Seite mit dem Schadcode öffnet. Der Code wird dabei so eingebettet, dass es gar keine weiteren Aktionen seitens des Nutzers erforderlich sind.
Folgen:
Durch die HTTP-Anfragen, die ohne des Wissens des Nutzers abgeschickt werden, können die Daten verändert oder gelöscht werden.
Funktionsweise:
Das Prinzip der Attacke ist Einbettung des Schadcodes in die Seite oder E-Mail, so dass dieser vom Browser interpretiert und ausgeführt wird.
Der Nutzer muss lediglich die infizierte Seite bzw. E-Mail öffnen und schon ist es passiert - die Anfrage mit den erwähnten Folgen wird gesendet.
Ein typischer und bei Angreifern sehr beliebter Weg, um die Attacke durchzuführen, ist die Benutzung der HTML Image-Tags oder JavaScript Image-Objekte. Der Angreifer bettet die HTTP-Anfrage provozierenden Code in die src-Attribute des <img>-Tags ein und der Browser versucht beim Laden der Seite auf die Inhalte zuzugreifen, um sie zu laden. Das Einzige, was für die erfolgreiche Attacke von Bedeutung ist - der Nutzer muss in der Applikation eingelogt sein.
1 2 | <img src="http://example.de/delete_user.php?id=12" />
<script src="http://example.de/delete_user.php?id=12"></script>
|
1 2 3 4 | <script>
var myImage = new Image();
myImage.src="http://example.de/delete_user.php?id=12"
</script>
|
Gegenmaßnahmen:
Es gibt verschiedene Möglichkeiten, um die Anwendung gegen CSRF zu sichern. Manche bringen weniger Schutz, manche mehr. Aber im allgemeinen wird es den Angreifern erheblich erschwert, sollten verschiedene Schutzmechanismen gleichzeitig verwendet werden.
Als erstes sollte man für die Parameterübergabe POST statt GET verwenden. Das schließt die direkte Ausnutzung der Links für die Attacke aus.
Weiterhin könnte man bei wichtigen Funktionen eine Captcha-Abfrage einsetzen. Diese nimmt zwar der Applikation ein Stück an Benutzerfreundlichkeit ab und ist nicht besonders barriererfrei, baut allerdings eine große Hürde auf, denn da weiß der Nutzer mindestens gleich, dass die Funktion aufgerufen wurde und kann die weitere Ausführung stoppen.
Und als dritte Maßnahme gegen CSRF kann man jedes Formular mit einem zufällig erzeugten und nur einmal gültigen Token versehen und diesen dann bei Anfragen serverseitig überprüfen. Dadurch wird es dem Angreifer nicht möglich, die präparierten Requests auszunutzen. Das Token darf aber nicht vorhersagbar sein.
Fazit:
Cross-Site Request Forgery ist eine weitere Attacke, mit der man viel anstellen kann. Besonders gefährlich ist sie, wenn der Nutzer Administrator Rechte besitzt. Denn in dem Fall können nicht nur die Daten vom Nutzer selbst, sondern die vieler anderen Nutzern manipuliert werden.
zurück zur Übersicht Web-Sicherheit
Diese Seite kann von jedem registrierten Benutzer bearbeitet werden. Bisher haben 3 Personen an der Seite "Cross-Site Request Forgery" mitgewirkt.
Sie haben einen Fehler entdeckt oder möchten etwas ergänzen? Dann können Sie nach der Anmeldung "Cross-Site Request Forgery" hier bearbeiten.
-
Student der Fakultät Informatik an der HS Augsburg im 5. Fachsemester
-
Computer Scientologe im 7. Semester an der HS Augsburg. Schreibt gerade an seiner Bachelorarbeit im Bereich neue Webtechnologien und arbeitet als Werksstudent bei Team23. Nebenbei betreibt er noch seinen Blog www.gironimo.org
-
David Danier arbeitet seit mehr als neun Jahren im Bereich Web Programmierung und ist unter anderem Geschäftsführer der Webagentur Team23 sowie Webmasterpro.de.
Token
Wie würde man das technisch umsetzen? Spontan würde ich sagen, man hat in der Account-Tabelle eine Spalte "Token" die den aktuell gültigen Token für einen Benutzer speichert. Führt er eine Aktion aus, wird an die URL der Token drangehängt und vor dem Ausführen der Aktion geprüft, ob der Token der URL mit dem in der DB übereinstimmt.
Würde das aber nicht Tabbed-Browsing unmöglich machen? Das wäre mMn ein KO-Kriterium für den breiten Einsatz dieser Sicherheitsmaßnahme...