Afin d'éviter l'authentification en continu pour chaque page d'un site ou d'un service, les applications Web mettent en œuvre divers mécanismes pour stocker et valider les informations d'identification pour un laps de temps prédéterminé. Ces mécanismes sont connus sous le nom de gestion de session et, alors qu'ils sont utilisés pour augmenter la facilité d'utilisation et la convivialité de l'application, ils pourraient être exploités par un testeur de pénétration afin d'accéder à un compte d'utilisateur, sans avoir besoin de fournir des informations d'identification correctes. Dans ce test, nous voulons vérifier que les cookies et autres jetons de session sont créés de manière sécurisée et imprévisible. Un attaquant qui est capable de prédire et de forger un cookie faible peut facilement détourner des sessions des utilisateurs légitimes.

• Description des vulnérabilités de gestion de session : voire les articles sur l'OWASP sur les vulnérabilités de gestion des sessions.
• Description des countremesures de la gestion de session : voir les articles sur l'OWASP sur les contre-mesures de gestion des sessions
• Comment éviter les vulnérabilités Voir l'article de l'OWASP Guide de développement sur la manière d'éviter les vulnérabilités de gestion des sessions.
• Comment détecter les vulnérabilités dans le code de gestion de session : voir l'article de l'OWASP Guide d'examen du Code sur la façon de détecter les vulnérabilités de gestion des sessions.

Les cookies sont utilisés pour mettre en œuvre la gestion des sessions et sont décrits en détail dans la RFC 2965. En un mot, lorsqu'un utilisateur accède à une application qui a besoin de garder une trace des actions et de l'identité de l'utilisateur à travers de multiples demandes, un cookie (ou plusieurs) est généré par le serveur et envoyé au client. Le client envoie ensuite le cookie au serveur pour toutes les connexions suivantes jusqu'à ce que le cookie expire ou soit détruit. Les données stockées dans le cookie peuvent fournir au serveur un large éventail d'informations sur qui est l'utilisateur, quelles actions il a accomplies jusqu'à présent, quelles sont ses préférences, etc offrant ainsi un état à un protocole stateless comme HTTP.

Un exemple typique est fourni par un panier en ligne. Tout au long de la session d'un utilisateur, l'application doit garder la trace de son identité, son profil, les produits qu'il a choisis d'acheter, de la quantité, les prix individuels, les remises, etc.. les cookies sont un moyen efficace de stocker et de transmettre cette l'information dans les deux sens (d'autres méthodes sont des paramètres d'URL et les champs cachés).

En raison de l'importance des données qu'ils stockent, les cookies sont donc vitaux dans la sécurité globale de l'application. Être capable de manipuler les cookies peut entraîner le détournement des sessions des utilisateurs légitimes, gagner des privilèges plus élevés dans une session active, et en général influer sur les opérations de l'application d'une manière non autorisée. Dans ce test, nous devons vérifier si les cookies retournés aux clients peuvent résister à un large éventail d'attaques visant à interférer avec les sessions des utilisateurs légitimes et avec l'application elle-même. L'objectif global est d'être capable de forger un cookie qui sera considérée comme valide par l'application et qui fournira un accès non autorisé (détournement de session, une escalade de privilège, …). Habituellement, les principales étapes du schéma d'attaque sont les suivantes:

• Collecte des cookies: la collecte d'un nombre suffisant d'échantillons de cookies;
• Ingénierie inverse du cookie: analyse de l'algorithme de génération de cookie;
• Manipulation des cookies: forger un cookie valide pour effectuer l'attaque. Cette dernière étape peut nécessiter un grand nombre de tentatives, selon la façon dont le cookie est créé (attaque par force brute des cookies).

