Pourquoi les cookies et les en-têtes set-cookie ne peuvent pas être définis lors de la création de xmlhttprequest en utilisant setRequestHeader?
Je me demandais pourquoi on ne peut pas définir cookie en-têtes en utilisant setRequestHeader. Y a-t-il une raison spécifique ou simplement qu'ils sont ajoutés par le navigateur lui-même, donc ces en-têtes sont désactivés? Est-il un problème de sécurité?
--Modifier
Je travaille sur node.js et utilisé le module xmlhttprequest. Voici le code de test:
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.withCredentials = true;
xhr.setRequestHeader('Cookie', "key=value");
xhr.send(null);
Ici, je dois définir cookie-header comme {[2] } n'ajoute pas explicitement cookie-header(comme le font les navigateurs). Lorsque vous essayez de le faire, xmlhttprequest donne erreur "Refused to set unsafe header".
Bien que j'ai trouvé un patch et réussi à envoyer l'en-tête de cookie. Mais je me demandais pourquoi il était désactivé pour définir cookie-header? Où-jamais je lis, a constaté qu'il est nécessaire pour l'intégrité des données et de la sécurité, mais ce que la sécurité peut être violée dans ce cas, est mentionné nulle part. Je veux évaluer si, ce problème d'intégrité des données est valide pour le nœud.js demande si je vais avec mon patch.
6 réponses
Je suis sûr que vous auriez parcouru le projet de travail et trouvé
Les en-têtes ci-dessus sont contrôlés par l'agent utilisateur pour le laisser contrôler ces aspects du transport.
Tout d'abord, nous devons comprendre, ce sont des normes qui fonctionnent comme des lignes directrices pour l'interopérabilité des fonctions entre les différents navigateurs. Ce n'est pas obligatoire pour le navigateur et donc les navigateurs ont un niveau différent d'adhésion à cette norme pour différentes raisons.
Deuxièmement, techniquement parlant, vous pouvez émuler un agent utilisateur, traiter votre programme comme le navigateur et peut très bien définir ces valeurs selon les normes mentionnées.
Enfin, l'intention de refuser l'écrasement des en-têtes ou de configurer des en-têtes pour certains champs comme Content-Length , Cookie ethos le secure design approach. C'est pour décourager ou au moins essayer de décourager la contrebande de requêtes HTTP.
, Vous pouvez désactiver ce comportement:
var xhr = new XMLHttpRequest();
xhr.setDisableHeaderCheck(true);
xhr.open(...);
...
Comme on le sait, pour les navigateurs, les cookies (entre autres propriétés) doivent être soigneusement gérés pour empêcher des tiers de voler des sessions utilisateur (ou d'autres données). Ceci est un problème avec les navigateurs, et la nature incontrôlée de visiter un site web qui exécute JavaScript arbitraire.
Bien sûr, ce risque d'exécution de code arbitraire est soit un risque faible ou non pour le nœud.js, comme vous exécutez seulement un script que vous avez écrit qui peut exécuter un autre code que vous avez prévu.
Si vous avez un coup d'oeil au code source de XMLHttpRequest de driverdan.js, vous trouverez:
// These headers are not user setable.
// The following are allowed but banned in the spec:
// * user-agent
var forbiddenRequestHeaders = [
"accept-charset",
"accept-encoding",
"access-control-request-headers",
"access-control-request-method",
"connection",
"content-length",
"content-transfer-encoding",
"cookie",
"cookie2",
"date",
"expect",
"host",
"keep-alive",
"origin",
"referer",
"te",
"trailer",
"transfer-encoding",
"upgrade",
"via" ];
Cette réponse à votre question spécifique de savoir pourquoi la restriction s'applique particulièrement à ce script utilisé pour node.js - le codeur suivait la spécification (aussi étroitement que possible), malgré ce sentiment que ce n'était probablement pas une précaution de sécurité requise dans node.js. Néanmoins, ce niveau de sécurité par défaut est facilement modifié.
Comme robertklep l'a souligné, vous pouvez désactiver cette précaution par défaut en en utilisant la méthode setDisableHeaderCheck. Et oui ce dernier point répond ou contribue de manière significative à une réponse à votre question parce que dans votre question vous avez déclaré:
I have found a patch and successfully able to send the cookie-header
Nous avons maintenant trouvé que vous n'aviez pas besoin de ce patch.
Bonne Chance!
Oui, il est nécessaire pour l'intégrité et la sécurité des données. Pour comprendre cela, vous devez comprendre le rôle des cookies dans les méthodes de requête HTTP.
Les Cookies sont importants pour identifier l'utilisateur, le navigateur, la connexion, etc. et sont stockés sur le navigateur web. JavaScript permet de manipuler les cookies, mais pas tous les cookies sur le navigateur. Voir cookies HTTP , ceux-ci ne sont définis que par le navigateur, afin que l'utilisateur ne puisse pas en abuser (via JavaScript).
Sur un navigateur pris en charge, un Le cookie de session HttpOnly sera utilisé uniquement lors de la transmission de requêtes HTTP (ou HTTPS), limitant ainsi l'accès d'autres API non HTTP (telles que JavaScript).
Lorsque vous envoyez xmlhttprequest, il lit les cookies HttpOnly et envoie au serveur via l'en-tête Cookie.
Maintenant, si vous faites xhr.setRequestHeader('Cookie', "key=value");, vous essayez de falsifier les cookies envoyés au serveur. {[2] } ajoutera key=value supplémentaire qui peut compromettre l'intégrité des cookies envoyés.
Ceux-ci sont utilisés par le serveur pour authentifier l'utilisateur (session, compte e-mail ou tout autre compte). Cela permet essentiellement au serveur d'empêcher l'utilisation abusive des cookies pour accéder au serveur.
La documentation mentionne que cela est fait pour protéger l'intégrité des données. http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method
Les en-têtes ci-dessus sont contrôlés par l'agent utilisateur pour le laisser contrôler ces aspects du transport. Cela garantit l'intégrité des données à certains étendue. Les noms d'en-tête commençant par Sec-ne peuvent pas être définis sur autoriser les nouveaux en-têtes à frapper qui sont garantis de ne pas provenir XMLHttpRequest.
J'ai pu résoudre ce problème en utilisant L'essentiel suivant:
https://gist.github.com/killmenot/9976859
L'idée de départ est pris à partir d'ici:
https://gist.github.com/jfromaniello/4087861
J'ai fait face à plusieurs problèmes:
- Source Gist est obsolète et ne fonctionne pas pour moi. Par exemple, L'API lib" request " a été modifiée.
- je pourrais travailler avec la bibliothèque "xmlhttprequest" de socket.IO-client et ne pas installer sur le même niveau avec Socket. IO-client.
- Original " Socket. IO-client "(0.9.16) utilise "xmlhttprequest" (1.4.2) qui ne fonctionne pas supporte la méthode" setDisableHeaderCheck " (mais 1.6.0 le fait). Donc, je fais une fourchette et l'utiliser https://github.com/intspirit/socket.io-client/tree/0.9.16+20140408120400
Socket. IO-client (1.0.0-pre) utilise engine.io-client qui utilise la version correcte de xmlhttprequest. Je suppose que dans le futur, je vais utiliser la version 1.0.0 au lieu de ma fourchette, spécifiez " XHR-polling" transport et mock XMLHttpRequest comme le fait l'essentiel d'origine.