Warum erlauben Browser CSRF?

Question

Ich bin ziemlich neu in der Web-Sicherheit, und als ich mehr über die verschiedenen Angriffsvektoren lese, schreckt meine Meinung, dass sie in erster Linie erlaubt sind. Es ist so, als ob das Internet mit einem kaputten Sicherheitsmodell entworfen wurde und anfällig wäre.

Ich bin auch erstaunt über die Menge an vagen und ungenauen Informationen. Zum Beispiel klingt die Single Origin Policy zunächst ziemlich gut, dann habe ich gelesen, dass sie nur für XHR gilt und achtet übrigens nicht auf XHR-Ursprungs-POST, das ist der klassische CSRF-Angriff. Ich bin froh, dass ich weiter gelesen habe.

Es gibt auch einen Origin-Header, den der Server verwenden kann, um sicherzustellen, dass die Anfrage von der richtigen Stelle kommt - aber oops, ist es in den Browsern inkonsistent eingestellt, und wenn es nicht festgelegt ist, können Sie nicht sein ganz sicher, ob es wegen einer Anfrage mit demselben Ursprung oder einem Anforderungstyp war, der es nur für bestimmte Browser nicht bekommen hat (vielleicht ein IMG-Tag?). Weiter lesen.

So die richtig Weg scheint ein CSRF-Token in der Session-Cookie gesetzt werden, und auch das Token zu Formen/Links hinzufügen, und vergleichen Sie sie dann Server-Seite auf eine Vorlage. In der Theorie (und lassen Sie alle XSS-Angriffe für den Zweck dieser Frage ausschließen), kann ein CSRF-Versuch von einem anderen Tab eine POST-Anfrage an ein Formular machen, das den Cookie enthält, aber ohne ein Formulareingabeelement, das auf das passende Token gesetzt ist kann das Token nicht aus dem Cookie lesen), so dass der Server die Anfrage ablehnt. Funktioniert aber kludgy, und vergessen Sie nie, zu überprüfen!

Halten Sie diese Gedanken im Kopf für ein zweiten, hier ist meine Frage - warum der Browser des Session-Cookie in einer Anforderung senden, die von einer Seite stammt, die nicht der Ursprung des Cookie?

ich meine, Browser Cookies ablehnen - verschiedenen Domains aus gutem Grund zu senden, aber sind sehr glücklich, sie von unterschiedlicher Herkunft zu schicken? Würden die Sachen kaputt gehen, wenn sie es nicht würden? Wäre es eine robuste Verteidigung gegen CSRF, da Server nur das tun müssten, was sie gerade tun - nach einem gültigen Session-Cookie suchen?

Edit: Vielleicht ist dies ein Versuch, die Situation zu verbessern? https://tools.ietf.org/html/draft-west-origin-cookies-01

Answer 1

Ich bin ziemlich neu in Web-Sicherheit, und als ich mehr über die verschiedenen Angriffsvektoren lesen, mein Geist verwirrt, dass sie in der ersten Stelle erlaubt sind. Es ist so, als ob das Internet mit einem gebrochenen Sicherheitsmodell entworfen und verwundbar wäre.

Alle wahr. Es wurde nie entworfen, um in erster Linie sicher zu sein. Das Web wurde ursprünglich als statisches Dokumentenverwaltungs- und -freigabesystem konzipiert, das direkte Links zu Ressourcen auf verschiedenen Computern ermöglichte.

Das dynamische Web, das Sie heute sehen ist ein Kludge. Wir können es mit CSRF-Token, HTTP-Headern und ähnlichem beheben, aber wenn Sie eine dynamische Website erstellen, ohne eines dieser Dinge zu tun, dann besteht die Gefahr, dass es anfällig ist (und Leute wie mich in einem Job hält).

Auschecken its history in the Wikipedia article.

Ich bin auch erstaunt über die Menge an vagen und ungenauen Informationen.Für Beispiel zunächst die Single Origin Policy klingt ziemlich gut, dann I lesen, dass es nur für XHR gilt, und oh, und übrigens, verhindert nicht XHR Cross-Herkunft POST, das ist der klassische CSRF Attacke. Ich bin froh, dass ich weiter gelesen habe.

Auch hauptsächlich wahr. Die Same-Origin-Richtlinie gilt auch für Windows und Frames (z. B. example.com kann den Inhalt von example.org nicht durch JavaScript ändern, wenn example.com einen IFrame zu example.org enthält). Ja, domänenübergreifende XHRs können erstellt werden, aber ohne CORS aktiviert sind die Antworten nicht lesbar. Dies schützt zwar CSRF-Tokens vor Diebstahl, aber wie Sie sagen, wenn Sie CSRF-Schutz nicht verwenden, stellt dies eine CSRF-Sicherheitsanfälligkeit dar.

Andere Abwehrmechanismen wie adding a custom header können zur Verringerung von CSRF verwendet werden, da benutzerdefinierte Header nicht domänenübergreifend gesendet werden können.

XHRs war nicht in der Lage, auf irgendetwas Cross-Domain zuzugreifen, was als zu große Einschränkung angesehen wurde, daher das Aufkommen von CORS. Da Formulare ohnehin auf verschiedene Domains zugreifen konnten, wurde dies bisher nicht als besonders riskantes Manöver angesehen. Es ist immer noch nicht, sofern die entsprechenden Kontrollen eingerichtet werden.

Es gibt auch ein Origin-Header, der Server sicher vornehmen können die Anforderung von der richtigen Stelle kommt - aber oops, ist es inkonsequent in allen Browsern eingestellt, und wenn es nicht gesetzt ist, können Sie kann nicht ganz sicher sein, wenn es wegen einer gleichen Herkunft Anfrage war, oder eine Anfrage Typ, die es nur nicht für bestimmte Browser (vielleicht ein IMG-Tag?). Lesen Sie weiter.

Ganz richtig. Siehe this answer.

warum der Browser des Session-Cookie in einer Anforderung senden, dass von einer Seite stammt, die nicht der Ursprung des Cookie?

Da würden viele Dinge sonst kaputt gehen. Es gibt unzählige Formulare, die von statischen Websites an dynamische Websites gesendet werden, die die Back-End-Verarbeitung durchführen.

Es gibt eine neue standard for "same-site" cookies. Eine weniger trockene Erklärung ist here.

Grundsätzlich können Cookies mit einem neuen Attribut SameSite gesetzt werden. Im Modus strict werden Cookies nicht gesendet, wenn der Ursprung anders ist. Im lax Modus werden sie nur dann zurückgehalten, wenn das Verfahren z.B. POST, wo CSRF-Schwachstellen hauptsächlich liegen.

Das, mit dem Sie verbunden sind, war ein früher Entwurf davon.