dwndoc

User Tools

Site Tools

Trace: • testing_for_cookies_attributes
hack:testing_for_cookies_attributes

Table of Contents

testing_guide

Résumé

Les cookies sont souvent un vecteur d'attaque clé pour les utilisateurs malveillants (en général lorsqu'ils ciblent d'autres utilisateurs) et, à ce titre, l'application doit toujours prendre toutes les mesures nécessaires pour protéger les cookies. Dans cette section, nous allons examiner comment une application peut prendre les précautions nécessaires lors de l'attribution des cookies, et comment tester que ces attributs ont été correctement configurés.

Description

L'importance de l'utilisation sécurisée des cookies ne peut pas être sous-estimée, en particulier au sein des applications web dynamiques, qui ont besoin de maintenir l'état de la session à travers un protocole stateless tels que HTTP. Pour comprendre l'importance de cookies, il est impératif de comprendre pour qu 'elles fonctions ils sont principalement utilisés. Les fonctions de base sont généralement d'être utilisée pour maintenir une session suite à l'autorisation / authentification par jeton ou comme un conteneur de données temporaires. Ainsi, si un attaquant par un moyen quelconque est capable d'acquérir un jeton de session (par exemple, en exploitant une vulnérabilité de script intersite ou en reniflant une session non chiffrée), alors il / elle peut utiliser des cookies afin de détourner une session valide. En outre, les cookies permettent de maintenir l'état entre plusieurs demandes. Comme HTTP est apatride, le serveur ne peut pas déterminer si une demande qu'il reçoit est partie d'une session en cours ou c'est le début d'une nouvelle session sans un certain type d'identifiant. Cet identifiant est très souvent un cookie, bien que d'autres méthodes sont également possibles. Comme vous pouvez l'imaginer, il y a de nombreux différents types d'applications qui ont besoin de garder une trace de l'état de session entre plusieurs demandes. Le premier qui vient à l'esprit serait une boutique en ligne. Comme un utilisateur ajoute plusieurs éléments à un panier d'achat, ces données doivent être conservées dans des demandes ultérieures de la demande. Les cookies sont très couramment utilisées pour cette tâche et sont définies par l'application en utilisant la directive Set-Cookie dans la réponse HTTP de l'application, et est généralement dans un format nom = valeur (si les cookies sont activés et si ils sont pris en charge, ce qui est le cas pour tous les navigateurs modernes). Une fois qu'une demande a dit au navigateur d' utiliser un cookie particulier, le navigateur envoie le cookie à chaque demande ultérieure. Un cookie peut contenir des données telles que les articles à partir d'un panier d'achat en ligne, le prix de ces articles, la quantité de ces articles, le informations personnelles, les noms d'utilisateur, etc En raison de la nature sensible des informations contenues dans les cookies, ils sont généralement encodées ou cryptées dans le but de protéger les informations qu'ils contiennent. Souvent, plusieurs cookies seront transmis (séparés par un point-virgule) lors de demandes ultérieures. Par exemple, dans le cas d'une boutique en ligne, un nouveau cookie peut être généré lorsque vous ajoutez plusieurs éléments à votre panier. En outre, vous avez généralement un cookie pour l'authentification (jeton de session comme indiqué ci-dessus) une fois que vous vous connectez, et plusieurs autres cookies utilisés afin d'identifier les articles que vous souhaitez acheter et leurs informations auxiliaires (c.-à-prix et la quantité) .

