Ich versuche, das ganze Problem mit CSRF und geeigneten Möglichkeiten zu verstehen, um es zu verhindern. (Ressourcen, mit denen ich gelesen, verstanden und einverstanden bin:OWASP CSRF Prevention Spickzettel, Fragen zu CSRF.)

Soweit ich weiß, beruht die Sicherheitsanfälligkeit in Bezug auf CSRF auf der Annahme, dass (aus Sicht des Webservers) ein gültiges Sitzungscookie in einer eingehenden HTTP-Anfrage die Wünsche eines authentifizierten Benutzers widerspiegelt. Aber alle Cookies für die Ursprungsdomäne werden vom Browser auf magische Weise an die Anforderung angehängt, sodass der Server aus dem Vorhandensein eines gültigen Sitzungscookies in einer Anforderung nur schließen kann, dass die Anforderung von einem Browser stammt, der eine authentifizierte Sitzung hat. es kann nichts weiter von dem annehmenCode Laufen in diesem Browser, oder ob es wirklich Benutzerwünsche widerspiegelt. Die Möglichkeit, dies zu verhindern, besteht darin, zusätzliche Authentifizierungsinformationen (das "CSRF-Token") in die Anforderung aufzunehmen, die auf andere Weise als durch die automatische Cookie-Verarbeitung des Browsers übermittelt werden. Vereinfacht ausgedrückt authentifiziert das Sitzungscookie den Benutzer / Browser und das CSRF-Token den im Browser ausgeführten Code.

Kurz gesagt, wenn Sie ein Sitzungscookie verwenden, um Benutzer Ihrer Webanwendung zu authentifizieren, sollten Sie jeder Antwort auch ein CSRF-Token hinzufügen und in jeder (mutierenden) Anforderung ein entsprechendes CSRF-Token anfordern. Das CSRF-Token führt dann einen Roundtrip von Server zu Browser zurück zu Server durch, um dem Server zu beweisen, dass die Seite, die die Anforderung erstellt, von diesem Server genehmigt (selbst generiert) wurde.

Weiter zu meiner Frage, welche Transportmethode für dieses CSRF-Token auf dieser Rundreise verwendet wird.

Es scheint üblich zu sein (z. B. inAngularJS, Django, Schienen), um das CSRF-Token als Cookie (dh in einem Set-Cookie-Header) vom Server an den Client zu senden. Lassen Sie dann Javascript im Client das Token aus dem Cookie entfernen und als separaten XSRF-TOKEN-Header anhängen, an den es zurückgesendet werden soll der Server.

(Eine alternative Methode wird z.B.ausdrückenwobei das vom Server erzeugte CSRF-Token über eine serverseitige Vorlagenerweiterung im Antworttext enthalten ist und direkt an den Code / das Markup angehängt wird, der / das es an den Server zurückliefert, z. als versteckte Formulareingabe. Dieses Beispiel ist eine mehr web-1.0-artige Vorgehensweise, würde sich aber für einen JS-lastigeren Client gut verallgemeinern.)

Warum ist es so üblich, Set-Cookie als Downstream-Transport für das CSRF-Token zu verwenden / warum ist dies eine gute Idee? Ich stelle mir vor, die Autoren all dieser Frameworks haben ihre Optionen sorgfältig geprüft und nichts falsch gemacht. Auf den ersten Blick scheint es unsinnig zu sein, Cookies zu verwenden, um das zu umgehen, was im Wesentlichen eine Designbeschränkung für Cookies darstellt. Wenn Sie Cookies als Roundtrip-Transport verwenden (Set-Cookie: Header Downstream für den Server, um dem Browser das CSRF-Token mitzuteilen, und Cookie: Header Upstream für den Browser, um es an den Server zurückzugeben), würden Sie die Sicherheitsanfälligkeit erneut einführen versuchen zu beheben.

Mir ist klar, dass die oben genannten Frameworks keine Cookies für den gesamten Roundtrip für das CSRF-Token verwenden. Sie verwenden Set-Cookie im Downstream, dann etwas anderes (z. B. einen X-CSRF-Token-Header) im Upstream, und dies schließt die Sicherheitsanfälligkeit aus. Aber selbst die Verwendung von Set-Cookie als nachgelagerter Transport ist möglicherweise irreführend und gefährlich. Der Browser hängt nun das CSRF-Token an jede Anfrage an, einschließlich der wirklich böswilligen XSRF-Anfragen. im besten Fall wird die Anfrage dadurch größer als nötig, und im schlimmsten Fall könnte ein wohlmeinender, aber fehlgeleiteter Teil des Servercodes tatsächlich versuchen, ihn zu verwenden, was sehr schlecht wäre. Da der eigentliche Empfänger des CSRF-Tokens clientseitiges JavaScript ist, kann dieses Cookie nicht nur mit http geschützt werden. Das Senden des CSRF-Tokens in einem Set-Cookie-Header scheint mir daher ziemlich suboptimal zu sein.