Un autre type d'attaque consiste à déborder un cookie. Strictement parlant, cette attaque a une nature différente, car ici on ne cherche pas à recréer un cookie parfaitement valide. Au lieu de cela, notre objectif est de déborder une zone de mémoire, interférant ainsi avec le bon comportement de l'application et éventuellement injecter (et à distance lancer l'exécution) du code malveillant.

Toute interaction entre le client et l'application devrait être testé au moins sur les critères suivants:

• Toutes les directives Set-Cookie sont-elles marquées comme sécurisées?
• Y a t-il des opérations sur les cookie qui se déroulent dans les transports en clair?
• Peut-on forcer sur transports en clair du cookie?
• Si oui, quelle est l'application à maintenir?
• Y a t-il des cookies persistants?
• Quels sont les délais d'expiration utilisés sur les cookies persistants, et sont-ils raisonnables?
• Les cookies qui sont censés être transitoire sont-ils configurés en tant que tels?
• Est-ce que les paramètres HTTP/1.1 Cache-Control sont utilisés pour protéger les témoins?
• Est-ce que les paramètres HTTP/1.0 Cache-Control sont utilisés pour protéger les témoins?

La première étape nécessaire dans le but de manipuler le cookie est évidemment de comprendre comment l'application crée et gère les cookies. Pour cette tâche, nous devons essayer de répondre aux questions suivantes:

• Combien de cookies sont utilisés par l'application? Pour cela surfez dans l'application et notez lorsque les cookies sont créés. Faites une liste des cookies reçus, la page qui les définit (avec la directive set-cookie), le domaine pour lequel ils sont valables, leur valeur et leurs caractéristiques.
• Quelles sont les parties de l'application qui produisent et / ou de modifient le cookie? Surfez dans l'application, trouver quels cookies restent constants et ceux qui sont modifiés. Quels sont les événements qui modifient le cookie?
• Quelles sont les parties de l'application qui on besoins d'un cookie afin d'être accessibles et utilisées? Découvrez quelles parties de l'application ont besoin d'un cookie. Accéder à la page, puis essayez à nouveau sans le cookie, ou avec une valeur modifiée de celui-ci. Essayez de mapper quels cookies sont utilisés et où.

Une feuille de calcul avec pour chaque cookie en correspondance les parties d'application correspondantes et les renseignements connexes peuvent être une sortie valable de cette phase.

Les jetons de session (cookies, champ SessionID ou cachés) eux-mêmes devraient être examinés pour s'assurer de leur qualité du point de vue de la sécurité. Ils doivent être testés en fonction de critères tels que leur caractère aléatoire, l'unicité, la résistance à l'analyse statistique et de cryptographie et les fuites d'informations.

La première étape consiste à examiner la structure et le contenu d'un ID de session fourni par l'application. Une erreur courante consiste à inclure des données spécifiques dans le jeton au lieu de délivrer une valeur générique et ainsi référencer des données réelles sur le côté serveur. Si l'ID de session est en texte clair, la structure et les données pertinentes peuvent être immédiatement mises en évidence comme dans ce qui suit:

192.168.100.1:owaspuser:password:15:58

Si une partie ou la totalité du jeton semble être codée ou haché, il doit être comparé à diverses techniques pour vérifier la pertinence de la dissimulation. Par exemple, la chaîne “192.168.100.1:owaspuser:password:15:58” est représenté en hexadécimal, en Base64 et en hash MD5:

Hex : 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 : MtkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 : 01c2fc4f0a817afd8366689bd29dd40a

Après avoir identifié le type de dissimulation, il peut être possible de décoder pour retrouver les données d'origine. Dans la plupart des cas, cependant, cela est peu probable. Mais même ainsi, il peut être utile d'énumérer l'encodage en place dans le format du message. En outre, si le format et la technique d'obscurcissement peut être déduite, l'automatisation des attaques par force brute peut être conçue.

Des jetons hybrides peuvent inclure des informations telles que l'adresse IP ou l'ID utilisateur avec une partie codée, comme suit:

owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412

Après avoir analysé un jeton de session unique, l'échantillon représentatif devrait être étudié. Une simple analyse des jetons doit immédiatement révéler des tendances évidentes. Par exemple, un jeton de 32 bits peut inclure 16 bits de données statiques et 16 bits de données variables. Cela peut indiquer que les 16 premiers bits représentent un attribut fixe de l'utilisateur - par exemple, le nom d'utilisateur ou l'adresse IP. Si le second morceau de 16 bits incrémente à un rythme régulier, cela peut indiquer un élément séquentiel ou même la génération de jetons en fonction du temps (Voir les exemples). Si les éléments statiques du jeton sont identifiés, des échantillons supplémentaires doivent être recueillies,pour faire varier un seul élément d'entrée potentiel à la fois. Par exemple, les tentatives de connexion par le biais d'un compte utilisateur différent ou à partir d'une adresse IP différente peuvent induire une variation dans la partie présumée statique du jeton de session. Les domaines suivants devraient être abordés lors de test Structure de l'ID unique et multiple de la session:

• Quelles parties de l'ID de session sont statiques?
• Quelles informations confidentielles sont stockées en texte clair dans l'ID de session? Par exemple noms d'utilisateur / UID, les adresses IP
• Est-il facile à décoder les informations confidentielles qui sont stockées?
• Quelles informations peuvent être déduites de la structure de l'ID de session?
• Quelles parties de l'ID de session sont statiques pour les mêmes identifiants de connexion?
• Quelles tendances évidentes sont présentes dans l'ID de session dans son ensemble, ou des portions individuelles?

L'analyse des domaines variables (le cas échéant) de l'ID de session doit être entrepris pour établir l'existence de motifs reconnaissables ou prévisibles. Ces analyses peuvent être effectuées manuellement et avec sur mesure ou statistique ou avec des outils d'analyse cryptographique afin d'en déduire les motifs de l'ID de Session. Les contrôles manuels doivent inclure la comparaison des identifiants de session émis dans les mêmes conditions de connexion - par exemple, les mêmes nom d'utilisateur, mot de passe et adresse IP. Le temps est un facteur important qui doit également être contrôlé. Un grand nombre de connexions simultanées devraient être faites afin de recueillir des échantillons dans la fenêtre du même temps et de garder cette variable constante. Même une quantification de 50 ms ou moins peut-être trop large et un échantillon prélevé de cette manière peut révéler des composants basés sur le temps qui, autrement, seraient manqués. Les éléments variables doivent être analysés au fil du temps afin de déterminer si ils sont de nature progressive. S'ils sont incrémentales, les modèles relatifs au temps absolu ou le temps écoulé doivent être étudiés. De nombreux systèmes utilisent le temps comme une graine pour leurs éléments pseudo-aléatoires. Lorsque les motifs sont apparemment aléatoires, des hachages unidirectionnels de temps ou d'autres variations de l'environnement doivent être considérés comme une possibilité. En règle générale, le résultat d'une fonction de hachage cryptographique est un nombre décimal ou hexadécimal devrait donc être identifiable. En analysant les séquences des ID de session, les modèles ou les cycles, des éléments statiques et les dépendances du client doivent tous être considérés comme d'éventuels éléments qui contribuent à la structure et la fonction de l'application.

• Les ID de Session Sont-ils réellement aléatoires? Est-ce-que les valeurs résultantes peuvent être reproduites?
• Les mêmes conditions d'entrée produisent elles le même ID sur une exécution subséquente?
• Les ID de session sont-ils résistant à l'analyse statistique ou à la cryptanalyse ?
• Quels sont les éléments des identifiants de session qui sont liés à des éléments temporels?
• Quelles parties de l'ID de session sont prévisibles?
• Le prochain ID Peut-il être déduit, compte tenu de laconnaissance de l'algorithme de génération des ID précédentes?

Maintenant que nous avons énuméré les cookies et que nous avons une idée générale de leur utilisation, il est temps d'avoir un regard plus profond sur les cookies qui semblent intéressants. A quels cookies nous intéresserons-nous? Un cookie, afin de fournir une méthode sécurisée de gestion de session, doit combiner plusieurs caractéristiques, dont chacune est destinée à protéger le cookie d'un type d'attaque. Ces caractéristiques sont résumées ci-dessous:

• L'imprévisibilité: un cookie doit contenir une certaine quantité de données dur à deviner . Plus il est difficile de forger un cookie valide, plus il sera difficile de briser la protection d'un utilisateur légitime. Si un attaquant peut deviner le cookie utilisé dans une session active d'un utilisateur légitime, il / elle sera en mesure de se faire passer pour cet utilisateur (session hijacking). Afin de rendre un cookie imprévisible, des valeurs aléatoires et / ou de cryptographie peuvent être utilisées.
• Résistance aux manipulations: un cookie doit résister aux tentatives malveillantes de modification. Si nous recevons un cookie comme IsAdmin=Yes, il est trivial de le modifier pour obtenir des droits d'administration, à moins que l'application n'effectue une double vérification (par exemple, l'ajout au cookie du hachage chiffré de sa valeur)
• Maturité: un cookie critique ne doit être valable que pour une période de temps appropriée et doit être supprimé du disque / mémoire a l'issue de cette période, afin d'éviter le risque d'être rejoué. Ceci ne s'applique pas aux cookies qui stockent des données non critiques qui doivent se souvenir d'une session
• Drapeau “Secure” : un cookie dont la valeur est essentielle pour l'intégrité de la session devrait avoir cette option activée, afin de permettre sa transmission que dans un canal chiffré pour empêcher l'écoute clandestine.