Maintenant que vous avez une compréhension de la façon dont les cookies sont définis, quand ils le sont, pour quels objectifs ils sont utilisés, pourquoi ils sont utilisés, et leur importance, nous allons jeter un oeil sur les attributs qui peuvent être définis pour un cookie et comment tester si ces attributs sont bien sécurisés. Ce qui suit est une liste des attributs qui peuvent être définis pour chaque cookie et ce qu'elles sont leur signification. La section suivante se concentrera sur la façon de tester pour chaque attribut.

  • secure - Cet attribut indique au navigateur d'envoyer uniquement le cookie sur un canal sécurisé tel que HTTPS. Cela aidera à protéger le cookie en l'empêchant d'être passé par le biais d'un canal non chiffré. Si l'application peut être consultée sur les protocoles HTTP et HTTPS, alors il est possible que le cookie puisse être envoyé en texte clair.
  • HttpOnly - Cet attribut est utilisé pour aider à prévenir les attaques telles que le cross-site scripting, car elle ne permet pas au cookie d'être accessible via un script côté client comme JavaScript. Notez que tous les navigateurs prennent en charge cette fonctionnalité.
  • domain - Cet attribut est utilisé pour comparer par rapport au domaine du serveur dans l'URL qui est demandée. Si le domaine correspond ou si c'est un sous-domaine, alors l'attribut path sera contrôlé par la suite. Notez que seuls les hôtes du domaine spécifié peuventt définir un cookie pour ce domaine. L'attribut de domaine ne peut également pas être un domaine de premier niveau (tels que. Gov ou. Com) pour empêcher les serveurs de créer un cookie arbitraire pour un autre domaine. Si l'attribut de domaine n'est pas définie, alors le nom d'hôte du serveur qui génère le cookie est utilisé comme valeur par défaut du domaine. Par exemple, si un cookie est créé par une application à app.mydomain.com sans attribut de domaine, alors le cookie sera de nouveau présentée pour toutes les demandes ultérieures pour app.mydomain.com et ses sous-domaines (tels que hacker.app.mydomain . com), mais pas à otherapp.mydomain.com. Si un développeur a voulu desserrer cette contrainte, il peut alors définir l'attribut de domaine mydomain.com. Dans ce cas, le cookie sera envoyé à toutes les demandes de app.mydomain.com et ses sous-domaines, tels que hacker.app.mydomain.com, et même bank.mydomain.com. S'il y avait un serveur vulnérable sur un sous-domaine (par exemple, otherapp.mydomain.com) et si l'attribut de domaine a été réglé de manière trop lâche (par exemple, mydomain.com) le serveur vulnérable pourrait être utilisé pour récolter des cookies (comme des jetons de session).
  • path - En plus du domaine, le chemin URL pour lequel le cookie est valide peut être spécifié. Si le domaine et le chemin correspondent, alors le cookie sera envoyé dans la requête.Tout comme avec l'attribut de domaine, si l'attribut path est trop lâche, alors il pourrait exposer l'application vulnérable aux attaques d'autres applications sur le même serveur. Par exemple, si l'attribut path a été créé à la racine du serveur web “/”, les cookies seront renvoyés à toutes les applications dans le même domaine. expire - Cet attribut est utilisé pour définir des cookies persistants, car les cookies n'expireront pas avant que la date fixée soit dépassée. Ces cookies persistants seront utilisés par cette session du navigateur et par des sessions ultérieures jusqu'à ce que le cookie expire. Une fois la date de péremption est dépassée, le navigateur va supprimer le cookie. Par ailleurs, si cet attribut n'est pas défini, alors le cookie est valide uniquement dans la session du navigateur actuel et le cookie sera effacé quand la session se terminera.

Test boîte noire

En utilisant un proxy ou un plug-in permettant d'intercepter le trafic, piéger toutes les réponses où un cookie est installé par l'application (en utilisant la directive Set-cookie) et inspecter dans le cookie ce qui suit:

  • Attribut secure- À chaque fois qu'un cookie contient des informations sensibles ou un jeton de session, il devrait toujours être passés en utilisant un tunnel crypté. Par exemple, après la connexion à une application un jeton de session est défini à l'aide d'un cookie, vérifier qu'il est étiqueté en utilisant le drapeau “;secure”. Si ce n'est pas le cas, alors le navigateur pourra le passer par un canal non crypté comme HTTP.
  • Attribut HttpOnly - Cet attribut doit toujours être réglé même si tous les navigateur ne le supporte pas. Ceci facilite la sécurisation des attributs dans le cookie afin d'empêcher qu'il ne soit accessible par un script côté client. Vérifier que le flag “; HttpOnly” a bien été créé.
  • Attribut domain - Vérifiez que le domaine n'a pas été défini de façon trop lâche. Comme indiqué ci-dessus, il ne doit être défini que pour le serveur qui doit recevoir le cookie. Par exemple, si l'application réside sur le serveur app.mysite.com, alors il doit être réglé sur “; domain = app.mysite.com” et non “;. Domain = mysite.com” car cela permettrait à d'autres serveurs potentiellement vulnérables à recevoir le cookie.
  • Attribut path - Vérifiez que l'attribut path, tout comme l'attribut de domaine, n'a pas été réglée de façon trop lâche. Même si l'attribut de domaine a été configuré aussi serrée que possible, si le chemin est réglé sur le répertoire racine “/”, alors il peut être vulnérable à des applications peu sûres sur le même serveur. Par exemple, si la demande est situé dans /myappp/, vérifiez que le chemin des cookies est réglé sur “path = /myapp/” et non “; path=”/“ ou path=”/myapp“. Notez ici que le ”/“ doit être utilisée après myapp. Si il n'est pas utilisé, le navigateur peut envoyer le cookie à un chemin qui correspond à “myapp” tels que “myapp-exploit».
  • Attribut Expire - Assurez-vous que, si cet attribut est réglé à un moment dans l'avenir, qu'il ne contient pas d'informations sensibles. Par exemple, si un cookie est réglé sur ”;expires=Tue,13-Jun-2010 14:45:29 GMT” et que nous sommes le 10 Juin 2008, alors si ce cookie est un jeton de session qui est stocké sur le disque dur de l'utilisateur, un attaquant ou un utilisateur local (comme un admin) qui a accès à ce cookie peut accéder à l'application en présentant de nouveau celui-ci jusqu'à la date d'expiration.

Références

Livres blancs

Outils

hack/testing_for_cookies_attributes.txt · Last modified: 2025/01/29 08:34 by 127.0.0.1