OWASP Top Ten: A8 – Cross-Site-Request-Forgery

In diesem Beitrag aus unserer OWASP Top Ten Reihe, welche die 10 größten Sicherheitsrisiken für Webapplikationen sowie entsprechende Gegenmaßnahmen näher erläutert, geht es um sogenannte Cross-Site-Request-Forgery-Angriffe (kurz CSRF).

Ein Cross-Site-Request-Forgery (zu deutsch seitenübergreifende Aufrufmanipulation) führt eine – meist sicherheitskritische – Funktion einer Webanwendung im Kontext eines gerade angemeldeten Nutzers aus. Sofern wir CSRF-Schwachstellen im Rahmen eines Penetrationstests feststellen, wird häufig argumentiert, dass es sich um einen normalen Funktionsaufruf handelt und die Webapplikation korrekt funktioniert. Der Knackpunkt ist dabei allerdings, dass die aufgerufene Funktion auch dann verarbeitet wird, wenn der Nutzer dies eigentlich nicht beabsichtigt, beispielsweise durch den Aufruf eines präparierten Links innerhalb einer Phishing-Mail oder durch im Vorfeld eingeschleusten Schadcode (z.B. mittels Cross-Site-Scripting-Angriffen). Anfällig sind dabei sowohl GET- als auch POST-Funktionen.

Beispielszenarien:

• Ein Benutzer meldet sich auf meinebank.com an, um seinen Kontostand abzufragen. Kurze Zeit später klickt der Nutzer auf einen manipulierten Link in einer Mail, die 5.000€ Sofortgewinn verspricht. Der Link führt jedoch nicht zum versprochenen Gewinn, sondern öffnet die folgende URL:
  https:// www.meinebank.com/sende_geld.php?menge=100€&account=8562342
  Da die zuvor gestartete Online-Banking-Sitzung bzw. der dazugehörige Session-Cookie noch gültig ist, hat der Benutzer kein Geld gewonnen, sondern sendet 100€ an die Kontonummer (8562342) des Angreifers.
• Der Administrator von verysercure.com surft auf www.notsosecure.com und wird dort zum Opfer einer XSS-Attacke. Dadurch führt der Browser des Admins den folgenden Schadcode aus:
  <script>document.write(“<img src=http://www.verysercure.com/neuerAdmin?name=mr_evil&pw=moreevil>”)</script>
  Zur Folge legt der Administrator, ohne es zu wollen, einen neuen administrativen Zugang auf www.verysercure.com für den Ersteller der XSS-Attacke (Mr_Evil) an.

Gegenmaßnahmen

Um CSRF-Angriffen sinnvoll entgegenzuwirken, sollte jede sensible Funktion zusätzlich einen sogenannten Page-Token validieren. Dabei handelt es um einen zufällig genierten Wert, welcher dem Browser des Benutzers unmittelbar vor dem Aufruf einer Funktion mittgeteilt wird und ansonsten nur dem Webserver bzw. der Webapplikation bekannt ist. Sicherheitskritische Anfragen an den Server müssen diesen Token dann enthalten. Sofern der Token fehlt oder nicht korrekt ist, schlägt der Funktionsaufruf fehl und CSRF-Attacken werden somit verhindert.

Ein Page-Token wird am besten innerhalb von einem versteckten Formularfeld (hidden input) an den Nutzer übergeben und dann über eine POST-Anfrage mit den restlichen Parametern an die Webapplikation zurück übermittelt. Viele Frameworks bieten bereits sogenannte Anti-CSRF-Funktionen oder CSRF-Guards an, welche solch einen Token generieren. In der Regel muss dieser Schutz für jedes HTML-Formular separat aktiviert werden. Dies kann beispielsweise über eine extra CSS-Klasse oder auch mittels zusätzlichen Annotationen geschehen. Eine weitere CSRF-Gegenmaßnahme wäre z.B. eine aktive Bestätigung des Benutzers beim Aufruf einer Funktion, wie z.B. durch die Abfrage eines CAPTCHAs oder die Verwendung von TANs.

Zusammenfassung

Da bei vielen Webapplikationen die benötigten Parameter für einen Funktionsaufruf bekannt oder leicht vorherzusagen sind, ist die Durchführung eines CSRF-Angriffs in der Regel sehr leicht. Dabei initiiert ein Angreifer aus einer externen Quelle den Aufruf einer Funktion durch einen Anwender mit einer gültigen Benutzer-Session innerhalb der Zielapplikation. Das Schadenspotential hängt dabei maßgeblich von den Funktionen der Anwendung sowie von der Berechtigungsstufe und dem Sitzungszustand (angemeldet/nicht angemeldet) des betroffenen Benutzers ab. Die wirkungsvollste Methode gegen CSRFs ist die Implementierung eines Page-Tokens über ein Hidden-Input-Feld.