Quel est le but de l’en-tête X-Requested-With?

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

X-Requested-With: XMLHttpRequest

Pourquoi est-ce 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 réel en utilisant 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 lorsqu’il est terminé. Lorsqu’elle est demandée avec AJAX, aucune redirection n’est effectuée.

Une bonne raison est la sécurité – cela peut empêcher les attaques CSRF car cet en-tête ne peut pas être ajouté au domaine inter-requêtes AJAX sans le consentement du serveur via CORS .

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

  • Acceptez
  • Accept-Language
  • Langage de contenu
  • ID dernier événement
  • Type de contenu

toute autre cause une demande de “pré-vol” dans les navigateurs compatibles CORS.

Sans CORS, il n’est pas possible d’append 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é lancée à partir du domaine d’un attaquant tentant de faire une demande au nom de l’utilisateur avec JavaScript. Cela vérifie également que la requête n’a pas été postée à partir d’un formulaire HTML standard, dont il est plus difficile de vérifier qu’elle n’est pas interdomaine sans l’utilisation de jetons. (Cependant, la vérification de l’en-tête Origin pourrait être une option dans les navigateurs pris en charge, bien que vous laissiez les anciens navigateurs vulnérables .)

Nouveau contournement de Flash découvert

Vous pouvez souhaiter combiner cela avec un jeton , car Flash s’exécutant sur Safari sous OSX peut définir cet en-tête s’il y a une étape de redirection . Il semble que cela a également fonctionné sur Chrome , mais est maintenant corrigé. Plus de détails ici, y compris les différentes versions concernées.

OWASP recommande de combiner ceci avec une vérification d’origine et de référence :

Cette technique de défense est spécifiquement décrite dans la section 4.3 des défenses robustes pour la falsification de requête intersite. Cependant, des contournements de cette défense utilisant Flash ont été documentés dès 2008 et encore récemment 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 d’origine ou de référence. En vérifiant les deux, nous pensons que cette combinaison de vérifications devrait empêcher le contournement de Flash des attaques CSRF. (NOTE: Si quelqu’un peut confirmer ou réfuter cette opinion, veuillez nous en informer afin que nous puissions mettre à jour cet article)

Cependant, pour les raisons déjà évoquées, la vérification de l’origine peut être délicate.

Mettre à jour

J’ai écrit un article de blog plus approfondi sur CORS, CSRF et X-Requested-With ici .

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

La raison en est principalement que si vous connaissez la source d’une demande, vous voudrez peut-être la personnaliser un peu.

Par exemple, disons que vous avez un site Web qui contient de nombreuses recettes. Et vous utilisez un framework jQuery personnalisé pour faire glisser des recettes dans un conteneur basé sur un lien sur lequel elles cliquent. Le lien peut être www.example.com/recipe/apple_pie

Maintenant, normalement, cela renvoie une page complète, un en-tête, un pied de page, un contenu de recette et des annonces. 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 économiser de la bande passante, ne chargez pas l’en-tête / le pied de page / les annonces.

Maintenant, vous pouvez simplement écrire un sharepoint terminaison secondaire pour les données comme www.example.com/recipe_only/apple_pie mais cela est plus difficile à gérer et à partager avec d’autres personnes.

Mais il est plus facile de détecter que c’est une requête ajax qui effectue la requête et ne renvoie ensuite qu’une partie des données. Ainsi, l’utilisateur perd moins de bande passante et le site semble plus réactif.

Les frameworks ajoutent simplement l’en-tête car certains peuvent trouver utile de garder une trace des requêtes ajax et de celles qui ne le sont pas. Mais il est entièrement dépendant du développeur d’utiliser de telles techniques.

C’est en fait un peu comme l’en Accept-Language tête Accept-Language . Un navigateur peut demander un site Web s’il vous plaît montrez-moi une version russe de ce site Web sans avoir à insérer / ru / ou similaire dans l’URL.

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 la requête xhr et donne soit une réponse json ou une réponse html comme réponse.

La plupart des bibliothèques Ajax (Prototype, JQuery et Dojo à partir de v2.1) incluent un en-tête X-Requested-With qui indique que la requête a été effectuée par XMLHttpRequest au lieu d’être déclenchée en cliquant sur un lien hypertexte ou un bouton d’envoi.

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