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


224

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.


7
"[Wenn] ohne AJAX angefordert wird, wird es nach Abschluss zur ursprünglichen Website zurückgeleitet. Wenn es mit AJAX angefordert wird, erfolgt keine Umleitung." -> Genau deshalb möchten Sie es tun. :)
Robert Christian

Antworten:


257

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 .


14
Ich verstehe es nicht Was hindert den Angreifer daran, eine Anfrage zu erstellen und auch einen X-Requested-WithHeader hinzuzufügen ?
Greg

13
@ Greg: Der Browser - er lässt es nicht domänenübergreifend zu.
SilverlightFox

2
Oh, ich wusste nicht, dass keine CORS-Konfiguration benötigt wird, solange Sie sich in derselben Domain befinden. Es ist jedoch offensichtlich, wenn Sie darüber nachdenken. Vielen Dank !
Greg

10
@ vol7ron: Nichts hält sie davon ab, aber dann haben sie die Cookies ihres Opfers nicht in der Anfrage, was das Objekt der Anfrage besiegt. Damit ein CSRF erfolgreich ist, muss der Browser automatisch Cookies an die Anforderung anhängen. Ohne den Browser gibt es also keinen CSRF-Angriff.
SilverlightFox

3
@ vol7ron: Ersteres. CSRF ist ein verwirrtes stellvertretendes Problem. Der Browser ist der verwirrte Stellvertreter und wird "dazu gebracht", Cookies für eine Anfrage zu senden, die der Benutzer nicht selbst gestellt hat.
SilverlightFox

25

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.


30
Wow, das klingt nach einem schrecklichen Wartungsalptraum. Wenn Sie eine andere Darstellung derselben Seite zurückgeben möchten, sollten Sie dem AcceptHeader einen anderen Inhaltstyp bereitstellen . Die Verwendung eines benutzerdefinierten Headers hierfür klingt nach einem falschen Weg.
Gili

10

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

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.