it-swarm.com.de

Werden Samesite-Cookies einen ausreichenden Schutz gegen CSRF und XSS bieten?

Ich muss sagen, dass mir diese Idee gefällt und es scheint, dass sie eine neue Form des Schutzes gegen CSRF und XSS bringen oder zumindest diese Angriffe reduzieren wird.

Wie effektiv wird dieser Schutz sein?

SameSite-Cookies ist ein Mechanismus zum Definieren, wie Cookies über Domains gesendet werden sollen. Dies ist ein von Google entwickelter Sicherheitsmechanismus, der derzeit in Chrome-dev (51.0.2704.4) vorhanden ist. Der Zweck von SameSite-Cookies besteht darin, CSRF- und XSSI-Angriffe zu verhindern. Den Entwurf können Sie hier lesen. (Quelle)

21
Mirsad

Zunächst eine Definition von Chrome :

Mit Cookies auf derselben Website (geb. "Nur Erstanbieter" (geb. "Erstanbieter")) können Server das Risiko von CSRF- und Informationsleckangriffen verringern, indem sie behaupten, dass ein bestimmtes Cookie nur mit von demselben initiierten Anforderungen gesendet werden sollte registrierbare Domain.

Wovor schützt das also?

CSRF?

Cookies auf derselben Website können CSRF-Angriffe wirksam verhindern. Warum?

Wenn Sie das Sitzungscookie als dieselbe Site festlegen, wird es nur gesendet, wenn eine Anforderung von Ihrer Site stammt. Ein Standard-CSRF-Angriff, bei dem der Angreifer das Opfer auf die Website lockt http://malicious.com, das eine Anfrage an http://bank.com/transfer.php?amount=10000&receiver=evil_hacker wird nicht funktionieren. Schon seit malicious.com ist nicht derselbe Ursprung wie bank.com, der Browser sendet das Sitzungscookie nicht und transfer.php wird ausgeführt, als ob das Opfer nicht angemeldet wäre.

Dies ist sehr ähnlich zu der Einstellung eines X-Csrf-Token HTTP-Header schützt Sie vor CSRF - wieder gibt es etwas, das nur gesendet wird, wenn die Anfrage von Ihrer Domain stammt. Die Eigenschaft derselben Site verwandelt Ihr Sitzungscookie in ein CSRF-Token.

Also Problem gelöst? Naja, so ungefähr. Es gibt einige Einschränkungen:

  • Dies funktioniert nur für Browser, die diese Funktion implementieren. Bisher tun es nur sehr wenige. Wenn Sie nicht jeden, der einen etwas älteren Browser verwendet, unter den Bus werfen möchten, müssen Sie dennoch ein altmodisches CSRF-Token implementieren.
  • Wenn Sie eine feinkörnigere Kontrolle benötigen, reicht dies nicht aus. Wenn Sie ein System ausführen, das nicht vertrauenswürdige Benutzerinhalte anzeigt, z. B. ein Forum, möchten Sie nicht, dass Anforderungen, die von Benutzerbeiträgen stammen, als gültig behandelt werden. Wenn jemand einen Link zu http://myforum.com/?action=delete_everything Sie möchten nicht, dass etwas gelöscht wird, nur weil ein Benutzer darauf klickt. Mit einem herkömmlichen CSRF-Token können Sie genau steuern, wann es verwendet wird. Mit einem Cookie auf derselben Site können Sie dies nicht tun.
  • Es gelten immer noch die gleichen alten Vorbehalte wie für altmodische CSRF-Schutzmaßnahmen. Wenn Sie eine XSS-Sicherheitsanfälligkeit haben, wird Sie kein CSRF-Schutz in dieser Welt retten.

Trotzdem ist das Cookie auf derselben Site immer noch eine gute Sache, die als Tiefenverteidigung verwendet werden sollte zusammen mit traditionellen Verteidigungen.

XSS und XSSI?

Das Cookie auf derselben Site schützt Sie nicht vor normalen XSS-Angriffen. Wenn es einem Hacker gelingt, Ihre Site zu täuschen, um das Skript von der URL auf Ihrer Site wiederzugeben, wird es so ausgeführt, als stamme es von Ihrem Ursprung (schließlich ist es das), und daher werden Sitzungscookies weiterhin mit allen Anforderungen des injizierten Skripts gesendet macht zu Ihrer Domain.

Wenn Sie das Zitat in Ihrem Beitrag sorgfältig lesen, wird XSSI mit einem I am Ende und nicht XSS angezeigt. Das I steht für Inklusion, und XSSI ist mit XSS verwandt, unterscheidet sich jedoch von diesem. hier ist eine gute Erklärung für XSSI und wie es sich von XSS unterscheidet:

