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 sera jamais parfaite, mais vous pouvez faire en sorte qu'elle soit meilleure demain qu'elle ne l'était 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 rassemblé une poignée de projets open-source dans un pipeline CI/CD ou des crochets de commit Git et que vous espériez le meilleur, votre boîte à outils ne peut pas vous aider à voir :
- Comment votre application peut être vulnérable en raison de pratiques de programmation moins qu'idéales, de dépendances non sécurisées, etc.
- Où les vulnérabilités se cachent très probablement, jusqu'à des LOC uniques ou des entrées dans votre système de gestion de la sécurité.
package.jsonfichier. - Pourquoi vous devez corriger certaines vulnérabilités immédiatement et pourquoi d'autres sont moins prioritaires.
Aikido existe pour rendre la sécurité des applications pertinente et efficace pour les développeurs qui ont besoin d'appliquer les bons correctifs de sécurité rapidement et de retourner à la livraison du code. Tout comme nous le faisons dans notre plateforme de sécurité centrée sur le développeur, 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 d'éducation.
- Une réponse concise à la question "Est-ce que cela me concerne ?" avec un oui ou un non clair (✅ ou 🙅) et une brève explication.
- Des conseils rapides en réponse à la question "Comment puis-je résoudre ce problème ?" qui n'impliquent pas d'outils coûteux ou de refontes onéreuses.
#1 : Injection SQL && Injection NoSQL
TL;DR : Cette vulnérabilité classique est rendue possible par une entrée utilisateur non nettoyée et non validée, ce qui permet aux attaquants d'exécuter des requêtes directement dans votre base de données. À partir de là, ils peuvent extraire des données, modifier des enregistrements ou les supprimer à volonté, ce qui annule complètement toutes les autres mesures de sécurité que vous avez mises en place pour votre application.
Cela me concerne-t-il ?
- ✅ si votre application interagit à tout moment avec une base de données SQL ou NoSQL. Les attaques par injection existent depuis des décennies, et les attaques automatisées commenceront immédiatement à sonder vos points de terminaison avec des exploits courants.
- 🙅 si vous n'avez pas de contenu dynamique basé sur des enregistrements de base de données. Cela peut être dû au fait que vous êtes entièrement côté client, que vous utilisez un générateur de site statique (SSG) ou que vous effectuez un rendu côté serveur avec une base de données mais que vous n'acceptez jamais d'entrées de la part des utilisateurs.
Comment y remédier ? Avant toute chose, il convient d'assainir et de valider toutes les données saisies par l'utilisateur afin d'éliminer les caractères ou les chaînes de caractères indésirables. Utilisez des bibliothèques et des frameworks open-source qui permettent des requêtes paramétrées, et ne concaténé jamais l'entrée utilisateur dans une requête de base de données. Si vous utilisez Node.js, pensez à 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 : Les scripts intersites (XSS)
TL;DR : XSS est une autre attaque par injection qui permet à un attaquant d'envoyer un script malveillant à une autre personne, ce qui peut permettre de recueillir ses informations d'authentification ou des données confidentielles.
Cela me concerne-t-il ?
- ✅ si votre application accepte les données de l'utilisateur et les restitue ailleurs sous forme de contenu dynamique.
- 🙅 si vous n'acceptez aucune entrée de la part de l'utilisateur.
Comment le réparer ? Comme pour les attaques par injection SQL/NoSQL, vous devez valider les données saisies par l'utilisateur lorsque vous les incluez dans la chaîne de caractères href des balises d'ancrage pour s'assurer que le protocole n'est pas utilisé. javascript. Soyez prudent lorsque vous utilisez des méthodes JavaScript telles que innerHTML ou de React dangereusementSetInnerHTMLqui peut exécuter arbitrairement n'importe quel code intégré dans la chaîne pendant la sortie. Quelle que soit votre approche, désinfectez la sortie HTML à l'aide d'outils de désinfection open-source tels que DOMPurify pour n'envoyer à vos utilisateurs que du HTML propre et non exécutable.
#3 : Falsification de requête côté serveur (SSRF)
TL;DR : Les attaques SSRF se produisent lorsqu'un acteur malveillant abuse de votre application pour interagir avec son réseau sous-jacent, l'exploitant comme un proxy pour accéder à des services potentiellement plus vulnérables ou plus lucratifs.
Cela me concerne-t-il ?
- si votre application s'interface avec un autre service ou API qui effectue une opération spécifique avec les données de l'utilisateur, même si vous avez utilisé des listes d'autorisations pour restreindre le trafic entre des points d'extrémité connus et fiables.
- 🙅 si vous êtes vraiment statique.
Comment y remédier ? Bien qu'une expression rationnelle pour valider les adresses IP ou les noms d'hôtes soit un bon début, elle est généralement sujette à des contournements tels que l'encodage octal. Deux solutions plus fiables sont d'utiliser une liste d'autorisation et l'analyseur d'URL natif de votre plateforme pour restreindre l'entrée aux seuls hôtes sûrs et connus, et de désactiver les redirections dans les requêtes de récupération. En fonction de votre plateforme, vous pouvez également vous appuyer sur des projets open-source, comme ssrf-req-filter pour Node.js, pour refuser correctement les requêtes adressées à des hôtes internes.
#4 : Traversée de chemin
TL;DR : Cette faille de sécurité permet aux attaquants d'accéder aux fichiers et aux répertoires de votre serveur web en référençant les fichiers à l'aide de la fonction ../ ou même des chemins d'accès absolus. En utilisant des tactiques sournoises comme le double encodage, les attaquants peuvent utiliser des hiérarchies de dossiers et de fichiers spécifiques au cadre ou des noms de fichiers communs pour trouver des informations précieuses.
Cela me concerne-t-il ?
- ✅. Votre application fonctionne sur un serveur web et inclut des références au système de fichiers - il n'est pas possible de contourner ce problème.
Comment y remédier ? La première étape consiste à supprimer du répertoire racine de votre serveur web tous les fichiers sensibles, comme ceux qui contiennent des variables d'environnement ou des secrets, et à mettre en place une procédure visant à prévenir d'autres dérapages.
de ne jamais stocker de fichiers sensibles, tels que 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 accessible au public, comme le dossier /statique et /public dossiers d'un Projet Next.js. Enfin, les bandes ../ les séparateurs de chemin et leurs variantes codées à partir des données de l'utilisateur.
Runtime fonctionne également très bien pour la traversée des chemins... c'est tout dire.
#5 : Injection d'entité eXterne XML (XXE)
TL;DR : Les attaques XXE exploitent une faiblesse des analyseurs XML qui permet à des entités externes, référencées par une définition de type de document (DTD), d'être récupérées et traitées sans validation ni assainissement. Le type et la gravité de l'attaque sont limités principalement par les compétences de l'attaquant et par les autorisations et la sécurité du système d'exploitation de votre fournisseur d'infrastructure.
Cela me concerne-t-il ?
- ✅ si vous analysez XML pour quelque raison que ce soit, y compris les flux d'authentification unique utilisant SAML.
- 🙅 si vous n'avez pas à gérer le XML dans votre application !
Comment résoudre ce problème ? Désactivez la résolution des DTD externes dans votre analyseur XML. Vous ne pouvez probablement pas refuser complètement les DTD, car il est normal que certaines charges utiles XML en contiennent, mais ne laissez pas votre analyseur XML faire quoi que ce soit avec elles.
#6 : Désérialisation
TL;DR : Les attaquants peuvent envoyer des données malveillantes par le biais d'une fonction de désérialisation intégrée à votre application (comme unserialize() de node-serialize) pour exécuter du code à distance, lancer un déni de service ou même créer un reverse shell.
Cela me concerne-t-il ?
- ✅ si votre application désérialise des données directement à partir de l'interaction avec l'utilisateur ou par le biais de fonctions/services d'arrière-plan comme les cookies, les formulaires HTML, les API tierces, la mise en cache, et plus encore.
- 🙅 si vous utilisez une application entièrement statique sans aucun des éléments ci-dessus.
Comment y remédier ? En général, évitez de désérialiser les données d'entrée de l'utilisateur (c'est-à-dire les données non fiables). Si vous devez le faire, n'acceptez que les données provenant d'utilisateurs authentifiés et autorisés sur la base de signatures, de certificats et de fournisseurs d'identité de confiance.
#7 : Injection de Shell/injection de commande
TL;DR : Votre application transmet les données de l'utilisateur directement au shell sous-jacent du système d'exploitation sur lequel votre serveur web et votre application s'exécutent, ce qui permet 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 basculer vers un autre système.
Cela me concerne-t-il ?
- ✅ si votre application interagit directement avec le système de fichiers ou l'interpréteur de commandes, comme une commande UNIX telle que
chat. - 🙅 si vous utilisez déjà une API ou une méthode du 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/le shell, comme dans un SSG.
Comment le réparer ? Évitez d'accepter les données de l'utilisateur directement dans les commandes ou de les appeler directement. Utilisez plutôt l'API/méthode de votre framework, comme child_process.execFile() dans Node.js, qui vous permet de passer des arguments dans une liste de chaînes. Même avec cette protection, exécutez toujours vos applications avec le minimum de privilèges nécessaires pour la logique métier requise, afin d'empêcher un attaquant de "s'échapper" du serveur web et d'accéder aux éléments suivants racine-uniquement des dossiers et des fichiers.
Et oui, nous sommes de retour pour un dernier rappel amical à ajouter Temps d'exécution à n'importe quel projet Node.js en une seule commande (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) pour protéger instantanément votre application contre les attaques courantes par injection de commandes ou de shell.
#8 : Inclusion de fichiers locaux (LFI)
TL;DR : Les attaques LFI consistent à tromper votre application en exposant ou en exécutant des fichiers sur le système qui exécute votre serveur web, ce qui permet aux attaquants d'extraire des informations ou d'exécuter du code à distance. Alors que la traversée de chemin ne permet aux attaquants que de lire des fichiers, les attaques LFI exécutent ces fichiers à l'intérieur de votre application, ce qui vous expose à une liste de vulnérabilités de sécurité telles que l'exécution de code à distance (RCE).
Cela me concerne-t-il ?
- ✅ si votre application utilise le chemin d'un fichier comme entrée utilisateur.
- 🙅 si votre application ne demande pas aux utilisateurs de fournir des chemins d'accès pour effectuer une action.
Comment le réparer ? Vérifiez toujours les entrées de l'utilisateur afin d'éviter les méthodes de traversée de chemin évoqué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 les fichiers "sûrs" de type /public ou /statique utilisez une liste de noms de fichiers et d'emplacements que votre application est autorisée à lire et à exécuter.
#9 : Prototype de pollution
TL;DR : Le présent Vulnérabilité spécifique à JavaScript permet à un attaquant de manipuler les objets globaux de votre application à l'aide de la fonction __proto__. Le nouvel objet est ensuite hérité dans l'ensemble de votre application, ce qui peut leur donner accès à des données confidentielles ou accroître leurs privilèges.
Cela me concerne-t-il ?
- ✅ si vous utilisez JavaScript.
- 🙅 si vous utilisez autre chose que JavaScript !
Comment le réparer ? Commencez par assainir les clés à partir des entrées utilisateur à l'aide de listes d'autorisations ou d'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 la fonction --disable-proto=delete offert avec Node.js.
#10 : Redirections ouvertes
TL;DR : Dans ce vecteur courant d'hameçonnage, les attaquants créent une URL personnalisée telle que https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com pour tromper votre application et rediriger les utilisateurs peu méfiants vers un site web malveillant. En outre, les attaquants peuvent enchaîner les redirections avec d'autres vulnérabilités pour obtenir un impact encore plus important, conduisant à des prises de contrôle de comptes et bien plus encore.
Cela me concerne-t-il ?
- ✅ si votre application redirige les utilisateurs vers une autre page/vue après avoir effectué une action, par exemple en les envoyant à
exemple.app/dashboardaprès une authentification réussie. - 🙅 si vous vivez encore cette vie statique.
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 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 risque de dégrader légèrement l'expérience de l'utilisateur, mais il s'agit d'un compromis valable pour améliorer la sécurité de l'application, et non pas d'un compromis qui laisse les utilisateurs vous blâmer pour les dépenses étranges figurant 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 par 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 toutes ces vulnérabilités possibles. Les attaques par injection SQL existent à elles seules depuis des décennies, et les gens continuent de trouver des CVE dans des applications, des frameworks et des bibliothèques sophistiqués. Cela ne veut pas dire que vous devez prendre ces problèmes de sécurité avec un grain de sel - si votre projet répond aux ✅ de l'un de ces 10 principaux problèmes de sécurité des applications, vous devez commencer à prendre des mesures.
Tout d'abord, inscrivez-vous à Aikido pour commencer à vous concentrer sur les véritables menaces qui pèsent sur la sécurité de votre application. En deux minutes, et gratuitement, vous pouvez analyser les référentiels et obtenir des détails pertinents ainsi que des remèdes guidés pour les vulnérabilités les plus critiques en fonction de l'architecture spécifique de votre application et des fonctionnalités, fonctions et bibliothèques d'aide que vous avez mises en œuvre. Avec Aikido, vous réduirez le champ d'application à ce qui est important et mettrez en œuvre des correctifs intelligents plus rapidement, tout en étant informé instantanément des nouveaux problèmes de sécurité introduits dans vos derniers commits.
Ensuite, ajoutez Runtime, notre moteur de sécurité intégré 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 d'application web ou des plateformes de gestion de la sécurité des applications basées sur des agents. Runtime vous donne l'assurance que votre application et vos utilisateurs sont à l'abri de ces problèmes de sécurité courants, mais il peut également transmettre 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 partez maintenant du bon pied, avec une vision plus claire de la situation :
- Les vulnérabilités de votre application sont plus nombreuses que vous ne le pensiez.
- Où vous devez concentrer votre temps et votre attention pour résoudre d'abord les problèmes les plus critiques.
- Pourquoi la sécurité des applications et l'analyse des vulnérabilités ne sont pas un effort ponctuel, mais un processus continu, rendu beaucoup plus facile grâce à l'Aïkido.
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
