Les 3 principales vulnérabilités de sécurité des applications web en 2024

Nous avons identifié les 3 principales vulnérabilités critiques 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 d'autres vulnérabilités risquées que nous ne pouvions ignorer.

Abordez ces problèmes tôt et efficacement, et vous aurez déjà une bonne longueur d'avance dans la lutte pour sécuriser votre application web contre la cybercriminalité.

1. La vulnérabilité du code la plus courante et la plus critique (SAST)

Les Tests de sécurité des applications statiques (SAST) sont une méthode de test qui analyse le code source à la recherche de vulnérabilités dès le début du cycle de développement. On l'appelle méthode de la boîte blanche (white-box) car le fonctionnement de l'application est connu du testeur.

Attaques par injection NoSQL (vulnérabilité du code : SAST)

L'injection NoSQL peut entraîner des fuites de données, des bases de données corrompues et même un compromis complet 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 utilisateurs Aikido y être exposés.

Qu'est-ce que l'injection NoSQL ?

L'injection NoSQL est un type d'attaque où les hackers utilisent du 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 comme MongoDB. Cela peut entraîner des fuites de données, une corruption ou même un contrôle total sur la base de données.

Pourquoi cette vulnérabilité est-elle si courante ?

L'injection NoSQL est courante en partie en raison 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 de sécurité uniques.

De plus, les bases de données NoSQL sont flexibles car elles acceptent divers formats comme XML et JSON. Cette flexibilité est excellente, mais elle peut entraîner des vulnérabilités de sécurité des applications web, car les contrôles de sécurité standard pourraient ne pas détecter les entrées malveillantes adaptées à ces formats.

Et la vaste gamme de bases de données NoSQL, chacune avec sa propre syntaxe et structure, rend également plus difficile la création de protections universelles. Les professionnels de la sécurité doivent comprendre les détails spécifiques de chaque base de données, ce qui ajoute de la complexité au processus de prévention.

Pire encore, et contrairement aux injections SQL traditionnelles, les injections NoSQL peuvent se produire dans différentes parties d'une application. Cela les rend encore plus difficiles à détecter.

Comment pouvez-vous facilement corriger cette vulnérabilité ?

Utiliser la validation des entrées et les requêtes paramétrées. La validation des entrées garantit que les saisies utilisateur correspondent aux types et formats attendus, rejetant ainsi les valeurs non sécurisées. Les requêtes paramétrées empêchent l'intégration d'entrées non validées.

En général, implémentez toujours des fonctionnalités de sécurité de base de données comme l'authentification et le chiffrement. Restez à jour avec les derniers correctifs. Et assurez-vous d'effectuer des audits réguliers du code et des configurations pour identifier et corriger cette vulnérabilité et d'autres.

Deuxième : Laisser des fonctions de débogage dangereuses dans le code (vulnérabilité du code : SAST)

Les fonctions de débogage exposées permettent la reconnaissance, aidant les attaquants à exploiter les systèmes — parfois avec un risque de sécurité significatif.

Que sont les fonctions de débogage dangereuses ?

