Ich habe eine Single-Page App (Benutzer lädt eine Menge HTML / JS und macht dann AJAX-Anfragen ohne einen weiteren Aufruf an MVC - nur über WebAPI). In WebAPI habe ich Folgendes:
%Vor%Registriert in Global.asax:
%Vor% Gelegentlich sehe ich den Fehler The anti-forgery cookie token and form field token do not match
in meinen Protokollen. Wenn dies geschieht, sind sowohl tokenCookie.value
als auch tokenHeader
nicht null.
Clientseitig verwenden alle meine AJAX-Anfragen Folgendes:
%Vor%Wenn Razor das Token einmal auf meiner SPA-Seite generiert:
%Vor%Ich habe meinen Maschinenschlüssel in Web.config eingestellt.
Was könnte das verursachen?
Aktualisieren Ich habe nur Protokolle überprüft und ich sehe das manchmal auch:
Das angegebene Anti-Fälschungs-Token war für den Benutzer "" gedacht, aber der aktuelle Benutzer ist "[email protected]". vor ein paar Sekunden
Dies tritt auf, wenn ein Benutzer seine SPA-Instanz aktualisiert, während er angemeldet ist. Der SPA löscht sie dann aus irgendeinem Grund auf der Zielseite ( User.Identity.IsAuthenticated
ist wahr) - dann können sie sich nicht einloggen wegen dieses Fehlers. Erfrischend zieht sie nach drinnen zurück. Nicht sicher, was das bedeutet, aber ich dachte mehr Info kann nicht weh tun.
Anhang Ссылка
Meine Antwort wird empfehlen, nicht CSRF-Schutz basierend auf Token in AJAX-Aufrufen zu verwenden, sondern sich auf die nativen CORS-Funktionen des Webbrowsers zu verlassen.
Grundsätzlich wird bei jedem AJAX-Aufruf vom Browser zum Back-End-Server nach dem Ursprung der Domain gesucht (die Domain, von der das Skript geladen wurde). Wenn die Domänen übereinstimmen (JS-Hostingdomäne == Ziel-AJAX-Serverdomäne), werden die AJAX-Aufrufe ausgeführt, andernfalls wird null
zurückgegeben.
Wenn ein Angreifer versucht, eine bösartige AJAX-Abfrage auf seinem eigenen Server zu hosten, wird dies fehlschlagen, wenn Ihr Back-End-Server keine CORS-Richtlinie hat, die dies erlaubt (was standardmäßig der Fall ist).
Aus diesem Grund sind CSRF-Schutzmaßnahmen in AJAX-Aufrufen nutzlos , und Sie können Ihre technischen Schulden senken, indem Sie einfach nicht versuchen, damit umzugehen .
Weitere Informationen zu CORS - Mozilla Foundation
Codebeispiel - Verwenden Sie Ihren Konsoleninspektor!
Führen Sie es aus und sehen Sie sich den Sicherheitsfehler an:
Cross-Origin-Anforderung blockiert: Die Richtlinie für gleiche Origins lässt das Lesen nicht zu die Remote-Ressource bei Ссылка . (Grund: CORS-Header "Access-Control-Allow-Origin" fehlt).
Mozilla ist ziemlich klar in Bezug auf die Implementierung Cross-site XMLHttpRequest :
Moderne Browser unterstützen Cross-Site-Anfragen durch die Implementierung des Webs Zugriffskontrolle von Anwendungen (WebApps) der Arbeitsgruppe für Cross-Site Anfragen Standard.
Solange der Server so konfiguriert ist, dass Anforderungen von Ihrem Web zugelassen werden Anwendungsherkunft, XMLHttpRequest funktioniert. Ansonsten, ein INVALID_ACCESS_ERR Ausnahme wird ausgelöst.
Ich versuche, eine Antwort die gleiche zu geben, auch wenn in den Kommentaren, die wir austauschen, deins scheint es ein nicht verwandtes Szenario mit mir ..
Eine solche Art von Problem kann auf das Verhalten XMLHttpRequest.setRequestHeader()
zurückzuführen sein, da diese Funktion " kombiniert "die Werte eines Headers, der bereits im Kontext einer HTTP-Anfrage zugewiesen wurde, wie von MDN und Whatwg :
Wenn diese Methode mehrmals mit demselben Header aufgerufen wird, -Werte werden in einem einzelnen Anforderungsheader zusammengeführt.
Also, wenn wir zum Beispiel ein SPA
haben, das alle ajax POSTs
ausführt und einen gegebenen http-Header setzt, in Ihrem Fall:
Die erste ajax POST
Anfrage setzt einen klaren Header ( "X-XSRF-Token"
) und so, serverseitig, sollten Sie einen "gültigen" Header-Wert haben, mit dem Sie vergleichen können.
Wenn jedoch keine Seitenaktualisierung oder eine neue GET
-Anforderung vorhanden ist, werden alle nachfolgenden Ajax POSTs
sowie in MDN und Whatwg Dokumentation, wird eine Dirty-Zuweisung des gleichen Headers ( "X-XSRF-Token"
) vornehmen, weil sie >
Um dieses Problem zu vermeiden, könnten Sie versuchen, "X-XSRF-Token"
value zurückzusetzen (aber es gibt nicht viel Dokumentation darüber und es scheint eine nicht zuverlässige Lösung zu sein ...)
Andere Lösungen können sich auf einige clientseitige Zustandsübergabemechanismen stützen, die Sie selbst implementieren müssen, da es nicht möglich ist, Werte oder Statuszugriffe der HTTP-Anforderungsheader zu erhalten (nur Antwortheader können aufgerufen werden) / p>
Aktualisieren - Überarbeitung des folgenden Textes:
Also, wenn wir zum Beispiel ein SPA
haben, das alle ajax POSTs
ausführt, wird das XMLHttpRequest-Objekt für jeden Aufruf neu berechnet und ein bestimmter http-Header gesetzt, in unserem Fall:
...
Tags und Links asp.net-mvc asp.net-web-api asp.net antiforgerytoken csrf