PHP-Einfach.de
  • PHP Tutorial
  • MySQL Tutorial
  • Für Fortgeschrittene
  • Webhosting
  • Forum

Cross-Site-Request-Forgery (CSRF)

10. Februar 2020
  1. Home
  2. »
  3. Für Fortgeschrittene
  4. »
  5. PHP Sicherheit
  6. »
  7. Cross-Site-Request-Forgery (CSRF)

Eine Cross-Site-Request-Forgery (abgekürzt CSRF oder XSRF) beschreibt das Unterschieben eines ungewollten Websiteaufrufs durch einen Angreifer. Dies ist stets dann problematisch, wenn dieser Aufruf eine gewisse Aktion für den Benutzer auslöst, beispielsweise wird durch den untergeschobenen Aufruf ungewollt Artikel gekauft oder das Benutzerkonto gelöscht. Somit kann ein Angreifer eure Benutzer verärgern oder gar großen monetären Schaden anrichten. Deswegen sollte jede Seite und jedes Formular welches Aktionen durchführt (beispielsweise Löschung des Accounts, Logout, Bestellung von Artikel usw.) entsprechend gegen Cross-Site-Request-Forgey geschützt werden.

Inhaltsverzeichnis

  • 1 Beispiele - Manipulierte GET-Abfragen
  • 2 Beispiele - Manipulierte POST-Abfragen
  • 3 Schutz vor CSRF

Beispiele - Manipulierte GET-Abfragen

Angenommen ihr habt eine Benutzercommunity, wie beispielsweise ein Webforum. Die Benutzer sind dort in der Lage Bilder zu verlinken die den anderen Nutzer dargestellt werden. Verlinkt nun der Angreifer im Bild zu der Adresse www.eure-seite.de/logout.php (eine Seite die den Benutzer ausloggt), so wird jeder der die Seite mit dem Bild aufruft direkt ausgeloggt. Der Grund dafür ist, dass der Browser versucht das Bild zu laden und sendet an euren Webserver den Abfrage um die Seite logout.php zu laden. Euer Webserver interpretiert dies, als möchte der User sich ausloggen und loggt diesen konform aus.

Besonders problematisch wird es, wenn man mittels Aufruf das eigene Benutzerkonto löschen kann, z.B. durch den Aufruf www.eure-seite.de/konto_loeschung.php. Dies könnte ein Angreifer wieder in ein untergeschobenes Bild packen und jeder der dieses Aufruft dessen Konto wird gelöscht. Oder alternativ sendet der Angreifer direkt diesen Link an eure Mitglieder und verspricht eine Tolle Prämie für den Klick auf den Link.

Man sollte vermeiden bei GET-Abfragen sensible Aktionen (Logout, Bestellung von Ware, Löschung des Accounts etc.) durchzuführen. Nutzt dazu Formulare die per POST übertragen werden.

Beispiele - Manipulierte POST-Abfragen

Neben GET-Methode existiert auch die POST-Methode für HTTP-Anfragen. Die POST-Methode wird dabei hauptsächlich verwendet, um Formulardaten zu übertragen, beispielsweise zur Bestellung von Artikel oder zum Ändern der eigenen Benutzerdaten. Solch einfachen Formulare bieten aber keinen ausreichenden Schutz gegen Cross-Site-Request-Forgey.

Angenommen ihr habt ein Formular mit der eure Benutzer ihr Passwort ändern kann welches als Zielseite (action-Attribut) eure-seite.de/change_password.php hat. Ein Angreifer erstellt nun eine neue Website und verspricht auf dieser Website beispielsweise ein tolles Gewinnspiel. Um an diesem Gewinnspiel teilnehmen zu können, muss der Benutzer einen Button drücken oder seine E-Mail-Adresse eintragen oder oder oder. Diesen Link verteilt der Angreifer nun gezielt an Benutzer eurer Website, beispielsweise per Facebook oder E-Mail.