Les fonctions de débogage comme phpinfo() peuvent exposer des informations sensibles concernant votre serveur et votre environnement. Cela inclut la version de PHP, les détails du système d'exploitation, les informations du serveur, et même les variables d'environnement qui pourraient contenir des clés secrètes (bien que nous ne recommandions absolument pas d'y placer des clés secrètes en premier lieu !).

En conséquence, la détection de la structure de votre système de fichiers via ces fonctions de débogage pourrait permettre aux hackers de mener des attaques de 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 légèrement faciliter la tâche des attaquants. Le principe est clair : moins les hackers ont d'informations spécifiques sur votre système, mieux c'est.

Pourquoi cette vulnérabilité est-elle si courante ?

Cette vulnérabilité de sécurité des applications web survient souvent parce que les développeurs utilisent ces fonctions pour le débogage et les poussent parfois même en production pour le dépannage. Les livraisons précipitées, le manque de code review et la sous-estimation des risques contribuent tous à ce que ces fonctions restent exposées.

Comment pouvez-vous facilement corriger cette vulnérabilité ?

• Code review : vérifiez régulièrement votre code pour identifier et supprimer les fonctions de débogage avant le déploiement en production.
• Outils automatisés d'analyse de vulnérabilités : utilisez un outil, comme Aikido, capable de détecter les fonctions de débogage dangereuses.
• Configurations spécifiques à l'environnement : assurez-vous de désactiver les fonctions de débogage dans l'environnement de production.

2. La vulnérabilité DAST la plus courante et la plus critique

Les Tests de sécurité des applications dynamiques (DAST) sont une technique de test qui identifie les vulnérabilités dans les applications en cours d'exécution. On l'appelle méthode de la boîte noire (black-box) car elle se concentre uniquement sur le comportement observable. Le DAST vous montre ce à quoi le système pourrait ressembler pour un attaquant.

Oubli des en-têtes de sécurité majeurs : HSTS et CSP (vulnérabilité du cloud : DAST)

Un manque de mise en œuvre adéquate de HSTS et CSP rend les applications web vulnérables à des attaques majeures comme 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 aide à contrer diverses attaques basées sur le navigateur, telles que le cross-site scripting et le clickjacking. Elle y parvient en restreignant les comportements risqués dans les pages web, tels que le JavaScript en ligne et les fonctions eval() non sécurisées. La CSP impose des valeurs par défaut plus sûres pour maintenir 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 courante ?

Il est très courant de négliger HSTS et CSP, en particulier CSP, et les développeurs privilégient souvent la fonctionnalité à ces en-têtes.

Le CSP devrait être planifié tôt dans le 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 crée des conflits, ils ignorent donc entièrement le CSP pour passer à d'autres tâches. Cela laisse les applications non protégées et sujettes à une série de vulnérabilités de sécurité des applications web.

Comment pouvez-vous facilement corriger cette vulnérabilité DAST ?

• Implémenter HSTS pour forcer les connexions HTTPS uniquement. Activer sur le serveur via des fichiers de configuration ou un WAF.
• Définissez et appliquez une CSP stricte adaptée à votre application en restreignant les pratiques non sécurisées comme les scripts inline. Testez attentivement la compatibilité.
• Surveillez et mettez à jour en continu les headers à mesure que l'application évolue pour maintenir la protection.

3. La vulnérabilité du cloud la plus courante et la plus critique (CSPM)

Les outils de Cloud Security Posture Management (CSPM) surveillent en permanence les environnements basés sur le cloud pour garantir la conformité aux normes de sécurité et aux meilleures pratiques. Les outils CSPM recherchent les configurations de sécurité inadéquates et visent à atténuer les risques.

Laisser les rôles IAM EC2 vulnérables aux attaques SSRF (cloud : CSPM)

Les rôles IAM EC2 ouverts peuvent fréquemment permettre aux attaquants de se déplacer latéralement et d'obtenir un accès non autorisé dans les environnements cloud. L'impact potentiel de ce type d'attaque peut être dévastateur.

Que sont les rôles IAM EC2 ?

Les rôles IAM (Identity and Access Management) EC2 dans Amazon Web Services (AWS) délèguent des autorisations pour déterminer les actions autorisées sur des ressources spécifiques. Ils permettent aux instances EC2 d'interagir de manière sécurisée avec d'autres services AWS sans avoir à stocker les identifiants directement sur les instances elles-mêmes.

Qu'est-ce qu'une attaque SSRF ?

Une attaque par Server Side Request Forgery (SSRF) est une attaque où un attaquant force le serveur à effectuer des requêtes vers des ressources internes comme si c'était le serveur lui-même qui les demandait. L'attaquant peut potentiellement accéder à des systèmes non autorisés de cette manière, contourner les 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 d'e-mail.

Pourquoi cette vulnérabilité CSPM est-elle si courante ?

Les rôles IAM EC2 sont généralement laissés vulnérables aux attaques SSRF en raison de configurations de sécurité inadéquates ou de rôles trop permissifs. Gérer des permissions cloud complexes est difficile et certains développeurs pourraient ne pas comprendre pleinement les risques. De plus, le désir que les services fonctionnent harmonieusement ensemble peut souvent inciter les équipes à accorder plus d'accès que nécessaire.

Comment pouvez-vous facilement corriger cette vulnérabilité CSPM ?

Il existe des moyens efficaces de gérer les rôles EC2 et d'atténuer les vulnérabilités de sécurité des applications web SSRF. Tout d'abord, respectez le principe du moindre privilège : n'accordez que l'accès strictement nécessaire, et rien de plus. Des rôles trop permissifs sont une source de problèmes.

Ensuite, utilisez les outils AWS intégrés tels que les groupes de sécurité et les ACL réseau pour verrouiller le trafic et réduire les ouvertures potentielles aux 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 détecter tout accès inutile qui pourrait s'introduire au fil du temps à mesure que les choses évoluent. Restez vigilant.

Enfin, implémentez 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 cause : Runtimes lambda cloud obsolètes (cloud : CSPM)

Lorsque ces environnements d'exécution deviennent obsolètes, ils peuvent exposer les fonctions lambda aux attaquants.

Que sont les runtimes Lambda obsolètes ?

Les runtimes lambda obsolètes désignent l'utilisation d'anciennes versions de langages de programmation ou d'environnements dans les fonctions serverless (lambdas). Ces runtimes obsolètes peuvent manquer des derniers correctifs de sécurité ou mises à jour de fonctionnalités, exposant potentiellement les applications à des vulnérabilités de sécurité des applications web connues.

Pourquoi cette vulnérabilité CSPM est-elle si courante ?

La vulnérabilité découle souvent d'une mentalité du « déployer et oublier ». Les développeurs peuvent déployer des lambdas avec un runtime spécifique et négliger de les mettre à jour à mesure que de nouvelles versions sont publiées. Ils peuvent également commettre l'erreur de supposer que les fournisseurs cloud gèrent toute la maintenance. Même si AWS et Google Cloud Functions maintiendront les runtimes pour vous avec des correctifs mineurs du système d'exploitation, ils n'effectueront pas de mises à niveau majeures des langages. En plus de tout cela, la complexité de la gestion de multiples lambdas fait qu'il est facile pour les runtimes obsolètes de passer inaperçus et de créer un risque supplémentaire.

Comment pouvez-vous facilement corriger cette vulnérabilité CSPM ?

Vous pouvez atténuer le risque en suivant trois règles simples :

• Examinez régulièrement les runtimes utilisés et vérifiez les mises à jour.
• Mettez à niveau vers les dernières versions prises en charge avec des 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 de sécurité des applications web et bonnes pratiques

Comprendre ces vulnérabilités de sécurité des applications web est essentiel pour la sécurité des systèmes, mais n'oubliez pas de suivre les meilleures pratiques de sécurité. Restez à jour, appliquez les correctifs appropriés et maintenez une surveillance régulière pour garantir la sécurité de votre environnement.

Scannez votre environnement avec Aikido dès maintenant pour savoir si vous êtes exposé à l'une de ces vulnérabilités.

Découvrez la checklist de sécurité 2024 d'Aikido pour les CTO SaaS afin d'obtenir des conseils concis sur plus de 40 façons d'améliorer la sécurité de vos équipes, processus, code, infrastructure, et plus encore.