Das Anti-Fälschungs-Cookie-Token und das Formularfeld-Token stimmen nicht überein, wenn WebApi verwendet wird

9

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 Ссылка

    
SB2055 29.07.2017, 12:53
quelle

2 Antworten

2

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!

%Vor%

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.

    
Fabien 08.08.2017, 12:57
quelle
0

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:

%Vor%

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

kombiniert

a> die neuen Werte mit den alten.

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 ...)

%Vor%

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: ...

    
Ciro Corvino 04.08.2017 16:20
quelle