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.
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:
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:
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:
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:
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.
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'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:
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:
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)
Plus d'informations ici: Testing for cookies attributes