XSSI ist eine Form von XSS, die die Tatsache ausnutzt, dass Browser nicht verhindern, dass Webseiten Ressourcen wie Bilder und Skripte enthalten, die auf anderen Domänen und Servern gehostet werden. [...] Wenn die Website von Bank ABC beispielsweise über ein Skript verfügt, das die privaten Kontoinformationen eines Benutzers liest, kann ein Hacker dieses Skript in seine eigene schädliche Website (www.fraudulentbank.com) aufnehmen, um Informationen von den Servern der Bank ABC abzurufen, wann immer a Der Kunde der Bank ABC besucht die Website des Hackers.

Cookies auf derselben Site schützen Sie vor XSSI, da ein Sitzungscookie nicht mit der Anforderung des Skripts gesendet wird und daher keine vertraulichen Informationen zurückgibt. Für gewöhnliches XSS macht dies jedoch keinen Unterschied.

28
Anders

Dies hängt davon ab, welche Browser Sie unterstützen möchten und wie Ihre Website derzeit eingerichtet ist.

Wenn Sie ausschließlich Browser unterstützen, die diese Funktion unterstützen, sollte dies ausreichen, wenn Sie dazu bereit sind:

  • Senden Sie keine Cookies mit Navigation auf oberster Ebene (dies ist recht restriktiv, da Sie keine externen Links zu angemeldeten Seiten erstellen können).
  • Stellen Sie sicher, dass keine Operationen GET (oder eine beliebige sichere Methode) verwenden, um eine Operation auszuführen. Andernfalls öffnen Sie sich für Verknüpfungsangriffe wie in die vorherige Antwort

Wenn Sie ohne Navigation auf oberster Ebene zu angemeldeten Seiten von externen Websites leben können, ist SameSite: 'strict' möglicherweise geeignet. Mit dieser Option wird das angegebene Cookie nicht mit einer Anfrage gesendet, die über den Ursprung hinweg erfolgt (---) einschließlich Klick-Links usw.).

Wenn Sie von externen Websites aus auf angemeldete Seiten verlinken müssen, müssen Sie sicherstellen, dass keine beobachtbaren Änderungen von einem GET (oder einem beliebigen Safe) auftreten Methode) an den Server und sollte stattdessen SameSite: 'lax' verwenden. Wenn Sie diese Einschränkung sicherstellen können, sollten auch vom Benutzer übermittelte Links sicher sein (ohnehin vor CRSF-Angriffen).

Es ist wahrscheinlich nicht trivial, sicherzustellen, dass eine dieser Einschränkungen in einer vorhandenen Codebasis (zusätzlich zu den modernen Browseranforderungen) nicht trivial ist. Daher würde ich nicht empfehlen, CSRF-Token zu entfernen, wenn Sie sie bereits verwenden, da viele Orte immer noch GET zum Auslösen von Operationen.

Wenn Sie ein neues Projekt starten und keine Browser unterstützen möchten, die diese Funktion nicht unterstützen, sollten Sie dies in Betracht ziehen, da es sich im Grunde nur um eine einzelne Codezeile handelt. Stellen Sie nur sicher, dass Sie beide 'lax' kennen und 'strict' Modi und welche Einschränkungen Sie bei beiden beachten müssen.


In Bezug auf SameSite: 'strict': Wenn Sie SameSite: 'strict' verwenden und ein Benutzer auf einen externen Link in einen eingeschränkten Teil der Site klickt, wird möglicherweise ein Begrüßungsbildschirm angezeigt, in dem er gefragt wird, ob er fortfahren möchte. Ich würde dies wärmstens empfehlen, wenn die Ressourcen nicht extern verknüpft werden sollen. In diesem Fall ist eine Verknüpfung wahrscheinlich ein Angriff/Trick.

Wenn der Benutzer über einen solchen Begrüßungsbildschirm verfügt, muss er sich dennoch nicht erneut anmelden, da durch Klicken auf "Weiter" auf Ihrer Website SameSite - Cookies gesendet werden, da es sich tatsächlich um denselben Ursprung handelt.

Wenn die Umleitung automatisch erfolgen soll, können Sie auch einfach einen Refresh: 0 -Header für Seiten hinzufügen, von denen Sie wissen, dass sie sicher sind (dies ist auch eine gute Gelegenheit, um zu überprüfen, ob eine bestimmte Seite tatsächlich ist sicher, extern verbunden zu sein, wenn nicht auf den oben genannten Begrüßungsbildschirm zurückgegriffen wird). Der Hauptnachteil dieses vs SameSite: 'lax' ist, dass Sie die Navigation zweimal wiederholen.

4
Jamesernator