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.

En 2021, le top 10 de l’OWASP, qui met en lumière les vulnérabilités les plus courantes des applications, a quelque peu évolué. En effet les failles d’injection, auparavant les plus critiques, se retrouvent désormais sur la troisième marche du podium.

Cela peut s’expliquer notamment par le fait que les développeurs prennent davantage conscience des risques liés aux vulnérabilités d’injections via la mise en œuvre d’outils et de pratiques plus sûrs pour le développement d’applications. Et évidemment LA mesure essentielle pour limiter le risque d’injection SQL consiste en l’utilisation de requêtes préparées.

Pour ce faire, on utilise généralement un ORM, ce qui peut introduire de nouveaux risques comme nous allons le voir dans cet article.

Qu’est-ce qu’un deep link ?

Les deep links sont des URI (Uniform Resource Identifier) prédéfinies qui permettent d’accéder directement à une activité dans une application web ou mobile lorsque l’on clique dessus.

Ces liens se trouvent généralement sur des pages au sein d’une application web ou dans les webviews d’une application mobile. Lorsque l’utilisateur clique sur un deep link, et qu’il possède l’application permettant d’ouvrir ce type de lien, une popup lui propose d’ouvrir le lien avec l’application correspondante.