Nous avons isolé les 3 principales vulnérabilités critiques en matière de sécurité des applications web auxquelles les utilisateurs d'Aikido sont confrontés. Ce guide décrit ce qu'elles sont, pourquoi elles sont si courantes et comment les corriger - ainsi que quelques autres vulnérabilités risquées que nous ne pouvions ignorer.
En vous attaquant rapidement et efficacement à ces problèmes, vous aurez déjà une bonne longueur d'avance dans la lutte pour la protection de votre application web contre la cybercriminalité.
1. Vulnérabilité du code la plus courante et la plus critique (SAST)
Le test statique de sécurité des applications (SAST) est une méthode de test qui analyse le code source à la recherche de vulnérabilités au début du cycle de développement. Il s'agit d'une méthode "boîte blanche", car le testeur connaît le fonctionnement de l'application.
Attaques par injection NoSQL (vulnérabilité du code : SAST)
L'injection NoSQL peut conduire à des fuites de données, à des bases de données corrompues, voire à la compromission complète du système. Malheureusement, il s'agit d'une vulnérabilité critique de la sécurité des applications web et nous avons vu de nombreux comptes d'utilisateurs d'Aikido exposés à cette vulnérabilité.
Qu'est-ce que l'injection NoSQL ?
L'injection NoSQL est un type d'attaque où les pirates utilisent un code malveillant pour manipuler ou obtenir un accès non autorisé à une base de données NoSQL. Contrairement aux injections SQL, qui ciblent les bases de données SQL, les injections NoSQL exploitent les vulnérabilités des bases de données NoSQL telles que MongoDB. Elles peuvent conduire à des fuites de données, à la corruption, voire au contrôle total de la base de données.
Pourquoi cette vulnérabilité est-elle si fréquente ?
L'injection NoSQL est courante en partie à cause de la popularité croissante des bases de données NoSQL, en particulier MongoDB. Ces bases de données offrent des avantages en termes de performances, mais elles s'accompagnent de défis uniques en matière de sécurité.
En outre, les bases de données NoSQL sont flexibles car elles acceptent différents formats tels que XML et JSON. Cette flexibilité est excellente, mais elle peut entraîner des vulnérabilités dans la sécurité des applications web, car les contrôles de sécurité standard risquent de ne pas détecter les entrées malveillantes adaptées à ces formats.
De plus, le vaste éventail de bases de données NoSQL, chacune avec sa propre syntaxe et sa propre structure, complique également la création de mesures de protection universelles. Les professionnels de la sécurité doivent comprendre les détails spécifiques de chaque base de données, ce qui rend le processus de prévention encore plus complexe.
Pire encore, et contrairement aux injections SQL traditionnelles, les injections NoSQL peuvent se produire dans différentes parties d'une application. Elles sont donc encore plus difficiles à détecter.
Comment remédier facilement à cette vulnérabilité ?
Utiliser la validation des entrées et les requêtes paramétrées. La validation des entrées permet de s'assurer que les entrées des utilisateurs correspondent aux types et aux formats attendus, et de rejeter les valeurs non sûres. Les requêtes paramétrées empêchent l'intégration d'entrées non validées.
D'une manière générale, il convient de toujours mettre en œuvre des fonctions de sécurité pour les bases de données, telles que l'authentification et le cryptage. Restez à jour avec les derniers correctifs. Veillez également à effectuer des audits réguliers du code et des configurations afin d'identifier et de corriger cette vulnérabilité et d'autres.
Deuxième prix : Laisser des fonctions de débogage dangereuses dans le code (vulnérabilité du code : SAST)
Les fonctions de débogage exposées permettent une reconnaissance qui aide les attaquants à exploiter les systèmes - parfois avec un risque de sécurité important.
Quelles sont les fonctions de débogage dangereuses ?
Les fonctions de débogage comme phpinfo() peuvent exposer des informations sensibles sur votre serveur et votre environnement. Cela inclut la version de PHP, les détails du système d'exploitation, les informations sur le serveur, et même les variables d'environnement qui peuvent contenir des clés secrètes (bien que nous ne recommandions pas de mettre des clés secrètes dans ces variables).
Par conséquent, la détection de la structure de votre système de fichiers par le biais de ces fonctions de débogage peut permettre aux pirates de mener des attaques par traversée de répertoire si votre site est vulnérable. Exposer phpinfo() en soi n'est pas nécessairement un risque élevé, mais cela peut faciliter légèrement la tâche des attaquants. Le principe est clair : moins les pirates ont d'informations spécifiques sur votre système, mieux c'est.
Pourquoi cette vulnérabilité est-elle si fréquente ?
Cette vulnérabilité de la sécurité des applications web se produit souvent parce que les développeurs utilisent ces fonctions pour le débogage et parfois même les poussent vers la production pour le dépannage. Des versions précipitées, l'absence de révision du code et la sous-estimation des risques sont autant de facteurs qui contribuent à l'exposition de ces fonctions.
Comment remédier facilement à cette vulnérabilité ?
- Révision du code : vérifiez régulièrement votre code pour identifier et supprimer les fonctions de débogage avant de le déployer en production.
- Outils automatisés d'analyse des vulnérabilités: utilisez un outil, comme Aikido, qui peut détecter les fonctions de débogage dangereuses.
- Configurations spécifiques à l'environnement : veillez à désactiver les fonctions de débogage dans l'environnement de production.
2. Vulnérabilité DAST la plus courante et la plus critique
Le test dynamique de la sécurité des applications (DAST) est une technique de test qui permet d'identifier les vulnérabilités des applications en cours d'exécution. Il s'agit d'une méthode dite "boîte noire", car elle se concentre uniquement sur le comportement observable. Le DAST vous montre à quoi le système pourrait ressembler pour un attaquant.
Oubli des principaux en-têtes de sécurité : HSTS et CSP (vulnérabilité du nuage : DAST)
L'absence d'une mise en œuvre correcte de HSTS et de CSP rend les applications web vulnérables à des attaques majeures telles que XSS et la divulgation d'informations.
Qu'est-ce que le CSP ?
La politique de sécurité du contenu (CSP) est un mécanisme de sécurité qui permet de déjouer diverses attaques basées sur le navigateur, telles que le cross-site scripting et le clickjacking. Pour ce faire, elle limite les comportements à risque dans les pages web, tels que le JavaScript en ligne et les fonctions eval() peu sûres. CSP applique des valeurs par défaut plus sûres afin de préserver l'intégrité et la confidentialité du contenu. Le principal avantage est la protection contre l'injection malveillante de scripts.
Pourquoi cette vulnérabilité DAST est-elle si fréquente ?
Il est très courant de négliger HSTS et CSP, en particulier CSP, et les développeurs donnent souvent la priorité à la fonctionnalité par rapport à ces en-têtes.
Vous devriez planifier le CSP dès le début du développement, mais il est souvent négligé. Et lorsque les développeurs essaient de l'implémenter ou de l'adapter plus tard, cela provoque des conflits, si bien qu'ils sautent complètement le CSP pour se consacrer à d'autres tâches. Les applications ne sont donc pas protégées et sont sujettes à toute une série de vulnérabilités en matière de sécurité des applications web.
Comment corriger facilement cette vulnérabilité de DAST ?
- Implémenter HSTS pour forcer les connexions HTTPS uniquement. Activer sur le serveur par le biais de fichiers de configuration ou d'un WAF.
- Définissez et appliquez une CSP stricte adaptée à votre application en limitant les pratiques dangereuses telles que les scripts en ligne. Testez soigneusement la compatibilité.
- Contrôler et mettre à jour en permanence les en-têtes au fur et à mesure de l'évolution de l'application afin de maintenir la protection.
3. Les vulnérabilités les plus courantes et les plus critiques de l'informatique en nuage (CSPM)
Les outils de gestion de la sécurité de l'informatique en nuage (CSPM) surveillent en permanence les environnements basés sur l'informatique en nuage afin de garantir le respect des normes et des meilleures pratiques en matière de sécurité. Les outils de CSPM recherchent les mauvaises configurations de sécurité et visent à atténuer les risques.
Les rôles IAM EC2 vulnérables aux attaques SSRF (cloud : CSPM)
Les rôles IAM EC2 ouverts peuvent souvent permettre aux attaquants de se déplacer latéralement et d'obtenir un accès non autorisé dans les environnements en nuage. L'impact potentiel de ce type d'attaque peut être dévastateur.
Quels sont les rôles de l'IAM EC2 ?
Les rôles IAM (Identity and Access Management) EC2 dans Amazon Web Services (AWS) délèguent des permissions pour déterminer les actions autorisées sur des ressources spécifiques. Ils permettent aux instances EC2 d'interagir en toute sécurité avec d'autres services AWS sans avoir à stocker des informations d'identification directement sur les instances elles-mêmes.
Qu'est-ce qu'une attaque SSRF ?
Une attaque de type SSRF (Server Side Request Forgery) consiste pour un pirate à forcer le serveur à effectuer des requêtes vers des ressources internes comme si c'était le serveur lui-même qui les demandait. Le pirate peut ainsi accéder à des systèmes non autorisés, contourner des contrôles ou même exécuter des commandes. Découvrez cet exemple terrifiant de la façon dont une attaque SSRF a pris le contrôle du cloud d'une startup via un simple formulaire d'envoi de courrier électronique.
Pourquoi cette vulnérabilité du CSPM est-elle si fréquente ?
Les rôles IAM EC2 sont généralement vulnérables aux attaques SSRF en raison d'une mauvaise configuration de la sécurité ou de rôles trop permissifs. Il est difficile de jongler avec des autorisations complexes dans le nuage et certains développeurs peuvent ne pas comprendre pleinement les risques. En outre, le fait de vouloir que les services fonctionnent parfaitement ensemble peut souvent inciter les équipes à accorder plus d'accès que ce qui est réellement nécessaire.
Comment corriger facilement cette vulnérabilité du CSPM ?
Il existe des méthodes efficaces pour gérer les rôles EC2 et atténuer les vulnérabilités de sécurité des applications web SSRF. Tout d'abord, respectez le principe du moindre privilège : n'autorisez que l'accès absolument nécessaire et rien de plus. Des rôles trop permissifs sont synonymes de problèmes.
Ensuite, utilisez les outils intégrés à AWS, tels que les groupes de sécurité et les ACL de réseau, pour verrouiller le trafic et réduire les ouvertures potentielles pour les attaques SSRF. Plus vous pouvez limiter l'accès, mieux c'est.
Il est également important de revoir et d'auditer régulièrement les rôles afin de repérer tout accès inutile qui pourrait se glisser au fil du temps et de l'évolution des choses. Gardez le contrôle.
Enfin, mettez en œuvre des outils de sécurité AWS spécifiquement axés sur la détection et la prévention des attaques SSRF avant qu'elles ne causent des dommages. Plus il y a de couches de protection, plus vous serez en sécurité.
Deuxième prix : Des temps d'exécution lambda obsolètes (cloud : CSPM)
Lorsque ces environnements d'exécution deviennent obsolètes, ils peuvent exposer les fonctions lambda aux attaquants.
Qu'est-ce qu'une durée d'exécution lambda périmée ?
Les runtimes lambda obsolètes font référence à l'utilisation d'anciennes versions de langages de programmation ou d'environnements dans les fonctions sans serveur (lambdas). Ces runtimes obsolètes peuvent ne pas disposer des derniers correctifs de sécurité ou des dernières mises à jour de fonctionnalités, exposant potentiellement les applications à des vulnérabilités connues en matière de sécurité des applications web.
Pourquoi cette vulnérabilité du CSPM est-elle si fréquente ?
La vulnérabilité provient souvent d'une mentalité "set and forget". Les développeurs peuvent déployer des lambdas avec un runtime spécifique et négliger de les mettre à jour lorsque de nouvelles versions sont publiées. Ils peuvent également commettre l'erreur de supposer que les fournisseurs de cloud computing s'occupent de toute la maintenance. Même si AWS et Google Cloud Functions assurent la maintenance des runtimes pour vous avec des correctifs mineurs du système d'exploitation, ils ne se chargeront pas des mises à jour majeures du langage. En outre, la complexité de la gestion de plusieurs lambdas fait qu'il est facile pour les runtimes obsolètes de passer entre les mailles du filet et de créer un risque supplémentaire.
Comment corriger facilement cette vulnérabilité du CSPM ?
Vous pouvez réduire ce risque en suivant trois règles simples :
- Examinez régulièrement les moteurs d'exécution utilisés et vérifiez les mises à jour.
- Mettre à jour vers les dernières versions prises en charge avec les correctifs de sécurité.
- Utiliser des outils d'automatisation pour gérer et mettre à jour les runtimes dans la mesure du possible.
Vulnérabilités et meilleures pratiques en matière de sécurité des applications web
Il est essentiel de comprendre ces vulnérabilités de sécurité des applications web pour assurer la sécurité du système, mais n'oubliez pas de suivre les meilleures pratiques en matière de sécurité. Restez à jour, appliquez les correctifs appropriés et maintenez une surveillance régulière pour que votre environnement reste sûr et sécurisé.
Analysez votre environnement avec Aikido dès maintenant pour savoir si vous êtes exposé à l'une de ces vulnérabilités.
Consultez la liste de contrôle de sécurité 2024 SaaS CTO d'Aikido pour obtenir des conseils concis sur plus de 40 façons d'améliorer la sécurité de votre personnel, de vos processus, de votre code, de votre infrastructure et plus encore.
.jpg)
.svg)
.jpg)
.jpg)
.jpg)
