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.
Lorsqu’on développe un jeu, on peut avoir besoin de sauvegarder la partie d’un joueur dans un fichier pour ne pas perdre sa progression afin qu’il puisse revenir là où il en était. De la même manière, quand on développe un éditeur de texte en ligne, on peut vouloir préserver le contenu que l’utilisateur a écrit.
En effet, il y a beaucoup de cas où l’on souhaite sauvegarder l’état de notre application pour le rétablir dans le futur. Deux termes sont utilisés pour définir ce processus : la sérialisation et la désérialisation.
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.
Découverte d’une injection SQL avec le scanner de BURP
Lors d’un pentest, nous sommes tombés sur cette situation :
Le brute force est certainement l’une des techniques d’attaques les plus triviales. La principale raison : le facteur humain reste le maillon faible de la chaine cybersécurité. En effet, nul besoin de réaliser des attaques d’ingénierie sociale ou des attaques d’injection SQL sophistiquées pour voler des identifiants car les habitudes ont la vie dure : les mots de passe des utilisateurs restent faibles donc faciles à deviner. Avec les bons outils, même les attaquants les plus novices parviennent à compromettre les données et paralyser les systèmes de grandes entreprises.
Le Cross-site Scripting (abrégé XSS) est une vulnérabilité particulièrement répandue dans les applications web. En effet, plus d’une application sur deux en contiendrait selon diverses études, d’anciennes comme de plus récentes. Pour étayer ce propos, il s’agit de la vulnérabilité la plus courante que nous découvrons et exploitons lors de nos pentests sur tous types d’applications et de sites web.
Principes, types d’attaques XSS, exploitations, nous vous présentons dans cet article une vue d’ensemble des XSS, ainsi que les bonnes pratiques sécurité et mesures à implémenter pour contrer les risques d’attaques.
Les DOM-based XSS sont des vulnérabilités particulièrement méconnues car plutôt rares. En effet, il s’agit d’une variante de XSS (Cross-Site Scripting) – certainement l’une des failles les plus répandues dans les applications web.
Principes, impacts, exploitations possibles, nous vous présentons dans cet article un aperçu complet des vulnérabilités DOM XSS ainsi que les bonnes pratiques pour prévenir les risques d’attaques et de compromission de vos applications web.
Introduction
Le jeton CSRF est une protection qui requiert l’insertion d’une valeur aléatoire et dynamique dans une requête. Cette valeur est ensuite analysée par le serveur pour déterminer si la requête est légitime. Lors de vos tests d’intrusion, il vous est surement déjà arrivé de tomber sur une application utilisant ces jetons CSRF. Dans ce cas, vous avez sans doute constaté à quel point il est déroutant d’analyser une telle application avec Burp.
La plupart des applications web utilisent une ou plusieurs base(s) de données pour stocker et traiter les informations en temps réel.
En effet, lorsqu’un utilisateur envoie des requêtes, l’application web interroge la base de données afin de construire la réponse. Cependant, lorsque les informations fournies par l’utilisateur sont utilisées pour forger la requête à la base de données, un attaquant peut altérer cette dernière en l’utilisant à d’autres fins que celles prévues par le développeur d’origine. Ainsi, cela permet à un attaquant d’interroger la base de données via une injection SQL, abrégé en SQLi.