Comment fonctionnent les cookies HttpOnly avec requêtes AJAX ?

Question

JavaScript doit avoir accès à des cookies si l'AJAX est utilisé sur un site avec des restrictions d'accès basés sur les cookies. Sera des cookies HttpOnly travailler sur un site en AJAX?

Edit: Microsoft a créé un moyen pour empêcher les attaques XSS en interdisant les accès JavaScript pour les cookies si HttpOnly est spécifié. FireFox plus tard adopté le présent. Donc ma question est: Si vous êtes en utilisant AJAX sur un site, comme StackOverflow, sont Http Uniquement des cookies une option?

Edit 2: Question 2. Si le but de HttpOnly est pour éviter le JavaScript accès aux cookies, et vous pouvez toujours récupérer les cookies par l'intermédiaire de JavaScript via l'Objet XmlHttpRequest, ce qui est le point de HttpOnly?

Edit 3: Voici une citation de Wikipedia:

Lorsque le navigateur reçoit un cookie, il est censé l'utiliser comme d'habitude dans la suivante HTTP échanges, mais de ne pas la rendre visible pour les scripts côté client.[32] L' HttpOnly drapeau ne fait partie d'aucun standard, et n'est pas mis en œuvre dans tous les navigateurs. Notez qu'il n'existe actuellement pas de la prévention de la lecture ou de l'écriture, le cookie de session par l'intermédiaire d'un XMLHTTPRequest. [33].

Je comprends qu' document.cookie est bloqué lorsque vous utilisez HttpOnly. Mais il semble que vous pouvez toujours lire les valeurs de cookie dans l'objet XMLHttpRequest, permettant XSS. Comment HttpOnly vous rendre plus sûrs que? Par la fabrication de biscuits, essentiellement en lecture seule?

Dans votre exemple, je ne peux pas écrire à votre document.cookie, mais je peux encore voler votre cookie et de le poster à mon domaine en utilisant l'objet XMLHttpRequest.

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

Edit 4: Désolé, je voulais dire que vous pouvez envoyer à la XMLHttpRequest pour la StackOverflow domaine, puis enregistrer le résultat de getAllResponseHeaders() pour une chaîne regex le cookie, et puis après, qu'à un domaine externe. Il semble que Wikipédia et ha.ckers d'accord avec moi sur ce point, mais j'aimerais être rééduqués...

Final Edit: Ah, apparemment, les deux sites sont des faux, c'est réellement un bug dans FireFox. IE6 et 7 sont en fait les seuls navigateurs qui actuellement entièrement en charge HttpOnly.

À rappeler tout ce que j'ai appris:

• HttpOnly limite tous les accès au document.cookie dans IE7 et FireFox (je ne sais pas sur les autres navigateurs)
• HttpOnly supprime les informations de cookie de les en-têtes de réponse dans XMLHttpObject.getAllResponseHeaders() dans IE7.
• XMLHttpObjects ne peuvent être présentées pour le domaine de l'origine, donc il n'y a pas de contre-domaine de l'affichage de l'cookies.

edit: Cette information est probablement pas à jour.

Answer 1

Oui, HTTP Uniquement les cookies serait parfait pour cette fonctionnalité. Ils seront toujours fournis avec le XmlHttpRequest la demande au serveur.

Dans le cas de Dépassement de la Pile, les cookies sont automatiquement fournis dans le cadre de la requête XmlHttpRequest. Je ne connais pas les détails de mise en œuvre de l'Débordement de Pile fournisseur d'authentification, mais que les données de cookie est probablement automatiquement utilisées pour vérifier votre identité à un niveau inférieur à celui de la "voix" de la méthode du contrôleur.

Plus généralement, les témoins ne sont pas requis pour l'AJAX. XmlHttpRequest soutien (ou même iframe remoting, sur les anciens navigateurs) est tout ce qui est techniquement nécessaire.

Cependant, si vous souhaitez assurer la sécurité de l'AJAX activé la fonctionnalité, puis on applique les mêmes règles qu'avec les sites traditionnels. Vous avez besoin d'une méthode d'identification de l'utilisateur derrière chaque demande, et les cookies sont presque toujours les moyens à cette fin.

Dans votre exemple, je ne peux pas écrire à votre document.cookie, mais je peux encore voler votre cookie et de le poster à mon domaine en utilisant l'objet XMLHttpRequest.

XmlHttpRequest ne vais pas en faire des requêtes inter-domaine (pour exactement les raisons de votre doigt sur).

Vous ne pourriez normalement injecter un script pour envoyer le cookie à votre domaine à l'aide d'une iframe remoting ou JSONP, mais alors HTTP-ne protège que le cookie de nouveau, car il est inaccessible.

À moins que vous avait compromis StackOverflow.com du côté du serveur, vous ne seriez pas en mesure de voler mon cookie.

Edit 2: Question 2. Si le but de Http-Seulement pour empêcher JavaScript accès aux cookies, et vous pouvez toujours récupérer les cookies par l'intermédiaire de JavaScript via l'Objet XmlHttpRequest, ce qui est le point de Http Seule?

Considérez le scénario suivant:

