Top 10 des problèmes de sécurité des applications et comment vous protéger

Vous savez que votre dernière application web est intrinsèquement vulnérable à toutes sortes d'attaques. Vous savez également que la sécurité des applications ne peut jamais être parfaite, mais vous pouvez l'améliorer demain par rapport à hier.

Le problème est que, que vous utilisiez des outils de sécurité de niveau entreprise (c'est-à-dire coûteux et complexes), ou que vous ayez assemblé une poignée de projets open source dans un pipeline CI/CD ou des hooks de commit Git en espérant le meilleur, votre boîte à outils ne peut pas vous aider à voir :

• Comment votre application pourrait être vulnérable en raison de pratiques de programmation sous-optimales, de dépendances non sécurisées, et au-delà.
• Où les vulnérabilités se cachent très probablement, jusqu'à des lignes de code uniques (LOCs) ou des entrées dans votre package.json fichier.
• Pourquoi vous devriez corriger certaines vulnérabilités immédiatement et pourquoi d'autres sont de moindre priorité.

Aikido existe pour rendre la sécurité des applications pertinente et efficace pour les développeurs qui doivent appliquer rapidement les bonnes corrections de sécurité et revenir à la livraison de code. Tout comme nous le faisons dans notre plateforme de sécurité centrée sur les développeurs, nous allons réduire le bruit autour des vulnérabilités courantes et nous concentrer sur trois détails essentiels :

• Le TL;DR, qui vous en apprendra juste assez pour avoir peur… et les bons mots-clés pour poursuivre votre recherche éducative.
• Une réponse concise à la question, “Est-ce que cela m'affecte ?” avec un oui ou un non clair (✅ ou 🙅) et une brève explication.
• Conseils rapides en réponse à « Comment puis-je le corriger ? » qui n'impliquent pas d'outils coûteux ou de refactorisations onéreuses.

#1 : SQL injection && NoSQL injection

En bref : Cette vulnérabilité classique est rendue possible par des entrées utilisateur non assainies et non validées, ce qui permet aux attaquants d'exécuter des requêtes directement sur votre base de données. À partir de là, ils peuvent extraire des données, modifier des enregistrements ou les supprimer à volonté, annulant complètement toutes les autres mesures de sécurité des applications que vous avez mises en place.

Est-ce que cela m'affecte ?

• ✅ si votre application interagit avec une base de données SQL ou NoSQL à un moment donné. Les attaques par injection existent depuis des décennies, et les attaques automatisées commenceront immédiatement à sonder vos points d'accès avec des exploits courants.
• 🙅 si vous n'avez aucun contenu dynamique basé sur des enregistrements de base de données. Cela peut être parce que vous êtes entièrement côté client, utilisant un générateur de site statique (SSG), ou effectuant un rendu côté serveur avec une base de données sans jamais accepter d'entrée des utilisateurs.

Comment y remédier ? Tout d'abord, nettoyez et validez toutes les entrées utilisateur pour éliminer les caractères ou chaînes indésirables. Tirez parti des bibliothèques et frameworks open source qui permettent les requêtes paramétrées, et ne concaténez jamais les entrées utilisateur dans une requête de base de données. Si vous utilisez Node.js, envisagez notre moteur de sécurité open source Runtime, qui vous protège de manière autonome contre les attaques par injection SQL/NoSQL et bien plus encore.

#2: cross-site scripting (XSS)

En bref : Le XSS est une autre attaque par injection qui permet à un attaquant d'envoyer un script malveillant à un autre utilisateur, pouvant potentiellement collecter ses identifiants d'authentification ou des données confidentielles.

Est-ce que cela m'affecte ?

• ✅ si votre application accepte les entrées utilisateur et les affiche ailleurs comme contenu dynamique.
• 🙅 si vous n'acceptez aucune entrée utilisateur.

Comment le résoudre ? Comme pour les attaques par injection SQL/NoSQL, vous devriez valider les entrées utilisateur lorsque vous incluez ces entrées dans le href attribut des balises d'ancrage pour s'assurer que le protocole n'est pas javascriptSoyez vigilant lors de l'utilisation de méthodes JavaScript telles que innerHTML ou de React dangerouslySetInnerHTML, qui peut exécuter arbitrairement tout code intégré dans la chaîne lors de la sortie. Quelle que soit votre approche, nettoyez la sortie HTML avec des nettoyeurs open source comme DOMPurify pour n'envoyer que du HTML propre et non exécutable à vos utilisateurs.

#3 : Server-side request forgery (SSRF)

En bref : Les attaques SSRF (Server-Side Request Forgery) se produisent lorsqu'un acteur malveillant abuse de votre application pour interagir avec son réseau sous-jacent, l'utilisant comme un proxy pour accéder à des services potentiellement plus vulnérables ou lucratifs.

Est-ce que cela m'affecte ?

• ✅ si votre application s'interface avec un autre service ou une autre API qui effectue une opération spécifique avec les données utilisateur, même si vous avez utilisé des listes blanches pour restreindre le trafic entre des points d'accès connus et fiables uniquement.
• 🙅 si vous êtes vraiment statique.

Comment y remédier ? Bien qu'une expression régulière pour valider les adresses IP ou les noms d'hôte soit un bon début, elle est généralement sujette à des contournements comme l'encodage octal. Deux solutions plus fiables consistent à utiliser une liste blanche et l'analyseur d'URL natif de votre plateforme pour restreindre les entrées aux hôtes sûrs et connus uniquement, et à désactiver les redirections dans les requêtes fetch. Selon votre framework, vous pouvez également tirer parti de projets open source – comme ssrf-req-filter pour Node.js – pour refuser correctement toute requête vers des hôtes internes.

#4 : Traversal de chemin

TL;DR : Cette faille de sécurité permet aux attaquants d'accéder aux fichiers et répertoires sur votre serveur web en référençant des fichiers via ../ séquences ou même des chemins absolus. En utilisant des tactiques sournoises comme le double encodage, les attaquants peuvent exploiter les hiérarchies dossier-fichier spécifiques aux frameworks ou les noms de fichiers courants pour trouver des informations précieuses.

Est-ce que cela m'affecte ?

• ✅. Votre application s'exécute sur un serveur web et inclut des références au système de fichiers — impossible de contourner cela.

Comment y remédier ? Votre première étape consiste à supprimer tout fichier sensible, tel que ceux contenant des variables d'environnement ou des secrets, du répertoire racine de votre serveur web, et à établir un processus pour éviter de nouvelles erreurs.

est de ne jamais stocker de fichiers sensibles, comme ceux contenant des variables d'environnement ou des secrets, dans le répertoire racine de votre serveur web. De même, ne stockez pas ces fichiers dans un dossier destiné à être publiquement accessible, comme le /static et /public dossiers d'un Projet Next.js. Enfin, supprimez ../ séparateurs de chemin et leurs variantes encodées à partir de l'entrée utilisateur.

Runtime fonctionne aussi incroyablement bien pour le path traversal… pour information.

#5 : XML eXternal Entity (XXE) injection

En bref : Les attaques XXE (XML External Entity) exploitent une faiblesse dans les parseurs XML qui permet de récupérer et de traiter des entités externes, référencées par une définition de type de document (DTD), sans validation ni assainissement. Le type et la gravité de l'attaque sont principalement limités par les compétences de l'attaquant et les mesures de sécurité/permissions au niveau du système d'exploitation de votre fournisseur d'infrastructure.

Est-ce que cela m'affecte ?

• ✅ si vous analysez du XML pour quelque raison que ce soit, y compris les flux d'authentification par authentification unique (SSO) utilisant SAML.
• 🙅 si vous n'avez pas à gérer de XML dans votre application !

Comment y remédier ? Désactivez la résolution de DTD externes dans votre analyseur XML. Vous ne pouvez probablement pas refuser entièrement les DTD, car il est normal que certaines charges utiles XML en contiennent – assurez-vous simplement que votre analyseur XML n'en fait rien.

#6 : Désérialisation

TL;DR : Les attaquants peuvent envoyer des données malveillantes via une fonction de désérialisation intégrée à votre application (comme unserialize() de node-serialize) pour exécuter du code à distance, lancer une attaque par déni de service, ou même créer un reverse shell.

Est-ce que cela m'affecte ?

• ✅ si votre application désérialise des données directement à partir d'une interaction utilisateur ou via des fonctions/services d'arrière-plan comme les cookies, les formulaires HTML, les API tierces, la mise en cache, et plus encore.
• 🙅 si vous exécutez une application entièrement statique sans aucune des conditions ci-dessus.

Comment y remédier ? En général, évitez de désérialiser les données d'entrée utilisateur (c'est-à-dire non fiables). Si vous devez le faire, n'acceptez ces données que d'utilisateurs authentifiés et autorisés, en vous basant sur des signatures, des certificats et des fournisseurs d'identité de confiance.

