Quel est l'intérêt de l'en-tête X-Requested-With ?

Question

JQuery et d'autres frameworks ajoutent l'en-tête suivant :

X-Requested-With : XMLHttpRequest

Pourquoi cela est-il nécessaire ? Pourquoi un serveur voudrait-il traiter les requêtes AJAX différemment des requêtes normales ?

MISE À JOUR : Je viens de trouver un exemple concret d'utilisation de cet en-tête : https://core.spreedly.com/manual/payment-methods/adding-with-js . Si le processeur de paiement est demandé sans AJAX, il est redirigé vers le site web d'origine lorsque l'opération est terminée. Lorsqu'il est demandé avec AJAX, aucune redirection n'est effectuée.

Answer 1

Une bonne raison est la sécurité, qui permet d'éviter CSRF car cet en-tête ne peut être ajouté au domaine croisé de la requête AJAX sans l'accord du serveur par l'intermédiaire de CORS .

Seuls les en-têtes suivants sont autorisés entre les origines :

• Accepter
• Acceptation de la langue
• Langue du contenu
• Dernier identifiant d'événement
• Content-Type

les autres entraînent l'émission d'une demande "pré-vol" dans les navigateurs supportant CORS.

Sans CORS, il n'est pas possible d'ajouter X-Requested-With à une requête XHR interdomaine.

Si le serveur vérifie la présence de cet en-tête, il sait que la requête n'a pas été initiée par un domaine d'un attaquant tentant de faire une requête au nom de l'utilisateur avec JavaScript. Cela permet également de vérifier que la demande n'a pas été postée à partir d'un formulaire HTML ordinaire, dont il est plus difficile de vérifier qu'il ne s'agit pas d'un domaine croisé sans l'utilisation de jetons (cependant ), le contrôle de la Origin en-tête pourrait être une option dans les navigateurs pris en charge, bien que vous laissiez les anciens navigateurs vulnérables .)

Découverte d'un nouveau contournement de Flash

Vous pouvez souhaiter combiner avec un jeton parce que Flash fonctionnant sur Safari sous OSX peut définir cet en-tête s'il y a une étape de redirection . Il apparaît que il fonctionne aussi sur Chrome mais elle est maintenant assainie. Plus de détails ici y compris les différentes versions concernées.

L'OWASP recommande de combiner cette vérification avec une vérification de l'origine et du référent. :

Cette technique de défense est spécifiquement abordée dans la section 4.3 du document suivant Robust Defenses for Cross-Site Request Forgery (défenses robustes contre la falsification des requêtes intersites). Cependant, les contournements de cette défense en utilisant Flash ont été documentés dès 2008 et aussi récemment que aussi récemment qu'en 2015 par Mathias Karlsson pour exploiter une faille CSRF dans Vimeo. Mais nous pensons que l'attaque Flash ne peut pas usurper les en-têtes Origin ou Referer. Referer, donc en les vérifiant tous les deux, nous pensons que cette combinaison de vérifications devrait empêcher les attaques CSRF par contournement de Flash. (NOTE : Si quelqu'un peut confirmer ou infirmer cette hypothèse, merci de nous le faire savoir afin que nous puissions pour que nous puissions mettre à jour cet article)

Toutefois, pour les raisons déjà évoquées, le contrôle de l'origine peut s'avérer délicat.

Mise à jour

Rédaction d'un article de blog plus approfondi sur CORS, CSRF et X-Requested-With ici .

Answer 2

Assurez-vous de lire la réponse de SilverlightFox. Elle met en évidence une raison plus importante.

La raison en est principalement que si vous connaissez la source d'une demande, vous pouvez vouloir la personnaliser un peu.

Supposons par exemple que vous ayez un site web contenant de nombreuses recettes. Vous utilisez un framework jQuery personnalisé pour faire glisser les recettes dans un conteneur en fonction d'un lien cliqué. Le lien peut être www.example.com/recipe/apple_pie

Normalement, cela renvoie une page complète, un en-tête, un pied de page, le contenu de la recette et les publicités. Mais si quelqu'un navigue sur votre site web, certaines de ces parties sont déjà chargées. Vous pouvez donc utiliser un AJAX pour obtenir la recette sélectionnée par l'utilisateur, mais pour gagner du temps et de la bande passante, ne pas charger l'en-tête, le pied de page et les publicités.

Il suffit maintenant d'écrire un point de terminaison secondaire pour les données, comme par exemple www.example.com/recipe_only/apple_pie mais c'est plus difficile à maintenir et à partager avec d'autres personnes.

Mais il est plus facile de détecter qu'il s'agit d'une requête ajax qui fait la demande et ne renvoie qu'une partie des données. De cette manière, l'utilisateur gaspille moins de bande passante et le site semble plus réactif.

Les frameworks ajoutent simplement l'en-tête parce que certains peuvent trouver utile de garder une trace des requêtes qui sont ajax et de celles qui ne le sont pas. Mais l'utilisation de ces techniques dépend entièrement du développeur.

C'est en fait un peu la même chose que le Accept-Language en-tête. Un navigateur peut demander à un site web de me montrer une version russe de ce site sans avoir à insérer /ru/ ou un élément similaire dans l'URL.

Answer 3

Certains frameworks utilisent cet en-tête pour détecter les requêtes xhr, par exemple grails spring security utilise cet en-tête pour identifier les requêtes xhr et donner une réponse json ou html comme réponse.

La plupart des bibliothèques Ajax (Prototype, JQuery et Dojo à partir de la version 2.1) incluent un en-tête X-Requested-With qui indique que la demande a été faite par XMLHttpRequest au lieu d'être déclenchée par un clic sur un hyperlien ordinaire ou un bouton de soumission de formulaire.

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