• J'ai trouver un moyen pour injecter du code JavaScript dans la page.
• Jeff charge la page et mon code JavaScript malveillant modifie son cookie pour correspondre à la mienne.
• Jeff soumet une excellente réponse à votre question.
• Parce qu'il soumet avec mon cookie de données au lieu de sa, la réponse va devenir le mien.
• Vous de voter "mon" stellaire réponse.
• Mon compte réel obtient le point.

Avec HTTP-Seulement les témoins, la deuxième étape serait impossible, ainsi à l'encontre de mon XSS tentative.

Edit 4: Désolé, je voulais dire que vous pouvez envoyer à la XMLHttpRequest pour la StackOverflow domaine, puis enregistrer le résultat de getAllResponseHeaders() pour une chaîne regex le cookie, et puis après, qu'à un domaine externe. Il semble que Wikipédia et ha.ckers d'accord avec moi sur ce point, mais j'aimerais être rééduqués...

C'est correct. Vous pouvez toujours session détourner de cette façon. Il ne prend de manière significative mince le troupeau de gens qui peuvent exécuter avec succès de même que XSS hack contre vous.

Cependant, si vous allez revenir à mon exemple de scénario, vous pouvez voir où le HTTP-Seulement n'a réussi à couper les attaques XSS qui reposent sur la modification du client cookies (pas rare).

Elle se résume au fait que a) aucune amélioration permettra de résoudre tous les vulnérabilités et b) aucun système ne jamais être complètement sûr. HTTP Seule est un outil utile dans la consolidation de contre XSS.

De la même manière, même si la croix de restriction de domaine sur XmlHttpRequest n'est pas 100% de succès dans la prévention de toutes les XSS exploits, tu serais encore jamais rêve de retrait de la restriction.

Answer 2

Pas forcément, ça dépend ce que vous voulez faire. Pourriez-vous élaborer un peu ? AJAX n’est pas besoin d’accéder aux cookies à travailler, il peut faire des requêtes sur son propre pour extraire des informations, la demande de page qui fait l’appel AJAX pouvait accéder à des données de cookie & pass que retour vers le script appelant sans passer par Javascript pour accéder directement aux cookies

Answer 3

Oui, ils sont une option viable pour un Ajax basé sur site. Les cookies d'authentification ne sont pas à la manipulation par les scripts, mais sont tout simplement inclus par le navigateur sur toutes les requêtes HTTP vers le serveur.

Les Scripts n'ont pas besoin de vous soucier de ce que le cookie de session, dit - aussi longtemps que vous êtes authentifié, alors toutes les requêtes vers le serveur lancé par un utilisateur ou le script d'inclure les cookies. Le fait que les scripts ne peuvent pas, eux, savent le contenu du cookie n'a pas d'importance.

Pour tous les cookies qui sont utilisés à des fins autres que l'authentification, il peut être défini sans le HTTP seul drapeau, si vous voulez script pour être en mesure de les modifier ou de les lire. Vous pouvez choisir les cookies doivent être uniquement HTTP, par exemple, quelque chose de non-sensibles comme les préférences de l'INTERFACE utilisateur (de l'ordre de tri, l'effondrement volet de gauche ou pas) peuvent être partagés dans les cookies avec les scripts.

J'aime vraiment le seulement les cookies HTTP - c'est un de ces propriétaires extensions de navigateur qui a été une très bonne idée.

Answer 4

Il y a un peu plus de cela.

Ajax n'est pas strictement besoin d'utiliser des cookies, mais ils peuvent être utiles que d'autres affiches ont mentionné. Marquage d'un cookies HTTPOnly de le cacher à partir de scripts en partie seulement, car pas tous les navigateurs prennent en charge, mais aussi parce qu'il existe des solutions de contournement.

C'est bizarre que le XMLHTTPresponse les en-têtes sont de donner le cookie, techniquement, le serveur n'a pas à le cookie de retour avec la réponse. Une fois installé sur le client, il reste en jeu jusqu'à ce qu'il expire. Bien qu'il existe des régimes dans lequel le cookie est changé à chaque requête pour empêcher la ré-utilisation. Donc, vous pourriez être en mesure d'éviter que la solution en changeant le serveur pour ne pas fournir le cookie sur le XMLHTTP réponses.

En général cependant, je pense que HTTPOnly doit être utilisé avec précaution. Il y a cross site scripting des attaques d'où un attaquant organise un utilisateur à envoyer une requête ajax-comme la demande en provenance d'un autre site, à l'aide de simples formulaires de publication, sans l'utilisation de XMLHTTP, et que votre navigateur est toujours active témoin d'authentifier la demande.

Si vous voulez être sûr qu'une requête AJAX est authentifié, la demande elle-même ET les en-têtes HTTP nécessité de contenir le cookie. Par exemple par l'utilisation de scripts ou unique caché entrées. HTTPOnly ferait obstacle à cela.

Généralement intéressant de raison de vouloir HTTPOnly est d'empêcher des tiers le contenu sur votre page web à partir de voler des cookies. Mais il y a de nombreuses raisons d'être très prudent sur le contenu de tiers, et le filtre de manière agressive.

Answer 5

Les cookies sont automatiquement gérés par le navigateur lorsque vous effectuez un appel AJAX, vous n'avez donc pas besoin de votre Javascript pour manipuler les cookies.