L'approche ici est de recueillir un nombre suffisant de cas d'un cookie et de commencer à chercher des modèles dans leur valeur. La signification exacte de «suffisant» peut varier d'une poignée d'échantillons, si la méthode de génération d'un cookie est très facile à briser, à plusieurs milliers, si nous avons besoin de procéder à une analyse mathématique (par exemple, chi-squares, attractors. Voir plus loin pour plus d'informations).

Il est important de porter une attention particulière au workflow de l'application, comme l'état d'une session peut avoir un lourd impact sur les cookies collectées: un cookie recueillis avant d'être authentifié peut être très différente d'un cookie obtenu après l'authentification.

Un autre aspect à tenir en compte est le temps: toujours enregistrer le moment exact où un témoin a été obtenue, quand il y a la possibilité que le temps joue un rôle dans la valeur du cookie (le serveur peut utiliser un timestamp dans le cadre de la valeur du cookie ). La durée enregistrée peut être l'heure locale ou l'horodatage du serveur inclus dans la réponse HTTP (ou les deux).

L'analyse des valeurs collectées, essayer de comprendre toutes les variables qui pourraient avoir influencé la valeur du cookie et essayez de les faire varier une à la fois. Collecter les différentes versions d'un même cookie qu'un serveur a modifié peut être très utile pour comprendre comment l'application lit et traite le cookie.

