Durant nos audits il nous arrive encore très souvent de rencontrer des énumérations utilisateurs qui pourraient avec les bonnes méthodes être facilement évitées. Dans cet article, nous traiterons des énumérations d’utilisateurs sur les formulaires de connexion, de réinitialisation de mot de passe et de création de compte. Cependant, les énumérations utilisateur peuvent se trouver sur d’autres fonctionnalités, telles que, par exemple, des formulaires de recherches ou des envois de messages.

Description

Définition

Une énumération d’utilisateur permet comme son nom l’indique de trouver des identifiants de connexion utilisateurs valides sur une application. Pour ce faire, un attaquant tentera d’entrer un certain nombre de noms d’utilisateurs et observera le comportement de l’application pour déterminer si un identifiant est valide ou non (message d’erreur différent, temps de réponse différents et plus généralement toute différence au niveau réponse HTTP).

Pour constituer une liste de candidats, un attaquant pourra par exemple essayer de trouver des adresses email ou des personnes liées à sa cible sur des moteurs de recherche ou sur les réseaux sociaux.

Pourquoi cela pose problème

Cela pose problème tout d’abord parce que si un attaquant trouve un identifiant utilisateur valide, il pourra l’utiliser pour affiner ses attaques. Il pourra par exemple tenter une attaque par bruteforce sur le formulaire de connexion de la plateforme si celui-ci est vulnérable à ce type d’attaque, ou bien encore cibler plus spécifiquement les personnes identifiées avec des attaques par phishing.

Qui est concerné

Il est vrai que sur les formulaires de connexion cette vulnérabilité est assez rare à l’heure actuelle. Cependant, elle reste assez répandue sur les formulaires de réinitialisation de mots de passe et encore plus sur les formulaires de création de compte.

Afin d’effectuer cette démonstration, nous avons développé une application vulnérable sous PHP qui contient un formulaire de connexion, un formulaire de réinitialisation de mot de passe ainsi qu’un formulaire de création de compte.

Lire la suite →

Sous PHP, la méthode principale pour gérer des sessions utilisateurs est l’utilisation de cookies de sessions appelés par défaut « PHPSESSID ». Lorsqu’un utilisateur se connecte sur une application, celle-ci demande la génération d’un identifiant de session au programme PHP présent sur le serveur Web. Celui-ci s’exécute et créé un code unique qu’il va stocker dans sa mémoire vive puis renvoyer au client grâce au header « Set-Cookie ». Les cookies étant conçus pour être automatiquement renvoyés dans chaque requête du navigateur vers le serveur, l’identifiant de session sera transmis systématiquement. Cette solution permet de gérer les cas classiques de connexion/déconnexion d’un utilisateur.

Cependant, ce type de fonctionnement ne permet pas de partager facilement un même compte pour s’authentifier sur plusieurs plateformes distinctes et le serveur a l’obligation de stocker l’état et les informations des sessions dans sa mémoire vive.

Les jetons JWT quant à eux sont “stateless”, cela signifie que les informations des sessions ouvertes ne sont pas stockées côté serveur. Outre le gain de mémoire que cela procure, les jetons JWT peuvent être utiles si vous souhaitez utiliser les mêmes comptes utilisateurs pour plusieurs applications. Il suffira que les applications utilisent la même clé privée pour signer et vérifier les jetons JWT. Les utilisateurs pourront ainsi s’authentifier une fois sur l’application hébergeant les comptes utilisateurs, puis ils pourront se connecter aux autres applications, celles-ci n’ayant qu’à vérifier la validité des jetons.

Description

Les « JSON Web Token » ou JWT sont des jetons générés par un serveur lors de l’authentification d’un utilisateur sur une application Web, et qui sont ensuite transmis au client.

Ils seront renvoyés avec chaque requête HTTP au serveur, ce qui lui permettra d’identifier l’utilisateur.

Pour ce faire, les informations contenues dans le jeton sont signées à l’aide d’une clé privée détenue par le serveur. Quand il recevra à nouveau le jeton, le serveur n’aura qu’à comparer la signature envoyée par le client et celle qu’il aura générée avec sa propre clé privée et à comparer les résultats. Si les signatures sont identiques, le jeton est valide.

Structure d’un jeton JWT

Si la norme RFC 7519 est bien respectée, un jeton JWT se compose de cette façon :
Une partie “Header”, contenant l’algorithme utilisé pour la signature ainsi que le type de jeton (dans notre cas toujours “JWT »), en JSON encodé en Base64
Une partie “Payload” contenant les informations du jeton, comme par exemple le nom de l’utilisateur, la date d’émission du jeton ou sa date d’expiration le tout en JSON encodé en Base64
Une partie “Signature”, qui correspond à la concaténation des parties “Header” et “Payload” chiffrée avec la clé privée.

Lire la suite →

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce troisième épisode présente les failles liées aux échanges de données

Une application mobile fonctionne rarement en mode non-connecté. Une exception pourrait être une application de type dictionnaire, qui n’a pas besoin de communiquer avec un quelconque serveur pour fonctionner : toutes les données sont déjà présentes dans l’application et l’utilisateur affiche des définitions de mots du dictionnaire.

Mais il s’agit d’un cas bien spécifique, car la plupart des applications mobiles communiquent avec un serveur web.

Données échangées par l’application mobile

Suivant les besoins métier, une application mobile peut être amenée à envoyer ou recevoir différents types de données, comme par exemple :

• Identifiants de connexion
• Données de session utilisateur
• Données personnelles
• Données transactionnelles liées au métier de l’application
• Données bancaires

Comment les données sont-elles échangées avec l’extérieur ?

Suivant les cas, différents flux de données peuvent être présents au sein d’une même application.
Prenons l’exemple d’une application ecommerce permettant à ses utilisateurs d’acheter des articles, et de laisser des commentaires.

Les différentes données transférées peuvent être :

• Données d’identification de l’utilisateur
• Statistiques d’utilisation de l’application
• Données relatives aux commentaires sur les produits

Dans notre exemple, trois serveurs interagissent avec l’application. Certains flux contiennent des données sensibles, d’autres non.

Lire la suite →

Cette série d’articles aborde les points les plus importants de la sécurité des applications mobiles, quelle que soit la plateforme (iOS, Android ou autre).
L’objectif est de démystifier les différents aspects de la sécurité mobile, avec des mots très simples.

Ce second épisode présente les failles liées au stockage non sécurisé des données.

Une application mobile peut stocker différents types d’informations :

• Données de géolocalisation
• Transactions
• Identifiants ou tokens d’authentification
• Données personnelles (PII)
• Données métier
• Données mises en cache (stockage temporaire)

Comment les données sont-elles stockées sur l’application?

En fonction de la plateforme (iOS, Android…), différents moyens de stockage peuvent être utilisés. Base de données, fichiers plats, fichiers XML, fichiers Plist, carte de stockage type SD… Des emplacements différents pour des contextes différents.
De plus, les données peuvent être cryptées, plus ou moins efficacement.

Lire la suite →