Qu’est-ce qu’une attaque Cross Site Request Forgery ?

L’attaque CSRF (ou en français falsification de requête intersite) est une attaque qui oblige un utilisateur final à exécuter des actions non désirées et sans qu’il s’en rende compte sur une application web dans laquelle il est actuellement authentifié.
Les attaques CSRF visent spécifiquement les demandes de modification et non le vol de données, car l’attaquant n’a aucun moyen de voir la réponse à la demande falsifiée. Le résultat des actions est ce qui intéresse l’attaquant.

Ce type d’attaque s’appuie sur le fait que lorsqu’un utilisateur est authentifié sur une application, celle-ci lui fournit la plupart du temps un identifiant de session, stocké dans un cookie sur son navigateur.

Lire la suite →

Nous pensons souvent qu’un pare-feu suffisamment restrictif protège l’accès aux services non ouverts. Nous croyons aussi que seule une machine compromise peut donner accès au reste du réseau interne.

Et bien nous avons tort, et c’est ce que nous allons voir avec une vulnérabilité des applications web : le Server-Side Request Forgery (SSRF).

Qu’est-ce que les SSRF ?

A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts.

Lire la suite →

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 →