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

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

X-Requested-With: XMLHttpRequest

Warum ist das nötig? Warum sollte ein Server AJAX-Anfragen anders behandeln als normale Anfragen?

UPDATE : Ich habe gerade ein Beispiel aus dem wirklichen Leben mit diesem Header gefunden: https://core.spreedly.com/manual/payment-methods/adding-with-js . Wenn der Zahlungsprozessor ohne AJAX angefordert wird, wird er auf die ursprüngliche Website umgeleitet, sobald er fertig ist. Wenn es mit AJAX angefordert wird, erfolgt keine Umleitung.

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

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

    • Akzeptieren
    • Akzeptiere Sprache
    • Inhalt-Sprache
    • Letzte-Ereignis-ID
    • Inhaltstyp

    Alle anderen verursachen eine “Pre-Flight” -Anfrage, die in von CORS unterstützten Browsern ausgegeben wird.

    Ohne CORS ist es nicht möglich X-Requested-With einer domainübergreifenden XHR-Anfrage 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, die versucht, im Namen des Benutzers eine Anfrage mit JavaScript zu stellen. Dies überprüft auch, dass die Anfrage nicht von einem regulären HTML-Formular POST wurde, von dem es schwieriger ist zu überprüfen, dass es keine Domäne ohne die Verwendung von Tokens ist. (Das Überprüfen des Origin Headers kann jedoch in unterstützten Browsern eine Option sein, auch wenn alte Browser anfällig bleiben.)

    Neuer Flash-Bypass entdeckt

    Möglicherweise möchten Sie dies mit einem Token kombinieren , da Flash, das auf Safari unter OSX ausgeführt wird , diesen Header festlegen kann, wenn es einen Umleitungsschritt gibt . Es scheint, dass es auch in Chrome funktioniert hat , aber nun behoben wurde. Weitere Details finden Sie hier, einschließlich der betroffenen Versionen.

    OWASP empfehlen, dies mit einer Origin- und Referer-Prüfung zu kombinieren :

    Diese Verteidigungstechnik wird speziell in Abschnitt 4.3 von “Robuste Verteidigung für Cross-Site Request Forgery” diskutiert. Die Umgehungen dieser Verteidigung mit Flash wurden jedoch bereits 2008 und erst 2015 von Mathias Karlsson dokumentiert, um einen CSRF-Fehler in Vimeo auszunutzen. Wir sind jedoch der Meinung, dass die Flash-Attacke die Origin- oder Referer-Header nicht fälschen kann. Daher ist diese Kombination von Überprüfungen dafür verantwortlich, dass Flash CSRF-Angriffe nicht umgehen kann. (Hinweis: Wenn jemand diese Überzeugung bestätigen oder widerlegen kann, lassen Sie es uns bitte wissen, damit wir diesen Artikel aktualisieren können)

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

    Aktualisieren

    Einen ausführlicheren Blogeintrag zu CORS, CSRF und X-Requested-With hier geschrieben .

    Stellen Sie sicher, dass Sie die SilverlightFox-Antwort gelesen haben. Es hebt einen wichtigeren Grund hervor.

    Der Grund ist meistens, dass Sie, wenn Sie die Quelle einer Anfrage kennen, diese etwas 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 www.example.com/recipe/apple_pie

    Jetzt werden normalerweise eine ganze Seite, Kopfzeile, Fußzeile, Rezept-Inhalt und Anzeigen zurückgegeben. Aber wenn jemand Ihre Website durchsucht, sind einige dieser Teile bereits geladen. Sie können also ein AJAX verwenden, um das Rezept zu erhalten, das der Benutzer ausgewählt hat, aber um Zeit und Bandbreite zu sparen, werden die Kopf- / Fußzeile / Anzeigen nicht geladen.

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

    Aber es ist 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 reactjs reaktionsfähiger.

    Die Frameworks fügen nur den Header hinzu, weil es für manche nützlich sein kann, zu verfolgen, welche Anfragen AJAX sind und welche nicht. Aber es ist völlig abhängig von dem Entwickler, solche Techniken zu verwenden.

    Es ähnelt dem Accept-Language Header. Ein Browser kann eine Website anfordern, bitte zeigen Sie mir eine russische Version dieser Website, ohne dass Sie / ru / o.ä. in die URL einfügen müssen.

    Einige Frameworks verwenden diesen Header, um xhr-Anfragen zu erkennen, zB Grails Spring Security verwendet diesen Header, um eine xhr-Anfrage zu identifizieren und entweder eine json-Antwort oder eine HTML-Antwort als Antwort zu geben.

    Die meisten Ajax-Bibliotheken (Prototype, JQuery und Dojo ab v2.1) enthalten einen X-Requested-With-Header, der angibt, dass die Anfrage von XMLHttpRequest gestellt wurde, anstatt durch Klicken auf einen normalen Hyperlink oder Formular-Senden-Button ausgetriggers zu werden.

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