Was ist der Sinn des X-Requested-With-Headers?

JQuery und andere Frameworks fügen den folgenden Header hinzu:

X-Requested-With: XMLHttpRequest

Warum wird das benötigt? Warum sollte ein Server AJAX-Anforderungen anders behandeln als normale Anforderungen?

UPDATE : Ich habe gerade ein reales Beispiel mit diesem Header gefunden: https://core.spreedly.com/manual/payment-methods/adding-with-js . Wenn der Zahlungsprozessor ohne AJAX angefordert wird, leitet er nach Abschluss des Vorgangs zur ursprünglichen Website zurück. Wenn es mit AJAX angefordert wird, erfolgt keine Umleitung.

Ein guter Grund ist die Sicherheit - dies kann CSRF- Angriffe verhindern, da dieser Header ohne die Zustimmung des Servers über CORS nicht domänenübergreifend zur AJAX-Anfrage hinzugefügt werden kann .

Nur die folgenden Header sind domänenübergreifend zulässig:

• Akzeptieren
• Akzeptiere-Sprache
• Inhaltssprache
• Last-Event-ID
• Inhaltstyp

Alle anderen führen dazu, dass in von CORS unterstützten Browsern eine "Pre-Flight" -Anforderung ausgegeben wird.

Ohne CORS ist es nicht möglich X-Requested-With, eine domänenübergreifende XHR-Anforderung hinzuzufügen .

Wenn der Server überprüft, ob dieser Header vorhanden ist, weiß er, dass die Anforderung nicht von der Domäne eines Angreifers initiiert wurde, der versucht, eine Anforderung im Namen des Benutzers mit JavaScript zu stellen. Dadurch wird auch überprüft, ob die Anforderung nicht aus einem regulären HTML-Formular gesendet wurde. Es ist schwieriger zu überprüfen, ob sie ohne die Verwendung von Token nicht domänenübergreifend ist. (Das Überprüfen des OriginHeaders kann jedoch in unterstützten Browsern eine Option sein, obwohl alte Browser anfällig bleiben .)

Neuer Flash-Bypass entdeckt

Möglicherweise möchten Sie dies mit einem Token kombinieren , da Flash, das unter Safari unter OSX ausgeführt wird , diesen Header festlegen kann, wenn ein Umleitungsschritt vorhanden ist . Es scheint, dass es auch auf Chrome funktioniert hat , aber jetzt behoben ist. Weitere Details hier einschließlich verschiedener betroffener Versionen.

OWASP empfiehlt, dies mit einem Origin- und Referer-Check zu kombinieren :

Diese Verteidigungstechnik wird speziell in Abschnitt 4.3 von Robust Defences for Cross-Site Request Forgery erläutert. Umgehungen dieser Verteidigung mit Flash wurden jedoch bereits 2008 und erneut erst 2015 von Mathias Karlsson dokumentiert, um einen CSRF-Fehler in Vimeo auszunutzen. Wir glauben jedoch, dass der Flash-Angriff die Origin- oder Referer-Header nicht fälschen kann. Wenn Sie also beide überprüfen, glauben wir, dass diese Kombination von Überprüfungen verhindern sollte, dass Flash CSRF-Angriffe umgehen. (HINWEIS: Wenn jemand diese Überzeugung bestätigen oder widerlegen kann, teilen Sie uns dies bitte mit, damit wir diesen Artikel aktualisieren können.)

Aus den bereits diskutierten Gründen kann es jedoch schwierig sein, Origin zu überprüfen.

Aktualisieren

Habe hier einen ausführlicheren Blog-Beitrag über CORS, CSRF und X-Requested-With geschrieben .

Stellen Sie sicher, dass Sie die Antwort von SilverlightFox lesen. Es wird ein wichtigerer Grund hervorgehoben.

Der Grund ist meistens, dass Sie, wenn Sie die Quelle einer Anfrage kennen, diese möglicherweise ein wenig anpassen möchten.

Nehmen wir zum Beispiel an, Sie haben eine Website mit vielen Rezepten. Und Sie verwenden ein benutzerdefiniertes jQuery-Framework, um Rezepte basierend auf einem Link, auf den sie klicken, in einen Container zu verschieben. Der Link kann seinwww.example.com/recipe/apple_pie

Normalerweise werden jetzt eine ganze Seite, eine Kopfzeile, eine Fußzeile, ein Rezeptinhalt und Anzeigen zurückgegeben. Wenn jedoch jemand auf Ihrer Website surft, sind einige dieser Teile bereits geladen. Sie können also eine AJAX verwenden, um das vom Benutzer ausgewählte Rezept abzurufen. Um jedoch Zeit und Bandbreite zu sparen, laden Sie die Kopf- / Fußzeile / Anzeige nicht.

Jetzt können Sie einfach einen sekundären Endpunkt für die Daten schreiben, www.example.com/recipe_only/apple_pieaber das ist schwieriger zu pflegen und für andere Personen freizugeben.

Es ist jedoch einfacher zu erkennen, dass es sich um eine Ajax-Anfrage handelt, die die Anfrage stellt und dann nur einen Teil der Daten zurückgibt. Auf diese Weise verschwendet der Benutzer weniger Bandbreite und die Site reagiert schneller.

Die Frameworks fügen nur den Header hinzu, da es für einige nützlich sein kann, zu verfolgen, welche Anforderungen Ajax sind und welche nicht. Es ist jedoch völlig vom Entwickler abhängig, solche Techniken zu verwenden.

Es ist eigentlich ähnlich wie der Accept-LanguageHeader. Ein Browser kann eine Website anfordern. Bitte zeigen Sie mir eine russische Version dieser Website, ohne / ru / oder ähnliches in die URL einfügen zu müssen.

Einige Frameworks verwenden diesen Header, um xhr-Anforderungen zu erkennen, z. B. verwendet grails spring security diesen Header, um xhr-Anforderungen zu identifizieren und entweder eine json-Antwort oder eine HTML-Antwort als Antwort zu geben.

Die meisten Ajax-Bibliotheken (Prototype, JQuery und Dojo ab Version 2.1) enthalten einen X-Requested-With-Header, der angibt, dass die Anforderung von XMLHttpRequest gestellt wurde, anstatt durch Klicken auf einen regulären Hyperlink oder eine Schaltfläche zum Senden von Formularen ausgelöst zu werden.

Quelle: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html