Quel est le point de la X-requested-with-tête?

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

X-Requested-With: XMLHttpRequest

Pourquoi est-ce nécessaire? Pourquoi un serveur de traiter les requêtes AJAX différemment des demandes normales?

Mise à JOUR: je viens de trouver un exemple réel à l'aide de cet en-tête: https://core.spreedly.com/manual/payment-methods/adding-with-js. Si le processeur de paiement est requis, sans AJAX, il la renvoie vers le site d'origine lorsque c'est fait. Lorsqu'il est demandé par l'AJAX, pas de redirection est faite.

  • "[Lorsque] a demandé sans AJAX, il la renvoie vers le site d'origine lorsque c'est fait. Lorsqu'il est demandé par l'AJAX, pas de redirection est faite." -> C'est exactement pourquoi vous voulez le faire. 🙂
  • stackoverflow.com/questions/3315914/...
InformationsquelleAutor Gili | 2013-07-04
  1. 221

    Une bonne raison pour la sécurité - ce qui peut empêcher CSRF attaques parce que cet en-tête ne peut pas être ajouté à la requête AJAX croix de domaine sans le consentement du serveur via De la SCRO.

    Uniquement les en-têtes suivants sont autorisés croix de domaine:

    • Accepter
    • Accept-Language
    • Content-Language
    • Dernier-Event-ID
    • Content-Type

    tout les autres à cause d'un "pré-vol" demande à être délivré de la SCRO navigateurs pris en charge.

    Sans SCRO il n'est pas possible d'ajouter X-Requested-With à une croix de domaine demande XHR.

    Si le serveur est en train de vérifier que cet en-tête est présent, il sait que la demande n'a pas amorcer à partir d'un attaquant du domaine de la tentative de faire une demande au nom de l'utilisateur avec le JavaScript. Ce vérifie également que la demande n'a pas Posté de régulièrement un formulaire HTML, de qui il est plus difficile de vérifier qu'il n'est pas de la croix de domaine sans l'utilisation de jetons. (Cependant, la vérification de l' Origine de l'en-tête pourrait être une option dans les navigateurs pris en charge, bien que vous quitterez les anciens navigateurs vulnérables.)

    Flash de dérivation découvert

    Vous pouvez combinez cela avec un jeton, parce que Flash en cours d'exécution sur Safari sur mac OSX pouvez définir cet en-tête si il y a une étape de redirection. Il semble il a également travaillé sur Chrome, mais est maintenant mis à jour. Plus de détails ici y compris les différentes versions affectées.

    OWASP vous Recommandons de combiner cela avec une Origine et Referer vérifier:

    Cette technique de défense est spécifiquement abordé dans la section 4.3 de
    Robuste Défenses Cross-Site Request Forgery. Cependant, contourne de
    ce moyen de défense à l'aide de Flash ont été documentées dès 2008, et de nouveau comme
    récemment, à l'horizon 2015 par Mathias Karlsson pour exploiter une faille CSRF dans Vimeo.
    Mais, nous pensons que le Flash attaque ne peut pas falsifier l'Origine ou
    Referer en-têtes afin en cochant les deux d'entre eux nous croyons que cette
    la combinaison des contrôles doit prévenir Flash contourner les attaques de type CSRF. (REMARQUE:
    Si quelqu'un peut confirmer ou infirmer cette croyance, s'il vous plaît laissez-nous savoir afin que nous
    pouvez mettre à jour cet article)

    Cependant, pour les raisons déjà discuté de la vérification de l'Origine peut être délicat.

    Mise à jour

    Écrit plus en profondeur un billet de blog sur De la SCRO, CSRF et X-requested-with ici.

    • Je n'ai pas l'obtenir. Qu'est ce qui empêche l'attaquant de la construction d'une demande et l'ajout d'un X-Requested-With en-tête ainsi?
    • Le navigateur, il ne permettra pas qu'il inter-domaine.
    • Oh, je ne savais pas à pas de la SCRO config serait nécessaire aussi longtemps que vous êtes sur le même domaine. Il est évident que quand vous pensez à ce sujet. Merci !
    • C'est toujours super gênant, car il se décompose d'un simple de la SCRO le programme d'installation qui ne nécessite pas un contrôle en amont des OPTIONS de la requête si aucun en-têtes supplémentaires sont présents. Je considère que c'est un bug, et qui ont dû patch jQuery pour pas ajouter.
    • donc, ce qui empêche quelqu'un de faire des demandes en dehors du navigateur?
    • Rien ne les arrête, mais ils n'auront pas leur victime, les témoins à la demande qui va à l'encontre de l'objet de leur faire la demande. Pour une CSRF pour réussir, l'attaquant aurait besoin le navigateur de joindre automatiquement les cookies à la demande, sans que le navigateur n'est pas une attaque CSRF.
    • non, ce que je veux dire c'est qu'il semble que il ya beaucoup de sécurité appliquées dans le client, plutôt que sur le serveur. Est le point d'empêcher le client de l'exécution de mauvais code externe, ou pour empêcher le client d'accéder au contenu qu'ils ne devraient pas être autorisés à accéder? Il fait sens pour la première question, mais celle-ci doit être appliquée au niveau du serveur, pas en faisant confiance à l'navigateur, n'importe qui peut fourche/créer un navigateur et de prendre des restrictions de sécurité.
    • L'ancien. CSRF est un confus adjoint problème. Le navigateur est le confondre adjoint et est "trompé" dans l'envoi de cookies pour demander à l'utilisateur de ne pas le faire eux-mêmes.
    • BTW, vous pouvez modifier le jQuery.l'ajax X-requested-with valeur d'en-tête par "en-tête" afin de la rendre plus sûre. Alors vérifiez cette valeur sur le côté serveur. api.jquery.com/jquery.ajax
    • Pourquoi avons-nous besoin de jetons CSRF en plus de cela? Ne serait pas la vérification de cet en-tête est assez pour empêcher CSRF?
    • Vous n'avez pas, sauf si il y a un autre bug en Flash (ou similaire plugin) qui permet à l'arbitraire des en-têtes ensemble, en contournant le navigateur restrictions habituelles.
    • Où sont ceux autorisés en-têtes documenté? Je ne vois qu'une liste noire à w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method et xhr.spec.whatwg.org/#the-setrequestheader%28%29-method
    • href="https://www.w3.org/TR/cors/#terminology" >Ici, je crois. Bien que je crois qu'il y a apporté quelques modifications au cours des implémentations à l'appui d'autres en-têtes tels que Last-Event-ID.

    InformationsquelleAutor SilverlightFox
  2. 21

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

    La raison en est surtout que si vous connaissez la source d'une requête vous pouvez le personnaliser un peu.

    Par exemple, disons que vous avez un site web qui a beaucoup de recettes. Et vous utilisez un personnalisé du framework jQuery pour glisser des recettes dans un conteneur basé sur un lien à cliquer.
    Le lien peut être www.example.com/recipe/apple_pie

    Maintenant, normalement, qui renvoie à une pleine page, en-tête, pied de page, la recette des contenus et des publicités. Mais si quelqu'un est à la navigation de votre site web certaines de ces pièces sont déjà chargés. Ainsi, vous pouvez utiliser AJAX pour obtenir la recette sélectionnée par l'utilisateur mais pour gagner du temps et de bande passante ne pas charger l'en-tête/pied de page/ads.

    Maintenant, vous pouvez simplement écrire un critère secondaire pour les données comme www.example.com/recipe_only/apple_pie mais c'est plus difficile de les maintenir et de les partager à d'autres personnes.

    Mais il est plus facile de détecter que c'est une requête ajax qui fait la demande, puis le retour d'une partie seulement des données. De cette façon, l'utilisateur utilise moins de bande passante et le site semble plus réactif.

    Les cadres ajouter l'en-tête parce que certains peuvent le trouver utile pour garder la trace des demandes de l'ajax et qui ne le sont pas. Mais c'est entièrement dépendante du développeur d'utiliser de telles techniques.

    C'est en fait assez similaire à la Accept-Language en-tête. Un navigateur peut demander à un site web, prière de me montrer une version russe de ce site sans avoir à insérer /ru/ou similaires dans l'URL.

    • Wow, qui sonne comme une horrible entretien cauchemar. Si vous voulez retourner une représentation différente de la même page, vous devez fournir un autre type de contenu à la Accept en-tête. À l'aide d'un en-tête personnalisé pour cela sonne comme de la mauvaise façon d'aller.
    InformationsquelleAutor EWit
  3. 7

    Certains cadres sont à l'aide de cet en-tête pour détecter les demandes xhr par exemple graal de la sécurité printemps est à l'aide de cet en-tête pour identifier xhr demande et de lui donner une réponse json ou réponse html réponse.

    La plupart des bibliothèques Ajax (Prototype, JQuery, et Dojo de la v2.1) comprennent un X-requested-with-tête qui indique que la demande a été faite par XMLHttpRequest au lieu d'être déclenchée en cliquant régulière d'un lien hypertexte ou de forme bouton "soumettre".

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

    InformationsquelleAutor Koray Güclü