Attack Afternoon – CSRF Gegenmaßnahmen #2

Im ersten Post dieser Serie haben wir einen der wichtigsten Angriffe auf Webanwendungen vorgestellt: „Cross-Site Request Forgery“ (CSRF).

Kurz zur Wiederholung: Identifiziert eine Webanwendung einen Nutzer über Session-Cookies, schickt der Browser diese stets automatisch mit, sofern der Nutzer gerade angemeldet ist. Ein Angreifer kann nun z.B. auf einer manipulierten Seite, die der Nutzer besucht, HTTP-Requests an diese Webanwendung schicken. Ist diese für CSRF anfällig, achtet sie nur auf das vom Browser mitgeschickte, gültige Session-Cookie des Nutzers und führt die vom Angreifer gewünschte Funktionalität im Namen des Nutzers aus, ohne dass letzterer davon etwas mitbekommt. CSRF ist also ein Problem, das beim Session-Management via Cookies immer existiert und entsprechend gelöst werden muss.

Zum Schutz vor CSRF-Angriffen gibt es viele Lösungsansätze. Zum Beispiel Zufallswerte die vom Server generiert werden und im Formular als versteckter Parameter eingebaut werden. Nach dem Abschicken des Formulars überprüft der Webserver den Request auf den versteckten Parameter und akzeptiert den Request nur, wenn dieser den korrekten Parameter enthält. Diese Maßnahme haben wir bereits im letzten Post  „Attack Afternoon – CSRF Gegenmaßnahmen #1“ vorgestellt. Der Nachteil dieser Maßnahme ist, dass der Server neben der Session zusätzliche Daten speichern und verarbeiten muss.

Ein anderer, zustandslosen Weg zum Schutz vor CSRF, ist die Methode des Double Submit Cookie. Dabei wird bei der Anmeldung des Nutzers neben dem Session-Cookie ein kryptografisch starker Zufallswert als Anti-CSRF-Cookie im Browser des Nutzers gespeichert. Der Cookie wir automatisch mit jedem Request an den Server geschickt, bietet alleine aber noch keinen Schutz vor CSRF. Der Trick von Double Submit Cookie ist, dass der Server den Wert des Anti-CSRF-Cookies als versteckten Parameter in jedes Formular einbaut. Daher wird der Wert des Anti-CSRF-Cookies einmal als Cookie und einmal als Parameter mit jedem Request zum Server geschickt. Dieser braucht dann nur noch überprüfen, ob beide Werte identisch sind. Nur wenn dies der Fall ist, wird der Request akzeptiert.

Ein Angreifer hat keinen Zugriff auf den Wert des Cookies und kann daher keine HTTP-Requests erzeugen, die den korrekten Wert als zusätzlichen Parameter enthalten. CSRF-Angriffe sind daher nicht möglich. Mehr Informationen erhalten Sie unter: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#double-submit-cookie

Für die genaue Umsetzung des Double Submit Cookie als CSRF-Schutz gibt es verschiedene Möglichkeiten, die unter anderem von der Architektur der Anwendung abhängen. Auch hier können Fehler gemacht werden, wodurch sich der CSRF-Schutz aushebeln lässt. Details über potenzielle Angriffsmöglichkeiten gibt es hier: https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf

Weitere wirksame Gegenmaßnahmen bekommen Sie in einem unserer nächsten Attack Afternoons. 

Haben sie schon einen CSRF-Schutz und möchten diesen überprüfen lassen? Kontaktieren Sie uns gerne!