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.
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.
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.