Quel est l'intérêt 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 demandes AJAX différemment des demandes 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 redirige vers le site Web d'origine une fois terminé. Lorsqu'elle est demandée avec AJAX, aucune redirection n'est effectuée.

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

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

• J'accepte
• Accept-Language
• Langue du contenu
• ID du dernier événement
• Type de contenu

toute autre cause entraîne l'émission d'une demande de «pré-vol» dans les navigateurs pris en charge par CORS.

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

Si le serveur vérifie que cet en-tête est présent, il sait que la demande n'a pas été initiée depuis le domaine d'un attaquant tentant de faire une demande au nom de l'utilisateur avec JavaScript. Cela vérifie également que la demande n'a pas été envoyé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- Origintête peut être une option dans les navigateurs pris en charge, bien que vous laissiez les anciens navigateurs vulnérables .)

Découverte d'un nouveau contournement Flash

Vous souhaiterez peut-être combiner cela avec un jeton , car Flash exécuté sur Safari sur 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 il est maintenant corrigé. Plus de détails ici, y compris les différentes versions concernées.

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

Cette technique de défense est spécifiquement discutée dans la section 4.3 des Défenses robustes pour la contrefaçon de demande 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 Origin ou Referer, donc en les vérifiant tous les deux, nous pensons que cette combinaison de contrôles devrait empêcher les attaques CSRF de contournement Flash. (REMARQUE: si quelqu'un peut confirmer ou réfuter cette croyance, 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

A é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 principale est 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 cadre jQuery personnalisé pour faire glisser des recettes dans un conteneur en fonction d'un lien sur lequel ils cliquent. Le lien peut êtrewww.example.com/recipe/apple_pie

Maintenant, cela renvoie normalement 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 que l'utilisateur a sélectionnée, mais pour gagner du temps et de la bande passante, ne chargez pas l'en-tête / le pied de page / les annonces.

Maintenant, vous pouvez simplement écrire un point de terminaison secondaire pour les données, www.example.com/recipe_only/apple_piemais c'est plus difficile à maintenir et à partager avec d'autres personnes.

Mais il est plus facile de simplement détecter qu'il s'agit d'une demande ajax effectuant la demande, puis renvoyant uniquement une partie des données. De cette façon, l'utilisateur gaspille 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 qui sont ajax et qui ne le sont pas. Mais cela dépend entièrement du développeur d'utiliser ces techniques.

C'est en fait un peu similaire à l'en- Accept-Languagetête. Un navigateur peut demander un site Web, veuillez me montrer une version russe de ce site Web sans avoir à insérer / ru / ou similaire dans l'URL.

Certains cadres utilisent cet en-tête pour détecter les demandes xhr, par exemple la sécurité de Grails Spring utilise cet en-tête pour identifier la demande xhr et donner une réponse json ou une réponse html comme réponse.

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

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