Wie können Same-Site-Cookies verwendet werden, um CSRF-Angriffe einzudämmen?
Same-Site-Cookies sind ein wichtiger Sicherheitsmechanismus, der zur Abwehr von Cross-Site Request Forgery (CSRF)-Angriffen in Webanwendungen eingesetzt werden kann. CSRF-Angriffe treten auf, wenn ein Angreifer ein Opfer dazu verleitet, eine unbeabsichtigte Aktion auf einer Website auszuführen, auf der das Opfer authentifiziert ist. Durch die Ausnutzung der Sitzung des Opfers kann der Angreifer ohne dessen Zustimmung Aktionen im Namen des Opfers durchführen.
Same-Site-Cookies tragen dazu bei, CSRF-Angriffe zu verhindern, indem sie den Umfang der Cookies auf denselben Ursprung beschränken. Ein Ursprung wird durch die Kombination aus Protokoll (z. B. HTTP oder HTTPS), Domäne und Portnummer definiert. Wenn ein Cookie mit dem Attribut „SameSite“ gesetzt wird, gibt es an, ob das Cookie in standortübergreifenden Anfragen gesendet werden soll.
Für das Attribut „SameSite“ gibt es drei mögliche Werte:
1. „Streng“: Wenn das Attribut „SameSite“ auf „Streng“ gesetzt ist, wird das Cookie nur bei Anfragen gesendet, die von derselben Site stammen. Dies bedeutet, dass das Cookie nicht bei Cross-Site-Anfragen gesendet wird, wodurch CSRF-Angriffe effektiv verhindert werden. Wenn sich ein Benutzer beispielsweise auf „example.com“ authentifiziert und eine bösartige Website besucht, die versucht, einen CSRF-Angriff durchzuführen, schließt der Browser das „Strict“-Cookie für dieselbe Website nicht in die Anfrage ein und verhindert so den Angriff.
2. „Lax“: Wenn das Attribut „SameSite“ auf „Lax“ gesetzt ist, wird das Cookie in standortübergreifenden Anfragen gesendet, die als sicher gelten, beispielsweise wenn die Anfrage durch eine Top-Level-Navigation des Benutzers ausgelöst wird. Das Cookie wird jedoch nicht bei Anfragen gesendet, die von Websites Dritter initiiert werden, etwa wenn ein Bild oder ein Skript-Tag von einer anderen Domain geladen wird. Dies sorgt für ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit. Beispielsweise löst ein Benutzer, der über einen Link eine bösartige Website besucht, keinen CSRF-Angriff aus, da das „Lax“-Cookie für dieselbe Website nicht in der Anfrage enthalten ist.
3. „None“: Wenn das Attribut „SameSite“ auf „None“ gesetzt ist, wird das Cookie bei allen Cross-Site-Anfragen gesendet, unabhängig von deren Herkunft. Um die Sicherheit bei der Verwendung von „Keine“ zu gewährleisten, muss das Cookie jedoch auch als „Sicher“ gekennzeichnet sein, was bedeutet, dass es nur über HTTPS-Verbindungen gesendet wird. Diese Kombination ermöglicht es Webanwendungen, standortübergreifende Funktionalität zu unterstützen und gleichzeitig vor CSRF-Angriffen zu schützen. Es ist zu beachten, dass der Wert „None“ nur bei Bedarf verwendet werden sollte, da er die Angriffsfläche und das Potenzial für CSRF-Schwachstellen erhöht.
Um die Verwendung von Same-Site-Cookies zur Abwehr von CSRF-Angriffen zu veranschaulichen, stellen Sie sich das folgende Szenario vor: eine Bank-Website, die es Benutzern ermöglicht, Geld zu überweisen. Ohne Same-Site-Cookies könnte ein Angreifer eine bösartige Website erstellen, die ein verstecktes Formular enthält, das automatisch eine Überweisungsanforderung an die Bank-Website sendet, wenn ein authentifizierter Benutzer sie besucht. Sofern der Browser des Nutzers das Session-Cookie in die Anfrage einbindet, erfolgt die Übertragung ohne Einwilligung des Nutzers. Wenn Sie das Sitzungscookie jedoch als standortgleiches Cookie mit dem Attribut „Streng“ festlegen, schließt der Browser das Cookie nicht in die standortübergreifende Anforderung ein, wodurch der CSRF-Angriff effektiv verhindert wird.
Same-Site-Cookies sind ein wertvoller Sicherheitsmechanismus zur Abwehr von CSRF-Angriffen in Webanwendungen. Indem sie den Umfang der Cookies auf denselben Ursprung beschränken, verhindern diese Cookies, dass Angreifer die Sitzung eines Benutzers ausnutzen, um nicht autorisierte Aktionen durchzuführen. Der Wert „Streng“ stellt sicher, dass Cookies nur bei Anfragen gesendet werden, die von derselben Website stammen, während der Wert „Lax“ das Senden von Cookies bei sicheren standortübergreifenden Anfragen ermöglicht. Der Wert „None“ ermöglicht in Kombination mit dem Attribut „Secure“ die standortübergreifende Funktionalität und schützt gleichzeitig vor CSRF-Angriffen.
Weitere aktuelle Fragen und Antworten zu EITC/IS/WASF-Sicherheitsgrundlagen für Webanwendungen:
- Schützt die Implementierung von Do Not Track (DNT) in Webbrowsern vor Fingerprinting?
- Hilft HTTP Strict Transport Security (HSTS) beim Schutz vor Protokoll-Downgrade-Angriffen?
- Wie funktioniert der DNS-Rebinding-Angriff?
- Treten gespeicherte XSS-Angriffe auf, wenn ein schädliches Skript in eine Anforderung an eine Webanwendung eingefügt und dann an den Benutzer zurückgesendet wird?
- Wird das SSL/TLS-Protokoll verwendet, um eine verschlüsselte Verbindung in HTTPS herzustellen?
- Was sind Abrufmetadaten-Anforderungsheader und wie können sie verwendet werden, um zwischen Anforderungen desselben Ursprungs und standortübergreifenden Anforderungen zu unterscheiden?
- Wie reduzieren vertrauenswürdige Typen die Angriffsfläche von Webanwendungen und vereinfachen Sicherheitsüberprüfungen?
- Welchen Zweck hat die Standardrichtlinie bei vertrauenswürdigen Typen und wie kann sie zur Identifizierung unsicherer Zeichenfolgenzuweisungen verwendet werden?
- Wie wird ein Objekt für vertrauenswürdige Typen mithilfe der API für vertrauenswürdige Typen erstellt?
- Wie trägt die Direktive „Trusted Types“ in einer Inhaltssicherheitsrichtlinie dazu bei, Schwachstellen im DOM-basierten Cross-Site-Scripting (XSS) zu mindern?
Weitere Fragen und Antworten finden Sie unter EITC/IS/WASF Web Applications Security Fundamentals