Was der Benutzer aber nicht sieht, ist dass das Formular eigentlich euer Formular zum Ändern des Passworts ist. Das neue, vom Angreifer gewählte Passwort wird dabei als verstecktes Eingabefeld  im Formular hinterlegt. Sobald der Besucher bei dem Formular auf absenden drückt, werden die Daten an eure-seite.de/change_password.php übertragen. Euer Script denkt nun (sofern der Benutzer noch bei euch eingeloggt ist), dass dieser das Passwort geändert haben möchte und ändert das Passwort je nach Vorgabe des Angreifers. Der Angreifer kann sich dann später mit dem neuen Passwort einloggen und entsprechenden Schaden anrichten.

Jedes Formular welches Daten in eurer Datenbank verändert oder andere kritische Operationen ausführt sollte speziell gegen Cross-Site-Request-Forgery geschützt werden.

Schutz vor CSRF

Der Schutz gegen CSRF ist zum Glück relativ einfach. In eure Formulare und in eure Links die gewisse Aktionen auslösen (z.B. Logout-Link) müsst ihr eine geheime Information einbetten, die nur euer Server und der Browser des Benutzers kennt.

Beispielsweise generiert ihr nach dem Login einen zufälligen Wert und speichert diesen in einer Session ab:

1
2
3
<?php
//Nachdem sich der Benutzer eingeloggt hat
$_SESSION['csrf_token'] = uniqid('', true);

Jedes zu schützende Formular sowie jeder zu schützende Link wird nun dieser CSRF-Token übergeben. Aus dem Logout-Link wird entsprechend logout.php?csrf=$_SESSION['csrf_token'].

Ein zu schützendes Formular wird um ein hidden-Field erweitert, indem der Wert hinterlegt ist:

1
<input type="hidden" name="csrf" value="'.$_SESSION['csrf_token'].'">

Auf der Empfängerseite, also in eurem Logout-Script, in den Code-Stellen die eure Formulare etc. verarbeiten, könnt ihr überprüfen ob der übermittelte Wert dem abgespeicherten Wert in der Session entspricht:

1
2
3
4
5
6
7
8
9
10
11
12
<?php
//Bei GET-Aufrufen
if($_GET['csrf'] !== $_SESSION['csrf_token']) {
  die("Ungültiger Token");
}
 
//Bei Formularabfragen
if($_POST['csrf'] !== $_SESSION['csrf_token']) {
  die("Ungültiger Token");
}
 
//Weitere Aktionen, Logout, Änderung des Passworts etc.

Das Unterschieben von Links oder Formularen wird dadurch verhindert. Sofern ihr diesen Schutz also überall konsequent implementiert habt, ist eure Webanwendung recht sicher gegen Cross-Site-Request-Forgery.

Autor: Nils Reimers
Zurück: Sicherer Dateiupload
Weiter: Cross-Site-Scripting (XSS) in PHP

Für Fortgeschrittene

  • Objektorientierte Programmierung
  • PHP Sicherheit
    • Authentifizierung in PHP
    • Code Injection
    • Cross-Site-Request-Forgery (CSRF)
    • Cross-Site-Scripting (XSS) in PHP
    • Daten sicher speichern
    • Daten validieren
    • Penetrationtesting für PHP
    • SQL-Injections
  • Script-Beispiele
  • Codeschnipsel
  • Stellenmarkt
Mit freundlicher Unterstützung von:
  • Punkt191 Werbeagentur
  • DGUV V3
  • DGUV 3
  • CasinoAndy Finland
  • Casinopilot24.com
  • Neueonline-Casinos.com
  • CasinoHEX.at
  • Decasinos.de
  • Privatkredit247.com
  • Online Casino Spielautomaten
  • Casinofrog.com
  • parhaatuudetkasinot.com

Hoster – Geringste Ausfallzeit

  1. webgo Ø 0 Min.
  2. Linevast Ø 3 Min.
  3. netcup Ø 3 Min.
  4. dogado Ø 6 Min.
  5. Mittwald Ø 9 Min.
  6. All-Inkl.com Ø 10 Min.
  7. manitu Ø 10 Min.
  8. bplaced Ø 11 Min.
  9. checkdomain Ø 11 Min.
  10. Host Europe Ø 14 Min.
» Mehr erfahren

Impressum | Datenschutz | Auf PHP-Einfach.de werben

© PHP-Einfach.de 2003 - 2022

Um dich beim Lernen von PHP und MySQL zu unterstützen verwenden wir Cookies. OK Weitere Infos
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Notwendige
immer aktiv

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Nicht notwendige

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.