La plupart des applications intègrent une fonctionnalité, au demeurant critique, permettant d’identifier les utilisateurs. L’objectif :  garantir la confidentialité et l’intégrité de leurs données. Parmi les méthodes couramment utilisées pour permettre au serveur d’identifier un utilisateur, figurent les cookies de session, les tokens JWT, ou, dans certains cas, des solutions personnalisées.

De fait, la logique de génération de ces jetons de session est essentielle car, en cas de contournement ou de détournement, cela peut aboutir à un vol de compte et donc à des impacts critiques sur la sécurité des données voire à la compromission totale du système.

Lorsque nous visitons un site web, il est courant de pouvoir parcourir différentes pages. Chaque page peut être représentée par un fichier sur le serveur. Afin de déterminer quel fichier fournir, l’application a besoin que le client spécifie le fichier qui l’intéresse. Pour cela, il arrive que la page souhaitée par l’utilisateur soit présente dans un paramètre de la requête.

Qu’est-ce qu’une vulnérabilité de type Mass Assignment ?

Pour faciliter la tâche aux développeurs, de nombreux frameworks intègrent des fonctionnalités qui associent automatiquement les paramètres d’une requête HTTP à des variables liées à un objet dans le code de l’application.

Une vulnérabilité de type Mass Assignment survient lorsque le serveur ne filtre pas correctement les données transmises par l’utilisateur et les associe directement à un objet sans vérification.

Récemment, un de nos clients nous a demandé d’examiner son pipeline d’intégration et de déploiement continu (CI/CD), déployé sur une infrastructure AWS.

Dans cet article, nous allons montrer comment un développeur disposant d’un accès limité à GitLab aurait pu élever ses privilèges et accéder à des informations sensibles permettant de prendre le contrôle de l’infrastructure AWS et causer des dommages importants à l’organisation. Nous détaillerons également des bonnes pratiques et mesures à implémenter pour contrer ce type de risques.

Dans un précédent article, nous avons vu pourquoi il était important de stocker les mots de passe en base de données avec des fonctions de hachage robustes telles que Bcrypt et Argon2. Cela permet notamment de rendre totalement ineffectif des attaques brute force ou des attaques par dictionnaire.

Cependant, une problématique est régulièrement relevée sur des applications déjà existantes : comment utiliser les dernières recommandations sur le stockage des mots de passe sur une base de données déjà existante ?

Le contrôle d’accès est un élément central pour garantir la sécurité des applications web. Il doit reposer sur une authentification robuste et une gestion des sessions tenant compte des divers risques sécurité, comme le détournement de session (session hijacking).

Exploitation XSS, fixation de session, absence de chiffrement, contournement de MFA, etc., il existe de nombreuses techniques pour détourner la session d’un utilisateur. Dans cet article, nous présentons les principales attaques et exploitations.

Lors d’un test d’intrusion d’application web, nous sommes tombés sur la situation suivante.

Les IDOR (pour Insecure Direct Object Reference) sont des vulnérabilités très répandues dans les applications web au même titre que les failles XSS ou les injections SQL. Affiliées aux problèmes de droits, les failles IDOR sont en effet parmi celles que nous découvrons et exploitons le plus couramment lors de nos tests d’intrusion d’applications web.

Principes, scénarios d’attaques et exploitations, nous vous présentons dans cet article une vue d’ensemble des IDOR, ainsi que les bonnes pratiques sécurité et tests de droits à réaliser pour prévenir les risques d’attaques.

Lors d’un pentest d’application web, nous avons découvert une vulnérabilité liée à la configuration et à la mauvaise gestion des contrôles de droits sur GraphQL.