#7 : Shell injection / command injection

En bref : Votre application transmet directement les entrées utilisateur au shell sous-jacent du système d'exploitation sur lequel votre serveur web et votre application s'exécutent, permettant aux attaquants d'exécuter des commandes arbitraires ou de parcourir le système de fichiers, souvent avec des privilèges suffisants pour extraire des données ou pivoter vers un autre système.

Est-ce que cela m'affecte ?

• ✅ si votre application interagit directement avec le système de fichiers ou le shell, comme une commande UNIX telle que cat.
• 🙅 si vous utilisez déjà une API ou une méthode de framework pour passer en toute sécurité des arguments à la commande que vous devez exécuter, ou si vous n'avez pas besoin d'interagir avec le système de fichiers/shell, comme dans un SSG.

Comment le résoudre ? Évitez d'accepter directement les entrées utilisateur dans les commandes ou de les appeler directement. Utilisez plutôt l'API/méthode de votre framework, comme child_process.execFile() en Node.js, qui permet de passer des arguments dans une liste de chaînes de caractères. Même avec cette protection, exécutez toujours vos applications avec les privilèges les moins élevés nécessaires à la logique métier requise afin d'empêcher un attaquant de « s'échapper » du serveur web et d'accéder à root-uniquement les dossiers et les fichiers.

