Est-il possible qu'une attaque XSS obtienne des cookies HttpOnly?

Question

En lisant ce billet de blog sur les cookies HttpOnly m'a fait commencer à penser, est-ce vrai? est-il possible d’obtenir un cookie HttpOnly par le biais d’une forme quelconque de XSS? Jeff mentionne qu'il "élève considérablement la barre". mais donne l'impression que cela ne protège pas complètement contre le XSS.

Hormis le fait que tous les navigateurs ne prennent pas correctement en charge cette fonctionnalité, comment un pirate informatique peut-il obtenir les cookies d'un utilisateur s'il utilise HttpOnly?

Je ne vois aucun moyen de faire en sorte qu'un cookie HttpOnly soit envoyé sur un autre site ou lu par un script; il semble donc qu'il s'agisse d'une fonctionnalité de sécurité sûre, mais je suis toujours étonné de la facilité avec laquelle certaines personnes peuvent contourner de nombreuses couches de sécurité.

Dans l'environnement dans lequel je travaille, nous utilisons exclusivement Internet Explorer, de sorte que les autres navigateurs ne sont pas une source de préoccupation. Je cherche en particulier d'autres moyens de résoudre ce problème, qui ne repose pas sur des défauts propres à un navigateur.

Answer 1

Tout d'abord, comme certains l'ont mentionné, XSS peut autoriser d'autres charges utiles, pas seulement le vol de cookies.

Mais, y a-t-il la possibilité de voler des cookies httpOnly, avec XSS? (en ignorant la question du support httpOnly?) .... La réponse est: oui.
Un sous-ensemble de XSS est appelé traçage intersite (XST) (ou cliquez sur le lien suivant). document de recherche original. Cette attaque permet au contenu XSS d'envoyer une demande HTTP TRACE au serveur Web (ou proxy , forward OR reverse), qui renvoie la demande complète au client, y compris vos cookies, httpOnly ou non. La charge XSS peut ensuite analyser les informations renvoyées et récupérer ces délicieux cookies ...

Btw, encore un autre "sous-ensemble" (un peu) de XSS, implique l’injection de charge utile dans les en-têtes de réponse. Bien que similaire, ce n'est pas exactement XSS, et l'injection d'en-tête peut même conduire à HTTP Le fractionnement de la réponse (HRS) - beaucoup plus puissant, permet un contrôle quasi complet des autres clients, l’empoisonnement du cache et, bien sûr, l’accès aux cookies, si souhaité.

Answer 2

Si le navigateur ne comprend pas HttpOnly, l'attaque réussit. Modifier: d'accord, vous n'êtes pas concerné. C'est bien, mais je vais laisser cet avis juste pour référence. Il est utile de l'indiquer explicitement.

Un autre moyen de voler en plus de renifler le réseau serait le contrôle direct de l'ordinateur de l'utilisateur. Ensuite, les cookies peuvent être lus à partir d'un fichier. S'il s'agit d'un cookie de session, il sera bien entendu supprimé après la fermeture du navigateur.

Soit dit en passant, voler un cookie de session n’est pas la seule possibilité de "charge utile". d'attaque XSS. Par exemple, cela pourrait rendre votre protection CSRF inutile. Cela peut altérer le contenu de votre site pour tromper l'utilisateur. Et beaucoup d'autres choses malveillantes.

Mieux vaut donc vous protéger (sortie d'échappement), et penser à HttpOnly en tant que couche supplémentaire de protection.

Answer 3

L'utilisation de cookies HttpOnly empêchera les attaques XSS de recevoir ces cookies.

Sauf si:

• votre navigateur ne supporte pas HttpOnly
• il existe dans le navigateur une vulnérabilité inconnue jusqu'à présent qui rompt HttpOnly
• le serveur a été compromis (mais vous aurez probablement de toute façon un problème).

Comme l'a noté une autre affiche: XSS n'est pas la seule menace, et la capture de cookies n'est pas la seule menace de XSS. Je suis sûr que vous le saviez - je suis en train de terminer!

Bonne chance!

Answer 4

JavaScript peut modifier le code HTML sur la page. Par conséquent, httpOnly ne pas ne signifie que vous êtes en sécurité contre XSS.

Answer 5

La détection de paquets peut lire les cookies transmis via http. Mais il ne peut pas tomber sous le XSS.