Cross Site Request Forgery (CSRF)
Bei einem CSRF Angriff versucht der Angreifer das Opfer dazu zu bewegen eine unbeabsichtigte Aktion auszuführen.
Der Angriff nutzt meist eine Funktion um Datenänderungen vorzunehmen. ( Rechte eines Nutzers ändern ...).
Hierbei macht sich der Angreifer zu nutze, dass der Nutzer auf der legitimen Seite bereits eingeloggt ist und einen Session Cookie gespeichert hat. (zusätzliche macheanismen zum Validieren des User requests sind nicht vorhanden).
Wenn ein Angreifer sein Opfer nun auf eine modifizierte Seite lockt, auf der dann die Änderung der Email-Adresse via eines HTTP-Requests ausgeführt wird, kann dieser ggf. den Account der opfers übernehmen oder anders modifizieren.
Der Browser des Opfers nutzt den Session-Cookie um den nicht legitimen Request von der Angriffsseite gegenüber der legitimen Seite zu verifzieren und durchzuführen.
Typische Schritte des CSRF Angriffs:
1. Opferauthentifizierung: Das Opfer meldet sich auf einer legitimen Website an und erhält ein Sitzungscookie, das seine Sitzung authentifiziert.
2. Böswillige Anfrage: Der Angreifer erstellt eine Anfrage an die legitime Website, die eine vom Angreifer gewünschte Aktion ausführt (z. B. Geld überweisen, eine E-Mail-Adresse ändern). Diese Anfrage ist normalerweise in eine bösartige Website oder E-Mail eingebettet.
3. Ausführung: Wenn das Opfer die bösartige Website besucht oder auf den manipulierten Link klickt, während es sich noch bei der legitimen Website authentifiziert ist, fügt der Browser automatisch den Sitzungscookie in die Anfrage ein und täuscht so der legitimen Website vor, die Anfrage sei legitim.
4. Durchgeführte Aktion: Die legitime Website verarbeitet die Anfrage, da sie offenbar von einem authentifizierten Benutzer stammt.
Beispiel:
Eine legitime Webseite(A) nutzt zum Ändern der Email-Adresse folgenden POST Request.
POST /email/change HTTP/1.1
Host: legitime-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=tzuiolknhbgacdvreeqHHAJJVCeefsdfX
email=alice@normaler-user.com
der Angreifer Bob nutzt nun Seine böse Webseite (B) um Alice dazu zu bewegen folgenden code auszuführen.
<html>
<body>
<form action="https://legitime-website.com/email/change" method="POST">
<input type="hidden" name="email" value="bob@boeser-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
Besucht Alice nun mit dem Browser auf dem sie eingeloggt ist. Bobs Webseite wird der Code zur Emailänderung zu Bobs Addresse ausgeführt und mit dem Session-cookie aus Alice Browser verarbeitet.
Bob kann somit die Email-Adresse für Alices Account auf legitime-website.com ändern.
Wie wird ein CSRF Angriff It Forensisch erkannt ?
Da bei einem CSRF Angriff in jedem Fall eine böswillige Anfrage einer anderen Seite ausgeht, ist die Anfrage in der History des Browsers oder im Netzwerktraffic sichtbar. Hier ist erkennbar, dass z.B vor einem ungewollten Postrequest eine bösartige Seite besucht worden ist. Der Referral-Header kann hier Hinweise geben von wecher Webseite der bösartige Request kommt. Da es sich bei allerdings um eine valide Anfrage des Browsers handelt ist der Angriff nicht unmittelbar erkennbar.
folgende vorsorgliche Sicherheitsmaßnahmen können implementiert werden um besser vor CSRF Angriffen geschützt zu sein:
- Synchronizer-Tokens (CSRF-Tokens): Dabei wird für jede Sitzung ein eindeutiges Token generiert und in jedes Formular eingefügt, das ein Benutzer übermittelt. Der Server überprüft dann, ob das Token mit dem in der Sitzung des Benutzers gespeicherten Token übereinstimmt.
- SameSite-Cookies: Mit diesem Cookie-Attribut können Server behaupten, dass ein Cookie nicht zusammen mit Cross-Site-Anfragen gesendet werden soll, was einen gewissen Schutz vor CSRF-Angriffen bietet.
- Double-Submit-Cookies: Die Anwendung erfordert, dass ein bestimmter Cookie-Wert als Teil der Anfrage zusammen mit dem eigentlichen Cookie gesendet wird. Der Server kann dann das Vorhandensein des Cookies prüfen und sicherstellen, dass es übereinstimmt.
- Benutzerdefinierte Anforderungsheader: Anwendungen können benutzerdefinierte Header in Anforderungen erfordern (z. B. X-Requested-With). Da diese Header nicht domänenübergreifend festgelegt werden können, kann dies dazu beitragen, CSRF-Angriffe zu verhindern.
- Überprüfen des Referer-Headers: Der Referer-Header kann überprüft werden, um sicherzustellen, dass Anfragen vom gleichen Ursprung kommen. Diese Methode ist jedoch weniger zuverlässig, da einige Clients möglicherweise nicht immer den Referrer-Header senden.