Des exemples de contrôles à effectuer à ce stade sont:

• Quel est le jeu de caractères utilisé dans le cookie? Le cookie a-t'il une valeur numérique? alphanumérique? hexadécimal? Qu'est-ce qui se passe si nous insérons dans un cookie qui *caractères n'appartenant pas au jeu de carctères prévu?
• Le cookie est-il composée de différentes sous-parties transportant différents éléments d'information? Comment les différentes parties sont-elles séparées? Avec quels délimiteurs? *Certaines parties de ce cookie peut avoir une variance plus élevée, d'autres pourraient être constant, d'autres pourraient prendre seulement un ensemble limité de valeurs. Découper *le cookie à ses composants de base est la première étape fondamentale. Un exemple d'un cookie facile à déstructuré est la suivante:

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q

Dans cet exemple, nous voyons 5 domaines différents, portant différents types de données:

• ID – hexadécimale
• CR - petit entier
• TM et LM - grand entier. (Et curieusement ils détiennent la même valeur. voir ce qui se passe modifiant l'un d'eux)
• S – alphanumérique

Même si aucun délimiteur n'est utilisé, avoir suffisamment d'échantillons peut vous aider. A titre d'exemple, regardons la série suivante:

0123456789abcdef

L'attaque Brute force conduit inévitablement à des questions relatives de prévisibilité et de caractère aléatoire. La variance entre les identifiants de session doit être examiné conjointement avec les durées de session et les délais. Si la variation dans les ID de session est relativement faible, et la validité Session ID est longue, la probabilité d'un succès d'une attaque par force brute est beaucoup plus élevé. Un Id de Session long (ou plutôt un ID avec beaucoup de variation) et une période de validité plus courte, rendraient beaucoup plus difficile le réussite d'une attaque en brute force.

Combien de temps une attaque par brute force sur tous les ID de session possible doit-elle prendre? Est ce que l'espace entre ID de Session est suffisamment grand pour empêcher ce test? Par exemple, la longueur de la clé est-elle suffisante par rapport à la durée de vie valide? Est-ce que le délais entre deux tentatives de connexion avec différents ID de session permet d'atténuer le risque de cette attaque?

Si vous avez accès à la mise en œuvre du schéma de gestion de session, vous pouvez vérifier les points suivants:

L'ID de session ou cookies renvoyé au client ne doivent pas être facilement prévisibles (ne pas utiliser des algorithmes linéaires basés sur des variables prévisibles tels que l'adresse IP du client). L'utilisation d'algorithmes cryptographiques avec une longueur de clé de 256 bits est encouragée (comme AES).

L'ID de session sera d'au moins 50 caractères maximum.

Le jeton de session doit avoir un time-out (cela dépend de la criticité de l'application des données gérées)

• mémoire RAM uniquement: non persistant
• sécurisés (uniquement sur le cana HTTPS ): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure

  • HTTPOnly (non lisible par un script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly

  Plus d'informations ici: Testing for cookies attributes

• RFC 2965 “HTTP State Management Mechanism”

  • RFC 1750 “Randomness Recommendations for Security”
  • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis” (2001): http://lcamtuf.coredump.cx/oldtcp/tcpseq.html
  • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later” (2002): http://lcamtuf.coredump.cx/newtcp/
  • Correlation Coefficient: http://mathworld.wolfram.com/CorrelationCoefficient.html
  • Darrin Barrall: “Automated Cookie Analysis” – http://www.spidynamics.com/assets/documents/SPIcookies.pdf
  • ENT: http://fourmilab.ch/random/
  • http://seclists.org/lists/fulldisclosure/2005/Jun/0188.html
  • Gunter Ollmann: “Web Based Session Management” - http://www.technicalinfo.net
  • Matteo Meucci:“MMS Spoofing” - http://www.owasp.org/images/7/72/MMS_Spoofing.ppt

• OWASP's WebScarab dispose d'un mécanisme d'analyse de jeton de session. Vous pouvez consulter How to test session identifier strength with WebScarab.

  • Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
  • Foundstone CookieDigger - http://www.foundstone.com/resources/proddesc/cookiedigger.htm

• Session ID Analysis with WebScarab - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_AnalyzingSessions/

  • Session Hijacking in Webgoat Lesson - http://yehg.net/lab/pr0js/training/view/owasp/webgoat/WebGoat_SessionMan_SessionHijackingWithJHijack/