Et oui, nous sommes de retour pour un dernier rappel amical d'ajouter Runtime à tout projet Node.js avec une seule commande (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) pour protéger instantanément votre application contre les attaques courantes d'injection shell/commande.

#8 : Local file inclusion (LFI)

En bref : Les attaques LFI (Local File Inclusion) consistent à tromper votre application pour qu'elle expose ou exécute des fichiers sur le système hébergeant votre serveur web, ce qui permet aux attaquants d'extraire des informations ou d'exécuter du code à distance. Alors que le path traversal ne permet aux attaquants que de lire des fichiers, les attaques LFI exécutent ces fichiers au sein de votre application, vous exposant à une longue liste de vulnérabilités de sécurité des applications, telles que l'exécution de code à distance (RCE).

Est-ce que cela m'affecte ?

• ✅ si votre application utilise le chemin d'accès à un fichier comme entrée utilisateur.
• 🙅 si votre application ne demande pas aux utilisateurs de fournir des chemins pour effectuer une action.

Comment le résoudre ? Assainissez toujours les entrées utilisateur pour prévenir les méthodes de path traversal abordées ci-dessus. Si vous devez inclure des fichiers sur le système de fichiers local au-delà de ceux que l'on trouve généralement dans des répertoires « sûrs » /public ou /static dossiers, utilisez une liste blanche de noms de fichiers et d'emplacements que votre application est autorisée à lire et à exécuter.

#9 : Pollution de prototype

TL;DR : Ceci Vulnérabilité spécifique à JavaScript permet à un attaquant de manipuler les objets globaux de votre application en utilisant __proto__Le nouvel objet est ensuite hérité dans toute votre application, leur donnant potentiellement accès à des données confidentielles ou leur permettant d'escalader davantage leurs privilèges.

Est-ce que cela m'affecte ?

• ✅ si vous utilisez JavaScript.
• 🙅 si vous utilisez n'importe quoi sauf JavaScript !

Comment le résoudre ? Commencez par assainir les clés provenant des entrées utilisateur en utilisant des listes blanches ou une bibliothèque d'aide open-source. Vous pouvez étendre votre protection en utilisant Object.freeze() pour empêcher les modifications d'un prototype, ou même en utilisant le --disable-proto=delete option proposée avec Node.js.

#10 : Redirections ouvertes

TL;DR : Dans ce vecteur courant de phishing, les attaquants élaborent une URL personnalisée telle que https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com pour inciter votre application à rediriger des utilisateurs non avertis vers un site web malveillant. De plus, les attaquants peuvent enchaîner les redirections avec d'autres vulnérabilités pour un impact encore plus grand, menant à des prises de contrôle de compte et plus encore.

Est-ce que cela m'affecte ?

• ✅ si votre application redirige les utilisateurs vers une autre page/vue après avoir terminé une action, comme les envoyer vers example.app/dashboard après authentification réussie.
• 🙅 si vous êtes toujours adepte du contenu statiquement généré.

Comment y remédier ? Tout d'abord, supprimez les redirections basées sur des paramètres de votre application et remplacez-les par des redirections fixes basées sur une liste blanche de domaines et de chemins de confiance vers lesquels vous pouvez rediriger les utilisateurs après qu'ils aient effectué des actions spécifiques. Cela pourrait légèrement dégrader l'expérience utilisateur, mais c'est un compromis significatif pour une meilleure sécurité de l'application, et non un compromis qui les laisserait vous blâmer pour les dépenses étranges sur leur relevé de carte de crédit.

Quelle est la prochaine étape pour la sécurité de votre application ?

Si vous vous sentez dépassé par l'ampleur des attaques et tout le travail nécessaire pour vous en protéger, sachez que vous n'êtes pas seul.

Personne ne s'attend à ce que vous résolviez vous-même tous ces problèmes de sécurité et ces vulnérabilités potentielles. Les attaques par injection SQL existent depuis des décennies, et des CVE sont encore régulièrement découvertes dans des applications, frameworks et bibliothèques sophistiqués. Cela ne signifie pas pour autant que vous devriez prendre ces problèmes de sécurité à la légère – si votre projet coche la case ✅ pour l'un de ces 10 principaux problèmes de sécurité des applications, vous devriez commencer à agir.

Tout d'abord, inscrivez-vous à Aikido pour commencer à vous concentrer sur les menaces réelles pour la sécurité de votre application. En deux minutes, et gratuitement, vous pouvez scanner des dépôts et obtenir des détails pertinents ainsi que des remédiations guidées pour les vulnérabilités les plus critiques basées sur l'architecture spécifique de votre application et les fonctionnalités, fonctions et bibliothèques d'aide que vous avez implémentées. Avec Aikido, vous réduirez le périmètre à ce qui compte et implémenterez des correctifs intelligents plus rapidement, et serez informé instantanément des nouveaux problèmes de sécurité introduits dans vos derniers commits.

Ensuite, ajoutez Runtime, notre moteur de sécurité embarqué open source, à vos applications Node.js. Runtime protège instantanément et de manière autonome vos applications contre diverses attaques par injection, pollution de prototype et traversée de chemin en les bloquant au niveau du serveur, mais sans le coût et la complexité des pare-feu applicatifs web ou des plateformes de gestion de la sécurité des applications basées sur des agents. Runtime vous assure que votre application et vos utilisateurs sont à l'abri de ces problèmes de sécurité courants, mais peut également renvoyer des données en temps réel à Aikido pour vous donner une visibilité sur les vecteurs d'attaque actuels afin de vous aider à prioriser les correctifs.

Vous êtes maintenant sur la bonne voie, avec une vision plus claire quant à :

• Comment votre application est vulnérable de plus de façons que vous ne l'auriez imaginé.
• Où vous devriez concentrer votre temps et votre attention pour résoudre les problèmes les plus critiques en premier.
• Pourquoi la sécurité des applications et l'analyse des vulnérabilités ne sont pas un effort ponctuel, mais un processus continu — un processus rendu beaucoup plus facile avec Aikido.