Bienvenue sur notre blog.

Pourquoi êtes-vous ici ?

Vous voulez connaître la vraie réponse à deux questions sur la sécurité de Docker :

Docker est-il sûr pour une utilisation en production ?

‍Ouiet non. Docker utilise un modèle de sécurité qui repose sur les espaces de noms et l'isolation des ressources, ce qui rend les processus à l'intérieur plus sûrs contre les attaques spécifiques que l'exécution de vos applications directement à partir d'une VM cloud ou d'un système bare metal.Malgré cette couche, il existe encore de nombreux moyens pour les attaquants d'accéder à votre conteneur, ce qui leur permet de lire des informations confidentielles, d'exécuter des attaques par déni de service (DoS) ou même d'obtenir un accès racine au système hôte.

Comment puis-je améliorer ma sécurité Docker (d'une manière pas trop douloureuse) ?

‍Nousallons vous présenter les vulnérabilités les plus courantes et les plus graves de Docker, en passant outre les recommandations de base que vous trouverez partout sur Google, comme l'utilisation d'images officielles et la mise à jour de votre hôte.Au lieu de cela, nous vous conduirons directement vers les nouvelles options de Docker et les lignes de Dockerfile qui rendront votre nouveau déploiement de conteneurs Docker par défaut beaucoup plus sûr que jamais.

La liste de contrôle de sécurité de Docker (no-BS)

Rendre les systèmes de fichiers du conteneur accessibles en lecture seule

Que gagnez-vous ?

Vous empêchez un pirate de modifier l'environnement d'exécution de votre conteneur Docker, ce qui pourrait lui permettre de recueillir des informations utiles sur votre infrastructure, de collecter des données utilisateur ou de mener directement une attaque DOS ou par ransomware.

Comment le régler ?

Vous avez deux options, soit au moment de l'exécution, soit dans votre configuration Docker Compose.

Au moment de l'exécution : docker run --read-only votre-app:v1.0.1

Dans votre fichier Docker Compose :

services :
webapp :
image : your-app:v1.0.1read_only : true
...

Escalade des privilèges de verrouillage

Que gagnez-vous ?

Vous empêchez votre conteneur Docker - ou un attaquant qui s'amuse à l'intérieur dudit conteneur - d'activer de nouveaux privilèges, même au niveau racine, avec setuid ou setgid. Avec un accès plus permissif à votre conteneur, un attaquant pourrait accéder à des informations d'identification sous la forme de mots de passe ou de clés pour des parties connectées de votre déploiement, comme une base de données.

Comment le régler ?

Encore une fois, au moment de l'exécution ou dans votre configuration Docker Compose.

Au moment de l'exécution : docker run --security-opt=no-new-privileges your-app:v1.0.1

Dans votre fichier Docker Compose :

les services : 
	webapp :    
		image : your-app:v1.0.1    
		security_opt:      
			- no-new-privileges:true    
...

Isolez vos réseaux de conteneurs à conteneurs

Que gagnez-vous ?

Par défaut, Docker laisse tous les conteneurs communiquer via le réseau docker0, ce qui peut permettre à un attaquant de se déplacer latéralement d'un conteneur compromis à un autre. Si vous avez des services discrets A et B dans des conteneurs Y et ZSi les deux parties n'ont pas besoin de communiquer directement, l'isolation de leurs réseaux offre la même expérience à l'utilisateur final tout en empêchant les mouvements latéraux pour une meilleure sécurité de Docker.

Comment le régler ?

Vous pouvez spécifier les réseaux Docker au moment de l'exécution ou dans votre configuration Docker Compose. Cependant, vous devez d'abord créer le réseau :

docker network create your-isolated-network

Au moment de l'exécution, ajoutez l'élément --option réseaun : docker run --network your-isolated-network your-app:v1.0.1

Ou l'option équivalente dans votre fichier Docker Compose :

les services : 
	webapp :    
    	 image : your-app:v1.0.1    
        networks: 
        	- votre-réseau-isolé    
		...

Définir un utilisateur non-root approprié

Que gagnez-vous ?

L'utilisateur par défaut dans un conteneur est racineavec un uid de 0. En spécifiant un utilisateur distinct, vous empêchez un attaquant d'escalader ses privilèges vers un autre utilisateur qui peut agir sans restriction, comme root, ce qui annulerait toutes les autres mesures de sécurité Docker que vous avez travaillé dur pour mettre en œuvre.

Comment le régler ?

Créez votre utilisateur au cours du processus de construction ou d'exécution. Lors de l'exécution, vous pouvez soit créer l'utilisateur pour la première fois, soit remplacer la fonction UTILISATEUR que vous avez déjà défini lors de la construction.

Pendant le processus de construction, dans votre Fichier Docker:

...
RUN groupadd -r votre-utilisateur
RUN useradd -r -g votre-utilisateur votre-utilisateur
USER mon utilisateur
...

‍

Au moment de l'exécution : docker run -u votre-utilisateur votre-app:v1.0.1

Abandonner les capacités du noyau Linux

Que gagnez-vous ?

Par défaut, les conteneurs Docker sont autorisés à utiliser un ensemble restreint de fonctionnalités du noyau Linux. On pourrait penser que les gens de Docker ont créé cet ensemble restreint pour qu'il soit complètement sécurisé, mais de nombreuses capacités existent pour des raisons de compatibilité et de simplicité. Par exemple, les conteneurs par défaut peuvent arbitrairement changer la propriété des fichiers, modifier leur répertoire racine, manipuler les UID des processus et lire les sockets. En abandonnant tout ou partie de ces capacités, vous minimisez le nombre de vecteurs d'attaque.

Comment le régler ?

Vous pouvez supprimer des capacités et en définir de nouvelles au moment de l'exécution. Par exemple, vous pouvez supprimer toutes les capacités du noyau et n'autoriser votre conteneur qu'à modifier la propriété des fichiers existants.

docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1

‍

Ou pour Docker Compose :

services :
	webapp :
    	 image : your-app:v1.0.1
        cap_drop: 
        	- ALL
        cap_add: 
        	- CHOWN
        ...

Prévenir les bombes à fourchette

Que gagnez-vous ?

Les bombes à fourche sont un type d'attaque DoS qui réplique à l'infini un processus existant. Tout d'abord, ils réduisent les performances et limitent les ressources, ce qui augmente inévitablement les coûts et peut finalement faire planter vos conteneurs ou le système hôte. Une fois qu'une bombe à fourche a démarré, il n'y a pas d'autre moyen de l'arrêter que de redémarrer le conteneur ou le système hôte.

Comment le régler ?

Au moment de l'exécution, vous pouvez limiter le nombre de processus (PID) que votre conteneur peut créer.

docker run --pids-limit 99 votre-app:v1.0.1

‍

Ou avec Docker Compose :

services :
	webapp :
		image : your-app:v1.0.1
deploy
			limites:
				pids : 99

‍

Améliorez la sécurité de Docker en surveillant vos dépendances open source

Que gagnez-vous ?

Les applications que vous avez conteneurisées pour les déployer avec Docker ont probablement une large arborescence de dépendances.

Comment le régler ?

Le moyen le plus "non-BS" est l'analyse des dépendances open-source d'Aikido. Notre surveillance continue analyse les projets écrits dans plus d'une douzaine de langues en se basant sur la présence de lockfiles dans votre application et fournit une vue d'ensemble instantanée des vulnérabilités et des logiciels malveillants. Grâce au triage automatique qui filtre les faux positifs, Aikido vous donne des conseils de remédiation que vous pouvez commencer à appliquer immédiatement... et pas seulement après avoir lu une douzaine d'autres documents de référence et de problèmes GitHub.

Chez Aikido, nous aimons les projets open-source bien établis comme Trivy, Syft et Grype. Nous savons aussi par expérience que les utiliser de manière isolée n'est pas une expérience particulièrement agréable pour les développeurs. Sous le capot, Aikido améliore ces projets avec des règles personnalisées pour combler les lacunes et révéler les failles de sécurité que vous n'auriez pas pu trouver autrement. Contrairement à l'enchaînement de divers outils open-source, Aikido vous évite d'avoir à construire un script d'analyse ou à créer un travail personnalisé dans votre CI/CD.

Utiliser uniquement des images de confiance pour la sécurité de Docker

Que gagnez-vous ?

Docker Content Trust (DCT) est un système de signature et de validation du contenu et de l'intégrité des images officielles que vous tirez des registres Docker comme Docker Hub. Le fait de n'extraire que des images signées par l'auteur vous donne l'assurance qu'elles n'ont pas été modifiées pour créer des vulnérabilités dans votre déploiement.

Comment le régler ?

La méthode la plus simple consiste à définir la variable d'environnement dans votre shell, ce qui vous empêche, ainsi que toute autre personne, de travailler avec des images non fiables.

exportDOCKER_CONTENT_TRUST=1
docker run ...

Vous pouvez également définir la variable d'environnement à chaque fois que vous exécutez Docker :

DOCKER_CONTENT_TRUST=1 docker run ...

Mise à jour des durées d'exécution en fin de vie (EOL)

Que gagnez-vous ?

Une recommandation courante pour la sécurité des conteneurs Docker est d'épingler les images et les dépendances à une version spécifique au lieu de les épingler à une version spécifique. le plus récent. En théorie, cela vous empêche d'utiliser à votre insu de nouvelles images, même celles qui ont été falsifiées, qui introduisent de nouvelles vulnérabilités.

Comment le régler ?

Vous disposez de quelques projets open-source pour vous aider à découvrir les dates de fin de vie et à vous préparer au mieux. Le projet endoflife.date(dépôt GitHub) suit plus de 300 produits en regroupant des données provenant de sources multiples et en les mettant à disposition via une API publique. Quelques options s'offrent à vous avec endoflife.date et d'autres projets similaires :

• Vérifier manuellement le projet pour les mises à jour des dépendances sur lesquelles vos applications s'appuient et créer des tickets ou des problèmes pour les mises à jour nécessaires.
• Écrire un script (Bash, Python, etc.) pour obtenir les dates de fin de vie des dépendances à partir de l'API et l'exécuter régulièrement, comme une tâche cron.
• Incorporez l'API publique, ou ce script personnalisé, dans votre plateforme CI pour faire échouer les constructions qui utilisent un projet dont la fin de vie est proche ou atteinte.

En tant que développeur, nous comprenons que votre temps est précieux et souvent limité. C'est là qu'Aikido peut vous apporter un sentiment de sécurité - notre fonction d'analyse EOL suit votre code et vos conteneurs, en priorisant les runtimes ayant le plus d'impact et d'exposition, comme Node.js ou un serveur web Nginx. Comme d'habitude, nous ne nous contentons pas d'automatiser la collecte d'informations, mais nous émettons des alertes d'une sévérité appropriée pour vous informer et non vous submerger.

Limiter l'utilisation des ressources du conteneur

Que gagnez-vous ?

Par défaut, les conteneurs n'ont pas de contraintes de ressources et utilisent autant de mémoire ou de CPU que le planificateur de l'hôte. Limiter l 'utilisation des ressources d'un conteneur spécifique peut minimiser l'impact d'une attaque par déni de service. Au lieu de faire planter votre conteneur ou votre système hôte en raison d'une exception de mémoire insuffisante, l'attaque DoS en cours n'aura qu'un impact négatif sur l'expérience de l'utilisateur final.

Comment le régler ?

Au moment de l'exécution, vous pouvez utiliser la fonction --Mémoire et --cpus pour définir les limites d'utilisation de la mémoire et du processeur, respectivement. L'option memory prend des nombres avec g pour gigaoctets et m pour mégaoctets, tandis que l'option CPU reflète la limite des CPU dédiés disponibles pour le conteneur et ses processus.

docker run --memory="1g" --cpus="2" votre-app:v1.0.1

Cela fonctionne également avec Docker Compose :

services :
	webapp :
    	 image : your-app:v1.0.1
        deploy: 
            limites :
            	 cpus : '2'
                memory: 1G 
         ...

Votre dernière commande et les options de Compose pour la sécurité de Docker

Vous avez maintenant vu un certain nombre de conseils de sécurité Docker et les options CLI pertinentes ou la configuration qui les accompagne, ce qui signifie que vous êtes soit très enthousiaste à l'idée de les mettre en œuvre, soit submergé par la façon de les assembler. Ci-dessous, nous avons regroupé toutes les recommandations en une seule commande ou un seul modèle de configuration, ce qui vous aidera à déployer des conteneurs Docker plus sûrs dès maintenant.

Il est évident que vous voudrez modifier certaines options, comme le nom de l'utilisateur non root, les capacités du noyau, les limites de ressources, en fonction des besoins de votre application.

exportDOCKER_CONTENT_TRUST=1
docker run \N--Lire la suite  
    --read-only (lecture seule) \N--Security-opt=no-new-privileges (sécurité)  
   --security-opt=no-new-privileges\N--Configuration du réseau\N--Configuration du réseau \N--Sécurité 
    --network your-isolated-network \N--cap-drop ALL  
    --cap-drop ALL 
    --cap-add CHOWN \N- --pids-limit 99  
    --pids-limit 99 \N 
    --memory="1g" --cpus="2" \N-user=votre-utilisateur \N--cap-drop ALL  
    --user=votre-utilisateur \N  
    ...                 # LES AUTRES OPTIONS VONT ICI  
    votre-app:v1.0.1

Vous pouvez même créer un alias drun avec l'interpréteur de commandes de votre hôte que vous pouvez invoquer sans avoir à vous souvenir de tous ces détails.

function drun  { 
docker run \N  
    	--read-only (lecture seule) \N-security-opt=no-new-privileges (sécurité)    
       --security-opt=no-new-privileges\N--concernant le réseau de votre réseau isolé\N 
        --network your-isolated-network \N--cap-drop ALL   
        --cap-drop ALL 
        --cap-add CHOWN \N- --pids-limit 99  
        --pids-limit 99 \N 
        --memory="1g" --cpus="2" \N-user=votre-utilisateur \N--cap-drop ALL   
        --user=votre-utilisateur \N  
       $1 \ 
       $2
}

Ensuite, lancez votre alias comme suit, avec vos options et le nom de l'image : drun -it your-app:v1.0.1

Si vous êtes un adepte de Docker Compose, vous pouvez adapter toutes les mêmes options dans un nouveau modèle de base de Docker Compose à partir duquel vous pourrez travailler à l'avenir :

services :
	webapp :
    	 image : your-app:v1.0.1
        read_only: true
        security_opt:
           - no-new-privileges:true
        networks: 
           - votre-réseau-isolé
        cap_drop: 
           - ALL
        cap_add: 
           - CHOWN
        deploy: 
        	limits :
        		 pids : 9
        		 cpus: '2'
        		memory: 1G 
        ...               # D'AUTRES OPTIONS VONT ICI

Bonus : Exécuter Docker avec des conteneurs sans racine

Lorsque vous installez Docker sur un système, son démon fonctionne avec des privilèges de niveau racine. Même si vous activez toutes les options ci-dessus et que vous empêchez l'escalade des privilèges au sein d' un conteneur Docker, le reste de l'exécution du conteneur sur votre système hôte dispose toujours des privilèges root. Cela élargit inévitablement votre surface d'attaque.

La solution réside dans les conteneurs sans racine, qu'un utilisateur non privilégié peut créer et gérer. L'absence de privilèges root signifie beaucoup moins de problèmes de sécurité pour votre système hôte.

Nous aimerions pouvoir vous aider à utiliser des conteneurs sans racine avec une seule option ou commande, mais ce n'est pas si simple. Vous trouverez des instructions détaillées sur le site web Rootless Containers, y compris un guide pratique pour Docker.

Quelle est la prochaine étape pour votre sécurité Docker ?

‍

Si vous avez appris quelque chose de cette expérience, c'est que la sécurité des conteneurs est une opération de longue haleine. Il y a toujours plus de checklists de renforcement et d'articles de fond à lire sur le verrouillage de vos conteneurs dans Docker ou son cousin plus ancien et souvent mal compris, Kubernetes. Vous ne pouvez pas viser une sécurité des conteneurs sans faille - créer du temps dans votre calendrier de développement chargé pour aborder la sécurité, puis apporter des améliorations incrémentales basées sur l'impact et la gravité, vous permettra d'aller loin au fil du temps.

Pour vous aider à maximiser ce processus continu et à prioriser les correctifs qui amélioreront de manière significative la sécurité de vos applications, il y a Aikido. Nous venons de lever une série A de 17 millions de dollars pour notre plateforme de sécurité pour développeurs "no BS", et nous serions ravis que vous nous rejoigniez.

‍

Pourquoi êtes-vous ici ?

Vous avez déjà entendu parler des attaques par injection SQL de JavaScript, mais vous ne savez pas exactement à quoi elles ressemblent dans la nature ni si vous devez vous en préoccuper. Vous essayez peut-être de comprendre à quel point cela peut être grave.

En bref, si vous créez des applications utilisant des bases de données SQL, telles que MySQL et PostgreSQL, vous courez un risque : vous n'êtes pas à l'abri des méthodes d'attaque qui touchent les développeurs et leurs bases de données depuis des dizaines d'années. En tant que développeur, il vous incombe de mettre en place des garde-fous qui protègent les données des utilisateurs et garantissent que votre infrastructure sous-jacente ne fait jamais l'objet d'une intrusion, d'une exploration ou d'une réquisition.

Tous les nouveaux outils prétendent vous aider, mais ils ne font que rendre le développement plus complexe.

Vous pouvez ajouter un mappeur objet-relationnel (ORM) comme Sequelize et TypeORM pour simplifier la façon dont vous travaillez avec des bases de données SQL comme MySQL et PostgreSQL, mais ils ne vous exonèrent pas complètement du risque. Les pare-feu pour applications web (WAF) vous aident à bloquer les attaques au niveau du réseau, mais ils nécessitent une infrastructure coûteuse et une maintenance constante. Les scanners de code peuvent vous aider à identifier les failles évidentes, mais ils sont beaucoup moins efficaces pour les inconnues et les techniques de type "zero-day" qui se cachent.

Nous vous présenterons une image claire de ce à quoi ressemblent les attaques par injection SQL, du risque qu'elles comportent et des erreurs de développement qui les rendent possibles. Ensuite, nous vous accompagnerons dans l'installation d'un correctif global afin que vous sachiez, avec certitude, que vos applications sont sûres.

Attaques par injection SQL : exemples et implications

La définition la plus élémentaire d'une attaque par injection SQL est qu'une application permet à une entrée utilisateur non validée et non nettoyée d'exécuter des requêtes de base de données, ce qui permet à un attaquant de lire la base de données SQL, de modifier des enregistrements ou de les supprimer à sa guise.

Comme d'habitude, XKCD illustre le danger de SQL mieux que la plupart des scénarios sombres que nous pourrions imaginer :

À quoi ressemble une application JavaScript vulnérable ?

Commençons par un exemple de pseudocode simple : une application JavaScript avec un élément d'entrée qui permet aux utilisateurs de faire une recherche dans une base de données de chats. Dans l'exemple de code JavaScript ci-dessous, l'application répond aux requêtes POST sur le chemin /cats pour extraire l'entrée de l'utilisateur du corps de la requête et se connecte à la base de données avec une requête pour retourner tous les chats avec un identifiant correspondant. L'application affiche ensuite le chat à l'aide de la réponse JSON.

app.post("/cats", (request, response) => {
	const query = `SELECT * FROM cats WHERE id = ${request.body.id}`;
	connection.query(query, (err, rows) => {
    	if(err) throw err;
        response.json({
        	data: rows
		});  
	});
});

Bien que cet exemple puisse sembler inoffensif pour ceux qui n'ont pas été formés aux attaques par injection SQL, il est extrêmement vulnérable. Notamment, l'application ne tente pas de valider ou d'assainir l'entrée de l'utilisateur pour les chaînes de caractères ou les méthodes d'encodage potentiellement dangereuses, etconcatène l'entrée de l'utilisateur directement dans la requête SQL, ce qui donne aux attaquants de multiples occasions d'attaquer en utilisant des méthodes d'attaque par injection SQL courantes qui existent depuis des dizaines d'années.

Exemple de charges utiles d'attaque JavaScript SQL

L'injection SQL consiste à tromper votre base de données MySQL ou PostgreSQL pour qu'elle effectue une action ou réponde avec des données en dehors du cadre prévu, en raison de la manière dont votre application génère des requêtes SQL.

Le 1=1 est toujours vrai L'attaque peut retourner toute la table des chats avec des astuces comme les apostrophes ou les guillemets, parce que 1=1 est en effet toujours VRAI :

• L'utilisateur saisit les données : BOBBY TABLES" OU 1="1
• La base de données exécute la requête SQL : SELECT * FROM Users WHERE Cat = BOBBY TABLES OR 1=1 ;

De même, les attaquants peuvent exploiter une = est toujours vrai attaque pour renvoyer tous les chats, car ""="" est toujours VRAI :

• L'utilisateur saisit les données : " OR ""="
• La base de données exécute la requête SQL : SELECT * FROM Cats WHERE CatId ="" ou ""="" ;

Les attaquants exploitent souvent la manière dont les bases de données gèrent les commentaires en ligne, et en insérant des commentaires (/* ... */) dans une requête, ils peuvent obscurcir leur intention ou contourner les filtres.

• L'utilisateur saisit les données : DR/*hello world*/OP/*sneak attack*/ TABLE Cats ;
• La base de données exécute la requête SQL : DROP TABLE Cats ;

Une autre stratégie courante d'injection SQL en JavaScript est l'empilement de requêtes, qui permet aux attaquants de commencer par une chaîne inoffensive, puis d'utiliser un point-virgule ( ;) pour mettre fin à cette déclaration et en commencer une autre contenant leur injection. Les attaquants utilisent souvent l'empilement de requêtes pour supprimer des bases de données entières d'un seul coup à l'aide d'une commande DROP TABLE :

• L'utilisateur saisit les données : Bobby ; DROP TABLE Cats --
• L'application construit sa requête SQL : const query = "SELECT * FROM Cats WHERE CatId = " + input ;
• La base de données exécute la requête SQL : SELECT * FROM Cats WHERE CatId = BOBBY ; DROP TABLE Cats ;

Qu'en est-il des attaques par injection NoSQL ?

Les attaques par injection NoSQL sont tout aussi dangereuses pour la sécurité de votre application et des données des utilisateurs, mais elles n'affectent que les piles technologiques utilisant des bases de données telles que MongoDB. La principale différence réside dans le style des attaques, car les requêtes SQL et NoSQL utilisent une syntaxe totalement unique qui ne se traduit pas d'une catégorie à l'autre.

Si vous utilisez une base de données SQL, vous ne risquez pas d'être victime d'une attaque par injection NoSQL, et vice versa.

Le chemin de base : corriger manuellement toutes les vulnérabilités d'injection SQL

À ce stade, vous êtes peut-être moins intéressé par la description de toutes les astuces d'injection possibles que par la manière de protéger les données que vous avez dans MySQL ou PostgreSQL.

• Utiliser des requêtes paramétrées: SQL dispose d'une fonctionnalité permettant de déconnecter l'exécution des requêtes et des valeurs, protégeant ainsi la base de données des attaques par injection.Avec l'exemple JavaScript/Node.js ci-dessus, vous pouvez employer un espace réservé dans votre requête SQL avec un point d'interrogation (?). Les connexion.query() prend alors le paramètre en deuxième argument, ce qui donne les mêmes résultats dans une méthode à l'épreuve des injections.

app.post("/cats", (request, response) => {  
	const query = `SELECT * FROM Cats WHERE id = ?`;  
    const value = request.body.id;  
    connection.query(query, value, (err, rows) => {    
    	if(err) throw err;    
        response.json({      
        	data: rows    
		});  
	});
});

‍

• Valider et assainir les entrées des utilisateurs: Si les requêtes paramétrées peuvent contribuer à protéger votre base de données SQL contre les intrusions et les attaques, vous pouvez également empêcher les utilisateurs de saisir des chaînes de caractères potentiellement dangereuses dans votre application.
  
  Une option consiste à ajouter à votre application des bibliothèques open-source pour l'assainissement et la validation. Par exemple, vous pouvez utiliser validator.js dans l'écosystème JavaScript/Node.js pour vérifier qu'un utilisateur essaie d'entrer une véritable adresse électronique - et non une attaque par injection SQL - dans votre formulaire d'inscription.
  
  Vous pouvez également développer des validateurs personnalisés basés sur des expressions rationnelles pour effectuer un travail similaire, mais le chemin à parcourir sera extrêmement long et complexe, avec des recherches et des tonnes de tests manuels. De plus, pouvez-vous vraiment interpréter cet exemple de regex pour la validation d'un courriel ?
  
  const re = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  
  La même idée s'applique pour empêcher les chaînes de caractères comme ...' OR 1-'1. Vous pouvez essayer de rechercher et de fermer toutes ces opportunités vous-même, mais vous préférerez probablement passer votre temps à créer de nouvelles fonctionnalités.

‍

• Déployer des WAF ou des plateformes de sécurité basées sur des agents: Bien que ces solutions puissent bloquer les attaques SQL avant même qu'elles ne touchent votre application, ou au moins vous avertir en temps réel lorsque des attaques se produisent, elles sont assorties de quelques mises en garde.
  
  Tout d'abord, elles sont souvent coûteuses et vous obligent à lancer une nouvelle infrastructure sur site ou dans le nuage, ce qui est souvent beaucoup plus complexe que ce que vous avez signé en tant que développeur qui veut juste expédier à la production. Deuxièmement, elles nécessitent davantage de maintenance manuelle pour mettre à jour le jeu de règles, ce qui vous empêche d'effectuer d'autres interventions manuelles en cas d'injection de code SQL. Enfin, ils ajoutent souvent une charge de calcul supplémentaire ou redirigent toutes les requêtes via leur plateforme d'analyse, ce qui augmente la latence et nuit à l'expérience de l'utilisateur final.

Le gros problème est que les possibilités d'attaques par injection SQL sont comme des mauvaises herbes - vous pouvez les couper une fois à l'aide de ces outils, mais vous devez être constamment vigilant sur l'ensemble de votre base de code pour vous assurer qu'elles ne repoussent jamais.

Une voie alternative pour résoudre les attaques JavaScript par injection SQL : Pare-feu Aikido

Aikido Security a récemment publié Firewall, un moteur de sécurité gratuit et open-source qui vous protège de manière autonome contre les attaques par injection SQL et bien d'autres choses encore.

Si vous n'utilisez pas Node.js, sachez que nous prendrons en charge d'autres langages et frameworks à l'avenir. Vous pouvez toujours vous abonner à notre bulletin d'information sur les produits pour savoir exactement quand Firewall s'étendra au-delà du monde JavaScript ou nous envoyer un courriel à hello@aikido.dev si vous souhaitez parler d'un langage spécifique.

Tester une application vulnérable à l'injection SQL JavaScipt

Nous allons utiliser un exemple d'application fourni avec le dépôt open-source pour montrer comment fonctionne Aikido Firewall. Vous aurez également besoin de Docker/DockerCompose pour déployer une base de données MySQL locale.

Commencez par forker le dépôt firewall-node et clonez ce fork sur votre station de travail locale.

git clone https://github.com/<YOUR-GITHUB-USERNAME>/firewall-node.gitcd firewall-node

Utilisez Docker pour déployer une base de données MySQL locale sur le port 27015. Ce fichier docker-compose.yml crée également des conteneurs s3mock, MongoDB et PostgreSQL, car il a été créé pour aider l'équipe d'Aikido à tester la façon dont Firewall bloque diverses attaques.

docker-compose -f sample-apps/docker-compose.yml up -d

Lancez ensuite l'application modèle :

node sample-apps/express-mysql2/app.js

Ouvrir http://localhost:4000 dans votre navigateur pour découvrir cette application très simple. Dans la zone de texte, tapez quelques noms de chats et cliquez sur le bouton Ajouter pour tester l'injection d'un code SQL. Pour tester l'injection SQL, vous pouvez soit cliquer sur le bouton Injection de test ou tapez le texte suivant dans la zone de texte : Kitty') ; DELETE FROM cats;-- H et cliquez sur Ajouter à nouveau. Quoi qu'il en soit, l'application vous permet d'empiler plusieurs requêtes à l'aide de commentaires sournois, supprimant ainsi la totalité de la base de données des chats.

Comment cela se passe-t-il ? Comme nous l'avons déjà signalé, cette application ajoute simplement tous l'entrée de l'utilisateur à la fin de la requête SQL, ce qui n'est pas sûr par nature.

const query = `INSERT INTO cats(petname) VALUES ('${name}');`

Les conséquences peuvent être minimes, mais il n'est pas difficile d'imaginer comment cette erreur souvent honnête peut avoir des conséquences désastreuses pour votre application de production.

Blocage de l'injection JavaScript SQL avec Aikido Firewall

Voyons maintenant avec quelle rapidité notre moteur de sécurité open-source bloque les attaques JavaScript par injection SQL sans avoir à corriger manuellement chaque interaction avec la base de données dans votre code.

Si vous n'avez pas encore de compte Aikido, n'hésitez pas à en créer un. en faire un gratuitement. Si vous en avez déjà un, connectez-vous et connectez votre compte GitHub. Au cours de ce processus, accordez à l'Aikido l'accès à la lecture de votre fourche de l'accord. nœud de pare-feu projet.

Aller à la page Tableau de bord du pare-feu et cliquez sur Ajouter un service. Donnez un nom à votre service et choisissez à nouveau votre fourchette pour le service nœud de pare-feu projet.

Aikido vous explique ensuite comment installer et mettre en œuvre Aikido Firewall. Comme nous utilisons l'application d'exemple, ce travail est déjà fait pour vous, mais il s'agit d'une référence utile sur la façon d'apporter notre moteur de sécurité open-source à toutes vos applications Node.js qui pourraient être vulnérables à des attaques JavaScript par injection SQL.

Cliquez sur le bouton Générer un jeton pour créer un jeton permettant à Aikido Firewall de transmettre en toute sécurité les informations sur les attaques par injection SQL bloquées à la plateforme de sécurité Aikido. Copiez le jeton généré, qui commence par AIK_RUNTIME...et retournez à votre terminal pour réexécuter l'exemple d'application, mais maintenant avec le Pare-feu entièrement activé en mode blocage :

AIKIDO_TOKEN=<YOUR-AIKIDO-TOKEN> AIKIDO_DEBUG=true AIKIDO_BLOCKING=true node sample-apps/express-mysql2/app.js

Ouvrir localhost:4000 et invoque à nouveau l'attaque par injection SQL incluse. Cette fois, Aikido vous bloquera au niveau du navigateur, enverra un message dans les journaux de votre serveur web local et générera un nouvel événement. Cliquez sur cet événement pour obtenir des détails complets sur la tentative d'injection SQL, y compris la charge utile et l'endroit où votre application a généré la dangereuse requête SQL.

Au lieu de s'inquiéter de la protection permanente de vos applications contre les attaques par injection JavaScript SQL, qu'elles soient critiques ou non, Aikido Firewall offre un blocage complet et une observabilité sophistiquée qui vous tient informé des sources d'attaque, des charges utiles courantes et des points faibles potentiels.

Quelle est la prochaine étape ?

Vous pouvez installer et mettre en œuvre Aikido Firewall dans toutes vos applications basées sur Node.js gratuitement. Notre moteur de sécurité embarqué open-source protège votre infrastructure et les données de vos utilisateurs contre les attaques JavaScript SQL injection, l'injection de commandes, la pollution des prototypes, la traversée de chemin, et bien d'autres encore à venir prochainement.

Nous ne disons pas que Firewall devrait remplacer les meilleures pratiques de développement pour se protéger contre les injections SQL, comme l'utilisation de requêtes paramétrées ou le fait de ne jamais faire confiance à la saisie de l'utilisateur, mais nous savons aussi, par expérience personnelle, qu'aucun développeur n'est parfait. Aucune base de code n'est sans faille, et des erreurs honnêtes se produisent tout le temps.

Considérez Firewall comme un correctif global pour l'injection SQL. Contrairement aux expressions rationnelles développées sur mesure, aux WAFs induisant une latence ou aux agents de sécurité complexes qui coûtent une fortune, Firewall fait ce travail extraordinairement bien et avec un impact négligeable, et ce, tout à fait gratuitement.

Si vous aimez ce que vous avez vu, consultez notre feuille de route et donnez une étoile à notre dépôt GitHub(https://github.com/AikidoSec/firewall-node). ⭐

‍

Introduction

Imaginez que vous construisiez une application web de blogging en utilisant Prisma. Vous écrivez une requête simple pour authentifier les utilisateurs sur la base de leur email et de leur mot de passe :

1const user = await prisma.user.findFirst({
2  where: { email, password },
3});

Cela semble inoffensif, n'est-ce pas ? Mais que se passe-t-il si un pirate envoie password = { "not": "" }? Au lieu de renvoyer l'objet Utilisateur uniquement lorsque l'adresse électronique et le mot de passe correspondent, la requête renvoie toujours l'objet Utilisateur lorsque seule l'adresse électronique fournie correspond.

Cette vulnérabilité est connue sous le nom d'injection d'opérateur, mais elle est plus communément appelée injection NoSQL. Ce que de nombreux développeurs ignorent, c'est qu'en dépit de schémas de modèles stricts , certains ORM sont vulnérables à l' injection d'opérateur même lorsqu'ils sont utilisés avec une base de données relationnelle telle que PostgreSQL, ce qui en fait un risque plus répandu qu'on ne le pense.

Dans ce billet, nous allons explorer le fonctionnement de l'injection d'opérateur, démontrer des exploits dans Prisma ORM, et discuter de la façon de les prévenir.

Comprendre l'injection d'opérateur

Pour comprendre l'injection d'opérateurs dans les ORM, il est intéressant d'examiner d'abord l'injection NoSQL. MongoDB a présenté aux développeurs une API permettant d'interroger les données à l'aide d'opérateurs tels que $eq, $lt et $ne. Lorsque les données de l'utilisateur sont transmises aveuglément aux fonctions d'interrogation de MongoDB, il existe un risque d'injection NoSQL.

Les bibliothèques ORM populaires pour JavaScript ont commencé à offrir une API similaire pour l'interrogation des données et maintenant presque tous les ORM principaux supportent une certaine variation des opérateurs de requête, même s'ils ne supportent pas MongoDB. Prisma, Sequelize et TypeORM ont tous implémenté le support des opérateurs de requête pour les bases de données relationnelles telles que PostgreSQL.

Exploitation de l'injection d'opérateur dans Prisma

Les fonctions de requête Prisma qui opèrent sur plus d'un enregistrement prennent généralement en charge les opérateurs de requête et sont vulnérables à l'injection. Voici quelques exemples de fonctions trouverPremier, findMany, updateMany et deleteMany. Bien que Prisma valide les champs du modèle référencés dans la requête au moment de l'exécution, les opérateurs sont une entrée valide pour ces fonctions et ne sont donc pas rejetés par la validation.

L'une des raisons pour lesquelles l'injection d'opérateurs est facile à exploiter dans Prisma est la présence d'opérateurs basés sur des chaînes de caractères dans l'API Prisma. Certaines bibliothèques ORM ont supprimé la prise en charge des opérateurs de requête basés sur des chaînes de caractères parce qu'ils sont facilement négligés par les développeurs et faciles à exploiter. Au lieu de cela, elles obligent les développeurs à référencer des objets personnalisés pour les opérateurs. Comme ces objets ne peuvent pas être facilement désérialisés à partir de l'entrée de l'utilisateur, le risque d'injection d'opération est considérablement réduit dans ces bibliothèques.

Toutes les fonctions de requête de Prisma ne sont pas vulnérables à l'injection d'opérateur. Les fonctions qui sélectionnent ou modifient un seul enregistrement de la base de données ne prennent généralement pas en charge les opérateurs et génèrent une erreur d'exécution lorsqu'un objet est fourni. En dehors de findUnique, les fonctions update, delete et upsert de Prisma n'acceptent pas non plus les opérateurs dans leur filtre where.

1  // This query throws a runtime error:
2  // Argument `email`: Invalid value provided. Expected String, provided Object.
3  const user = await prisma.user.findUnique({
4    where: { email: { not: "" } },
5  });

‍

Meilleures pratiques pour prévenir l'injection de l'opérateur

1. Conversion des données utilisateur en types de données primitives

En règle générale, il suffit de convertir les données d'entrée en types de données primitifs tels que les chaînes de caractères ou les nombres pour empêcher les attaquants d'injecter des objets. Dans l'exemple original, la conversion se présente comme suit :

1  const user = await prisma.user.findFirst({
2    where: { email: email.toString(), password: password.toString() },
3  });

2. Valider les données de l'utilisateur

Bien que le casting soit efficace, vous voudrez peut-être valider l'entrée de l'utilisateur pour vous assurer qu'elle répond aux exigences de votre logique d'entreprise.

Il existe de nombreuses bibliothèques pour la validation des données utilisateur côté serveur, telles que class-validator, zod et joi. Si vous développez pour un framework d'application web tel que NestJS ou NextJS, il est probable qu'ils recommandent des méthodes spécifiques pour la validation de l'entrée utilisateur dans le contrôleur.

Dans l'exemple original, la validation de zod pourrait se présenter comme suit :

1import { z } from "zod";
2
3const authInputSchema = z.object({
4  email: z.string().email(),
5  password: z.string().min(8)
6});
7
8const { email, password } = authInputSchema.parse({email: req.params.email, password: req.params.password});
9
10const user = await prisma.user.findFirst({
11  where: { email, password },
12});

3. Maintenez votre ORM à jour

Restez à jour pour bénéficier des améliorations et des corrections de sécurité. Par exemple, Sequelize a désactivé les alias de chaîne pour les opérateurs de requête à partir de la version 4.12, ce qui réduit considérablement la sensibilité à l'injection d'opérateur.

Conclusion

L'injection d'opérateur est une menace réelle pour les applications utilisant des ORM modernes. La vulnérabilité provient de la conception de l'API ORM et n'est pas liée au type de base de données utilisé. En effet, même Prisma combiné à PostgreSQL peut être vulnérable à l'injection d'opérateur. Bien que Prisma offre une protection intégrée contre l'injection d'opérateur, les développeurs doivent toujours pratiquer la validation et l'assainissement des entrées pour garantir la sécurité de l'application.

Annexe : Schéma Prisma pour le modèle de l'utilisateur

1// This is your Prisma schema file,
2// learn more about it in the docs: https://pris.ly/d/prisma-schema
3
4generator client {
5  provider = "prisma-client-js"
6}
7
8datasource db {
9  provider = "postgresql"
10  url      = env("DATABASE_URL")
11}
12
13// ...
14
15model User {
16  id       Int      @id @default(autoincrement())
17  email    String   @unique
18  password String
19  name     String?
20  posts    Post[]
21  profile  Profile?
22}

TL;DR : La nouvelle directive européenne sur la cybersécurité, NIS2, modifie déjà la façon dont les fournisseurs de logiciels font des affaires en imposant des exigences plus strictes en matière de gestion des vulnérabilités dans les contrats d'approvisionnement. Ce changement prend de l'ampleur et de plus en plus d'entreprises devront s'adapter. Aikido aide à automatiser les rapports de conformité et le suivi des vulnérabilités pour répondre à ces nouvelles exigences. Commencez votre voyage de conformité gratuit iciou lisez la suite pour comprendre ce que cela signifie pour votre entreprise.

Les risques liés à la non-conformité des correctifs de NIS2

Imaginez un peu : Il est 8h33, un lundi. Vous êtes en train de trier votre boîte de réception, un café à la main, vous préparant mentalement à la réunion hebdomadaire de 9 heures. C'est alors que vous le voyez - l'objet de l'e-mail qui vous retourne l'estomac.

Vous ouvrez l'e-mail, vous faites défiler les habituelles formules passe-partout jusqu'à ce que vous lisiez - et relisiez - ces mots :

Tous les composants logiciels utilisés pour la fourniture des services doivent être corrigés dans les délais suivants, en fonction de la gravité de la vulnérabilité :

- Critique : dans les 48 heures suivant la disponibilité du correctif
- Élevé : dans la semaine suivant la disponibilité du correctif
- Moyen : dans le mois suivant la disponibilité du correctif
- Faible : dans les trois mois suivant la disponibilité du correctif

48 heures pour les vulnérabilités critiques. Pas des jours ouvrables. Pas "best effort". 48. heures. C'est ainsi que votre lundi s'est transformé en Jeux olympiques de la conformité et que vous participez simultanément à toutes les épreuves.

Les nouvelles exigences de NIS2 en matière de correctifs ne sont pas une simple case à cocher - elles représentent un défi opérationnel de taille. Pensez-y :

• Votre équipe est déjà très sollicitée
• Chaque nouveau CVE donne l'impression de jouer au jeu de la sécurité.
• Vos fenêtres de déploiement sont serrées et le sont de plus en plus
• Et maintenant, vous devez documenter et prouver que vous avez respecté ces délais serrés ?

Le non-respect de ces accords de niveau de service n'est pas seulement synonyme d'échec à un audit : il peut entraîner la perte de contrats importants, des pénalités, voire l'exclusion totale des marchés de l'UE.

Mais voilà : alors que d'autres fournisseurs s'efforcent de mettre en place des programmes de conformité massifs et d'engager des équipes dédiées à NIS2, vous n'avez pas à le faire.

Comment se conformer à la norme NIS2

Nous avons construit Aikido spécifiquement pour ce moment. Notre conformité NIS2 est comme un jeu en mode facile pour ces maux de tête de l'approvisionnement. En quelques minutes, vous pouvez :

• Générer des rapports de conformité que les équipes chargées des achats acceptent réellement
• Suivez automatiquement vos accords de niveau de service en matière de vulnérabilité
• Recevez des alertes avant de dépasser les délais
• Prouver votre conformité à l'aide de données réelles, pas de promesses

Voyons ce que signifient exactement ces exigences et comment vous pouvez y répondre sans bouleverser l'ensemble de votre plan 2025.

S'inscrire à Aikido et obtenez votre rapport NIS2 gratuit en quelques minutes.

Quelles sont les exigences du NIS2 ?

NIS2 est la dernière directive de l'UE sur la cybersécurité, et elle modifie la façon dont les entreprises gèrent la gestion de la vulnérabilité. Les États membres de l'UE transposent la directive NIS2 dans leur législation nationale, en se référant souvent à des normes telles que la norme ISO 27001 comme base de mise en œuvre.

Contrairement à son prédécesseur, le NIS2 couvre davantage de secteurs et impose des exigences plus strictes, notamment en ce qui concerne la sécurité de la chaîne d'approvisionnement. Les grandes entreprises, en particulier celles des secteurs critiques, ne se contentent pas de mettre en œuvre ces exigences en interne ; elles sont tenues de les imposer à tous les fournisseurs de leur chaîne d'approvisionnement.

Lire : NIS2 : Qui est concerné ?

Qu'est-ce que cela signifie en pratique ? Si vous vendez des logiciels ou des services à des entreprises de l'UE, vous serez de plus en plus souvent confronté à des exigences en matière de passation de marchés qui ressemblent exactement à l'exemple ci-dessus. Elles exigeront des délais précis pour l'application des correctifs, une documentation détaillée sur votre processus de gestion des vulnérabilités et des rapports de conformité réguliers. Il ne s'agit pas de simples cases à cocher: les équipes chargées des achats vérifient activement la conformité et intègrent ces accords de niveau de service dans les contrats.

Les exigences les plus courantes que nous rencontrons sont les suivantes :

• Définir des accords de niveau de service pour la correction des vulnérabilités en fonction de leur gravité (l'exemple donné dans l'introduction provient d'un véritable document sur les marchés publics !)
• Analyse et rapports réguliers sur les vulnérabilités
• Processus documentés pour la gestion des vulnérabilités
• Preuve de conformité grâce à un suivi automatisé
• Mises à jour régulières de l'état d'avancement des efforts de remédiation

Exigences en matière de correction de la vulnérabilité de NIS2

Passons sur le jargon juridique et concentrons-nous sur ce que la norme NIS2 implique réellement en matière de correction des vulnérabilités. La norme NIS2 elle-même ne prescrit pas de délais spécifiques pour l'application des correctifs. En revanche, elle impose des mesures de gestion des risques, notamment le traitement et la divulgation des vulnérabilités, ce qui conduit les acheteurs de logiciels à imposer les accords de niveau de service décrits. Voici ce que les équipes chargées des achats recherchent :

Délais de réponse

La plupart des entreprises normalisent ces fenêtres de correctifs :

• Vulnérabilités critiques : 48 heures
• Gravité élevée : 7 jours
• Gravité moyenne : 30 jours
• Faible gravité : 90 jours

Et oui, ces délais commencent à partir du moment où le correctif est disponible, et non pas à partir du moment où vous le découvrez. Cela signifie que vous devez rester au courant des annonces de vulnérabilités pour chaque composant de votre pile.

Exigences en matière de documentation

Vous devrez prouver trois choses :

1. Quand avez-vous découvert chaque vulnérabilité ?
2. Quand le correctif est devenu disponible
3. Lorsque vous avez déployé le correctif

Sans suivi automatisé, cela devient rapidement un travail à plein temps pour votre équipe de sécurité.

Contrôle continu

L'époque des analyses de sécurité trimestrielles est révolue. NIS2 attend :

• Analyse régulière des vulnérabilités (la plupart des entreprises considèrent qu'il s'agit d'une analyse quotidienne)
• Surveillance des CVE pour les nouveaux avis de sécurité
• Suivi actif de l'état des correctifs et de la conformité aux accords de niveau de service

Gestion des risques

Pour chaque vulnérabilité, vous devez

• Documenter l'évaluation de la gravité
• Suivre les progrès de la remédiation
• Justifier tout retard dans les travaux de réparation
• Rapport sur le respect des accords de niveau de service convenus

C'est pourquoi nous avons développé le rapport NIS2 dans Aikido - il gère tout cela automatiquement. Au lieu de construire des feuilles de calcul et de jongler avec des tickets, vous obtenez un tableau de bord unique qui suit tout ce que les équipes d'approvisionnement veulent voir.

Mise en œuvre avec l'aïkido (étapes pratiques)

Le problème avec les cadres de conformité, c'est qu'il s'agit généralement d'un fatras de paperasserie déconnecté de vos opérations de sécurité proprement dites. Mais il n'est pas nécessaire qu'il en soit ainsi.

Imaginons qu'une équipe d'acheteurs s'enquière de votre processus de gestion de la vulnérabilité. Au lieu de vous précipiter pour créer une documentation, vous vous contentez de.. :

1. Connectez Aikido à votre pipeline de développement
2. Relier votre infrastructure en nuage
3. Activer le rapport de conformité NIS2
4. Exporter les preuves automatisées de vos calendriers de correctifs
5. Envoyez-le

C'est tout. Pas de séances de documentation interminables. Pas de feuilles de calcul. Pas de panique de dernière minute.

Ce que vous obtenez immédiatement

• Analyse continue de neuf vecteurs de risque (des dépendances à la sécurité d'exécution)
• Collecte automatisée de preuves pour vos contrôles techniques
• Statut de conformité en temps réel pour les exigences en matière de marchés publics
• Des rapports dynamiques qui correspondent directement aux exigences du NIS2

Et le plus beau, c'est qu'il fonctionne exactement là où se trouvent déjà vos développeurs. Il fonctionne exactement là où se trouvent déjà vos développeurs : dans les pipelines CI, les référentiels de code et les environnements cloud. Alors que d'autres équipes collectent manuellement des preuves pour leurs certifications ISO 27001 et leurs efforts de conformité NIS2, vous générez automatiquement des rapports de conformité à partir de vos données de sécurité réelles.

Prochaines étapes

Résumons en une phrase : il n'est pas nécessaire de mettre en place un programme de conformité massif ou d'engager une armée de consultants pour répondre aux questions de conformité à la norme NIS2. Nous recommandons l'approche stratégique suivante

1. Obtenez une image claire de votre situation (en vous inscrivant à un compte Aïkido gratuit)
2. Exécutez votre premier rapport de conformité NIS2
3. Voir exactement ce qui nécessite une attention particulière
4. Automatisez les rapports et prouvez facilement à vos clients que vous êtes prêts pour le NIS2.

Alors que vos concurrents continuent de gérer leur documentation sur les correctifs à l'aide de processus manuels, vous pourriez mettre en place des rapports de conformité automatisés en quelques minutes. Lorsque de futures demandes d'approvisionnement concernant les exigences NIS2 arriveront, vous pourrez procéder en toute confiance, sachant que votre infrastructure de conformité est solidement en place.

Alors, la prochaine fois que vous verrez un courriel relatif à un marché public dont l'objet est "Besoins en NIS2", prenez une autre gorgée de café. Allez-y, buvez une nouvelle gorgée de café. Vous l'avez dans le sac - ou plutôt dans la tasse.

Dans cet article, nous présentons les 10 outils SAST les plus performants en matière d'IA. Nous explorons les caractéristiques principales de chaque outil et les façons uniques dont ils mettent en œuvre l'IA pour améliorer la découverte, la priorisation et la remédiation en matière de sécurité.  

Qu'est-ce que SAST ?

Le test statique de sécurité des applications (SAST) est une méthodologie d'analyse du code source, du bytecode ou du binaire d'une application afin d'identifier les vulnérabilités et les failles de sécurité dès le début du cycle de développement du logiciel (SDLC). Le SAST trouve les vulnérabilités dans le code source, ce qui signifie qu'il constitue souvent la première défense contre un code non sécurisé.

Pour plus d'informations SAST vs DAST : ce qu'il faut savoir

Quelles vulnérabilités SAST trouve-t-il dans votre code ?

Il existe de nombreuses vulnérabilités différentes que SAST peut trouver et qui dépendent des pratiques de codage utilisées, de la pile technologique et des cadres. Voici quelques-unes des vulnérabilités les plus courantes qu'un outil SAST permet de découvrir.

Injection SQL

Détecte une mauvaise vérification des entrées de l'utilisateur qui pourrait compromettre la base de données.

Exemple de code d'injection

# Function to authenticate user
def authenticate_user(username, password):    
   query = f"SELECT * FROM users WHERE username = '{user}' AND password = '{password}'"
   print(f"Executing query: {query}")  # For debugging purposes    
   cursor.execute(query)    
   return cursor.fetchone()

Scripts intersites (XSS)

Identifie les cas où les entrées des utilisateurs sont incorrectement validées ou encodées, ce qui permet l'injection de scripts malveillants.

Exemple de code vulnérable à XSS

<script>
   const params = new URLSearchParams(window.location.search);
   const name = params.get('name');
   if (name) {
          // Directly inserting user input into HTML without sanitization
          document.getElementById('greeting').innerHTML = `Hello, ${name}!`;
   }
</script>

Débordements de mémoire tampon

Met en évidence les domaines dans lesquels une mauvaise gestion de l'allocation de la mémoire pourrait entraîner une corruption des données ou un blocage du système.

Exemple de code vulnérable à un débordement de mémoire tampon

1#include
2void vulnerableFunction() {
3    char buffer[10]; // A small buffer with space for 10 characters
4
5    printf("Enter some text: ");
6    gets(buffer); // Dangerous function: does not check input size
7
8    printf("You entered: %s\n", buffer);
9}
10
11int main() {
12    vulnerableFunction();
13    return 0;
14}

Pratiques cryptographiques peu sûres

Détecte les algorithmes de chiffrement faibles, la mauvaise gestion des clés ou les clés codées en dur.

import hashlib  

def store_password(password):    
    # Weak hashing algorithm (MD5 is broken and unsuitable for passwords)    
    hashed_password = hashlib.md5(password.encode()).hexdigest()    
    print(f"Storing hashed password: {hashed_password}")    
    return hashed_password

Les outils SAST fournissent des informations précieuses, permettant aux développeurs de résoudre les problèmes avant qu'ils ne deviennent critiques.

Comment l'IA améliore les outils SAST

À l'heure actuelle, il est impossible de se soustraire à l'effervescence de l'IA (et à son côté " BullSh*t "). Il peut être difficile de savoir exactement comment l'IA est mise en œuvre dans les outils de sécurité. Nous avons voulu comparer certains des leaders en matière de SAST alimenté par l'IA et expliquer les différentes façons dont ces outils mettent en œuvre l'IA pour améliorer la sécurité.  

À l'heure actuelle, trois tendances se dégagent de l'IA en ce qui concerne les outils SAST.

1. ‍AIpour améliorer la détection des vulnérabilités : Les modèles d'IA formés sur de vastes ensembles de données de vulnérabilités connues améliorent la précision de l'identification des problèmes de sécurité tout en réduisant les faux positifs.‍
2. L'IA pour créer une hiérarchisation automatisée : L'IA aide à classer les vulnérabilités en fonction de leur gravité, de leur exploitabilité et de leur impact commercial potentiel, ce qui permet aux développeurs de se concentrer d'abord sur les problèmes critiques.‍
3. L'IA pour fournir une remédiation automatisée: L'IA fournit des corrections de code ou des suggestions en fonction du contexte, ce qui accélère le processus de correction et aide les développeurs à apprendre des pratiques de codage sûres.

Les 10 meilleurs outils SAST alimentés par l'IA

Voici 10 leaders de l'industrie qui utilisent l'IA de différentes manières pour améliorer les capacités des SAST traditionnels (par ordre alphabétique).

1. Aikido Security SAST | AI AutoFix

Capacité AI principale | Remédiation automatique (Dashboard + IDE)

AikidoSecurity utilise l'IA pour créer des correctifs de code pour les vulnérabilités découvertes par son scanner SAST et peut même générer des demandes d'extraction automatisées pour accélérer le processus de remédiation.
Contrairement à d'autres outils, Aikido n'envoie pas votre code à un modèle d'IA tiers et dispose d'une méthode unique pour s'assurer que votre code ne fuit pas à travers les modèles d'IA. Aikido crée un environnement sandbox de votre code, puis un LLM adapté l'analyse et crée des suggestions qui sont également analysées à nouveau à la recherche de vulnérabilités. Une fois que la remédiation suggérée a passé la validation, une demande d'extraction peut être automatiquement créée avant que l'environnement Sandbox ne soit détruit. Aikidos AutoFix est également capable de donner un score de confiance sur les suggestions qu'il fait aux développeurs afin qu'ils prennent des décisions éclairées lorsqu'ils utilisent du code généré par l'IA.

2. Checkmarx

Capacité d'IA de base - Remédiation automatique (IDE uniquement)

Les outils SAST de Checkmarx peuvent fournir aux développeurs des suggestions de codage générées par l'IA dans leur IDE. L'outil se connecte à ChatGPT, transmet le code du développeur au modèle OpenAI et récupère les suggestions. Cette méthode facilite le processus d'interrogation de ChatGPT mais n'ajoute aucun processus propriétaire, ce qui lui confère des capacités limitées pour l'instant.

AVERTISSEMENT- Ce cas d'utilisation envoie votre code propriétaire à OpenAI et peut ne pas respecter les normes de conformité.

3. CodeAnt AI

Capacité principale d'IA - Amélioration de la détection (tableau de bord)

CodeAnt est un outil de sécurité et de qualité du code qui utilise entièrement l'IA pour découvrir les vulnérabilités du code et suggérer des correctifs. CodeAnt ne fournit pas de documentation sur le fonctionnement de ses modèles d'IA, mais utilise généralement l'IA comme moteur de détection principal, ce qui peut ralentir la détection, en particulier dans les grandes entreprises.

4. CodeThreat

Capacité de base de l'IA | Hiérarchisation automatisée (tableau de bord)

CodeThreat propose une analyse de code statique sur site et des stratégies de remédiation assistées par l'IA. La principale différence réside dans le fait que CodeThreat vous permet d'intégrer votre propre modèle d'IA sur site dans son outil. Cela présente l'avantage de ne pas envoyer de données à un tiers, mais signifie qu'il ne peut offrir pour l'instant que des modèles d'IA génétiquement entraînés et que vous devez utiliser un LLM d'IA sur site tel que ChatGPT.

5. Fortify Static Code Analyzer (analyseur de code statique)

Capacité de base en matière d'IA - Amélioration de l'ordre des priorités (tableau de bord)

Fortify Static Code Analyzer analyse le code source à la recherche de vulnérabilités et donne aux utilisateurs la possibilité d'ajuster les seuils lorsqu'une alerte est émise, par exemple en fonction de la probabilité d'exploitabilité. Fortifies AI Autoassistant examine les seuils précédents attribués aux vulnérabilités et fait des prédictions intelligentes sur ce que devraient être les seuils pour d'autres vulnérabilités.

Note : Fortify Static Code Analyzer n'utilise pas l'IA pour découvrir des vulnérabilités ou suggérer des correctifs, mais pour prédire les paramètres administratifs utilisés dans les panneaux d'administration.

6. Sécurité avancée de GitHub | CodeQL

Capacité principale d'IA | Auto Remediation (IDE + tableau de bord)

GitHub CodeQL est un scanner de code statique qui utilise l'IA pour créer une auto-remédiation intelligente sous la forme de suggestions de code. Les développeurs peuvent accepter ou rejeter les modifications par le biais de demandes d'extraction dans GitHub CodeSpaces ou à partir de leur machine. Il fait partie de GitHub Advanced Security.

7. Qwiet AI | Code SAST

Core AI Capability | Auto Remediation (Dashboard)
QwietAI SAST est un outil de test statique de la sécurité des applications basé sur des règles qui exploite l'IA pour suggérer automatiquement des conseils de remédiation et des corrections de code pour les vulnérabilités du code. Son offre principale est constituée d'agents d'IA en trois étapes qui analysent le problème, suggèrent une correction, puis valident la correction.

8. Snyk Code | DeepCode

Capacité principale d'IA | Auto Remediation (IDE)

Snyk Code, un outil SAST en temps réel axé sur le développeur, peut fournir des suggestions de code aux développeurs à partir de l'IDE grâce à DeepCode AI que Snyk a acquis. DeepCode AI utilise plusieurs modèles d'IA et son principal argument de vente est que ses modèles sont entraînés sur des données sélectionnées par les meilleurs spécialistes de la sécurité, ce qui améliore la confiance dans les résultats de l'IA.

9. Code Semgrep

Capacité d'IA de base | Détection améliorée
L'assistant d'IA de SemGreps, judicieusement nommé assistant, utilise le contexte du code entourant une vulnérabilité potentielle pour fournir des résultats plus précis et recommander des correctifs de code. Il peut également être utilisé pour créer des règles pour SemGrep afin d'améliorer sa détection en fonction des invites que vous fournissez.

10. Correction du Veracode

Core AI Capability | Auto Remediation
Veracode fix utilise l'IA pour suggérer des changements basés sur les vulnérabilités dans le code lorsque les développeurs utilisent l'extension Veracode IDE ou l'outil CLI. La principale différence de Veracode Fix réside dans le fait que son modèle personnalisé n'est pas formé sur du code sauvage mais sur des vulnérabilités connues dans sa base de données. L'avantage est que les correctifs suggérés sont plus fiables, mais l'inconvénient est que les scénarios dans lesquels il peut suggérer des correctifs de code sont plus limités.

Comment choisir un outil SAST

L'IA est relativement nouvelle sur le marché de la sécurité, et les leaders de l'industrie ne cessent d'explorer des applications innovantes. L'IA doit être considérée comme un outil permettant d'améliorer les systèmes de sécurité, plutôt que comme une source unique de vérité. Il est important de noter que l'IA ne peut pas transformer des outils médiocres en outils efficaces. Pour maximiser son potentiel, l'IA doit être intégrée à des outils qui disposent déjà d'une base solide et d'une expérience éprouvée.

Consultez Aikido SAST aujourd'hui

Vous êtes donc à la recherche d'une sécurité applicative, voire d'une alternative à Snyk. Que vous exploriez pour la première fois une plateforme de sécurité du code ou que vous soyez un utilisateur chevronné à la recherche de meilleures options, vous êtes au bon endroit.

Lorsque les développeurs et les entreprises évaluent leurs choix, deux noms reviennent souvent en tête : Aikido Security et Snyk. Ces deux plateformes offrent des outils complets permettant aux équipes d'ingénieurs de sécuriser leurs applications, mais comment se comparent-elles réellement ? Plutôt que de nous fier à des opinions, nous nous tournons vers les voix qui comptent le plus : les utilisateurs réels.

Basé sur des avis vérifiés de tiers

Ce guide est une synthèse directe d'avis de tiers vérifiés provenant de G2, la plus grande place de marché de logiciels de confiance au monde. Plus de 100 millions de professionnels font confiance à G2 chaque année pour prendre des décisions éclairées en matière de logiciels en s'appuyant sur les commentaires authentiques des utilisateurs. Sur la base des dernières données vérifiées des utilisateurs de G2, nous fournirons une analyse détaillée d'Aikido Security par rapport à Snyk, en analysant les fonctionnalités, l'expérience utilisateur, les prix, et plus encore.

En outre, vous pouvez également lire ces avis d'utilisateurs directement sur G2. Voici le lien G2 pour Aikido Security et pour Snyk, et les commentaires directs qui comparent Aikido comme une alternative à Snyk.

Qu'est-ce que la sécurité en aïkido ?

Dirigée par Willem Delbare, CTO en série, Aikido est la plateforme de sécurité "no bullshit" pour les développeurs. Après de nombreuses années d'utilisation d'autres produits de sécurité applicative, Willem Delbare a fondé Aikido pour améliorer la sécurité des directeurs techniques et des développeurs grâce à une plateforme de sécurité code-to-cloud tout-en-un conçue pour aider les équipes d'ingénierie à obtenir une sécurité sécurité.

Les équipes d'ingénieurs travaillent plus rapidement avec Aikido grâce à des fonctionnalités dédiées aux développeurs : scans centralisés, réduction agressive des faux positifs, UX dev-native, triage automatique des risques, regroupement des risques, et correction des risques étape par étape, y compris des corrections automatiques basées sur LLM pour 3 types de problèmes différents.

TL;DR Aikido rend la sécurité simple pour les PME et réalisable pour les développeurs, afin que les entreprises puissent gagner des clients, se développer sur le marché et se mettre en conformité.

Qu'est-ce que Snyk :

Snyk est une société de sécurité bien connue qui se positionne comme un outil de sécurité "orienté développeur", permettant aux équipes d'identifier et de corriger les vulnérabilités dans leur code, les dépendances open-source et les images de conteneurs. Snyk est un acteur précoce du mouvement de sécurité "shift left" et a été fondée il y a 10 ans à Tel Aviv et à Londres et a actuellement son siège à Boston, aux États-Unis.

Aikido vs Snyk Alternative en un coup d'œil

• Sécurité de l'aïkido :
  
  • Rating ⭐️ : 4.7
  • Segments de marché : Petites et moyennes entreprises
  • Prix pour les débutants : Gratuit
• Snyk :
  
  • Evaluation ⭐️ : 4.5
  • Segments de marché : du marché intermédiaire à l'entreprise
  • Prix pour les débutants : Gratuit

Aikido Security est largement plébiscité par les petites et moyennes entreprises, tandis que Snyk est plus largement adopté par les grandes organisations du marché intermédiaire, en particulier les entreprises. Les deux plateformes proposent des plans gratuits, ce qui les rend accessibles aux développeurs individuels et aux petites équipes.

Aperçu du classement des catégories

Expérience de l'utilisateur

Facilité d'utilisation

• Sécurité Aikido: Avec une note de 9,5, les utilisateurs font l'éloge de son interface intuitive et de ses flux de travail rationalisés. Il est conçu selon une approche privilégiant les développeurs, ce qui permet de minimiser les frictions lors de l'intégration dans les pipelines CI/CD existants.
• Snyk: Noté 8,7, tout en restant convivial, certains évaluateurs notent une courbe d'apprentissage plus raide, en particulier pour les équipes qui ne sont pas familiarisées avec les outils DevSecOps.

Facilité d'installation

• Sécurité Aikido: Avec une note de 9,5, les utilisateurs apprécient la rapidité du processus d'intégration d'Aikido et les exigences minimales en matière de configuration.
• Snyk: Classé 9.0, l'installation est simple, mais les utilisateurs rencontrent parfois des difficultés d'intégration avec des outils moins courants.

Facilité d'administration

• Sécurité Aikido: Scoring 9.3, les administrateurs système trouvent qu'il est facile de gérer les équipes, les permissions et les intégrations.
• Snyk: Noté 8,8, l'administration est efficace mais peut devenir complexe dans les grandes organisations.

Soutien et orientation des produits

Qualité du soutien

• Sécurité Aikido: Avec un score impressionnant de 9,6, les utilisateurs félicitent fréquemment l'équipe d'assistance réactive et compétente. La plupart des témoignages soulignent la rapidité du support de l'équipe d'Aikido et des fondateurs comme un point fort.
• Snyk: Classé 8.6, le support est correct, généralement fiable mais parfois plus lent pour les utilisateurs du niveau libre.

Direction du produit

• Sécurité Aikido: Les utilisateurs attribuent à Aikido une note ronde de 10.0, ce qui reflète la confiance des utilisateurs dans sa feuille de route innovante et ses mises à jour régulières.
• Snyk: Noté 8,7, apprécié pour l'importance qu'il accorde à l'open source et aux outils centrés sur les développeurs, mais légèrement à la traîne en ce qui concerne la mise en place de fonctionnalités complètes.

Aikido vs Snyk Alternative Feature Comparaison

Si vous cherchez une alternative à Snyk, il est important de noter les fonctionnalités de production spécifiques offertes par chaque plateforme. Alors que Snyk propose SAST, IaC, Software Composition Analysis et l'analyse de vulnérabilité, Aikido offre davantage de fonctions et de caractéristiques au sein de sa plateforme tout-en-un.

Alors que Snyk propose 4 produits, Aikido offre 11 produits dans une suite de sécurité, y compris SAST, DAST, Software Composition Analysis, IaC, container image scanning, secret scanning, malware scanning, API scanning, license risk scanning, local custom scanning, ainsi que la sécurité dans le nuage (CSPM).

Tests statiques de sécurité des applications (SAST)

Qu'est-ce que c'est ? SAST est une méthode permettant d'identifier les vulnérabilités du code source avant son déploiement.

• Aikido Security: Classé 8,7, il excelle dans l'identification des vulnérabilités dans le code source et dans la présentation d'informations exploitables.
• Snyk: Noté 7,7, efficace mais souvent critiqué pour générer plus de faux positifs que ses concurrents.

Test dynamique de la sécurité des applications (DAST)

Qu'est-ce que c'est ? DAST est une technique qui analyse les applications en cours d'exécution afin de détecter les vulnérabilités.

• Sécurité Aikido: Avec une note de 8,9, les utilisateurs apprécient sa capacité à identifier les vulnérabilités d'exécution avec une configuration minimale.
• Snyk: Les données disponibles ne sont pas suffisantes pour évaluer les capacités de DAST.

Sécurité des conteneurs

Qu'est-ce que la sécurité des conteneurs ? La sécurité des conteneurs est le processus d'identification des vulnérabilités dans les applications et les images conteneurisées.

• Aikido Security: Classé 8.4, il fournit des informations approfondies sur les images de conteneurs et les vulnérabilités dans les registres.
• Snyk: Classé 7,9, il est performant pour l'analyse de base des conteneurs, mais moins complet pour les scénarios avancés.

Analyse de la composition des logiciels (SCA)

De quoi s'agit-il ? Le SCA est une pratique qui consiste à détecter les vulnérabilités dans les dépendances open-source et les bibliothèques tierces.

• Aikido Security: Avec une note de 8,9, il combine l'analyse des dépendances en source ouverte et la détection améliorée des logiciels malveillants, ce qui garantit une protection solide.
• Snyk: Classé 8.0, efficace pour détecter les vulnérabilités connues dans les bibliothèques open-source, mais moins avancé dans l'identification des paquets malveillants.

Gestion de la sécurité des applications (ASPM)

Qu'est-ce que c'est ? ASPM est un cadre permettant de gérer et d'améliorer la sécurité des applications tout au long de leur cycle de vie.

• Sécurité Aikido: Note de 8,4, pour son approche proactive de l'identification et de la résolution des risques de sécurité dans les environnements applicatifs.
• Snyk: Les données disponibles ne sont pas suffisantes pour évaluer les capacités des SAGI.

Gestion de la sécurité de l'informatique en nuage (CSPM)

De quoi s'agit-il ? CSPM est un ensemble d'outils permettant de surveiller et de sécuriser les environnements en nuage en identifiant les mauvaises configurations et les problèmes de conformité.

• Surveille et sécurise les environnements en nuage en identifiant les mauvaises configurations et les problèmes de conformité.
• Sécurité Aikido: Rated 7.4, s'intègre de manière transparente dans les environnements multi-cloud, fournissant des informations claires sur les erreurs de configuration. La fonctionnalité CSPM d'Aikido a été récemment lancée et constitue une facette importante de notre feuille de route.
• Snyk: Les données disponibles ne sont pas suffisantes pour évaluer les fonctionnalités de la GPSC. À l'heure actuelle, Snyk ne dispose pas de la fonctionnalité GPSC.

Scanner de vulnérabilité

Qu'est-ce que c'est ? Un scanner de vulnérabilité identifie et évalue les failles de sécurité dans les systèmes et les logiciels.

• Sécurité Aikido: Classé 7,9, efficace dans l'identification des vulnérabilités avec des conseils clairs pour y remédier.
• Snyk: note de 8,1, apprécié pour sa vaste bibliothèque de vulnérabilités connues, mais critiqué pour le bruit fréquent dans les résultats.

Témoignages vérifiés de clients de Snyk vs Aikido :

Avis de personnes vérifiées qui ont utilisé à la fois Aikido et Snyk. Si vous voulez savoir comment Aikido se positionne en tant qu'alternative à Snyk, lisez ce qui suit.

Aikido est une "solution efficace et juste".

Comparé à des concurrents bien connus comme Snyk, Aikido est beaucoup plus abordable, plus complet et surtout beaucoup plus efficace pour présenter les vulnérabilités qui atteignent réellement vos systèmes. Il utilise de nombreuses bibliothèques open source populaires pour analyser votre code, ainsi que des bibliothèques propriétaires, ce qui vous donne un bon mélange.

L'aïkido est "une alternative moins coûteuse à Snyk".

Nous cherchions une alternative moins chère à Snyk et Aikido remplit ce rôle de manière fantastique. Un bon logiciel, une interface facile à utiliser et, surtout, une grande facilité à obtenir des informations en retour.

Tout a été très simple à mettre en place et l'intégration des membres de l'équipe a été un jeu d'enfant.

Nous espérons que ce résumé des commentaires des utilisateurs de G2 vous aidera à trouver une plateforme de sécurité pour vos applications. Si vous souhaitez tester Aikido, pourquoi ne pas vous lancer dès maintenant?

Obtenez vos premiers résultats d'analyse en 32 secondes, sans carte de crédit et sans conditions. Vous pouvez même utiliser des données de démonstration pour plus de sécurité. Si vous souhaitez une visite plus personnalisée, vous pouvez parler à un humain ou dire "bonjour" sur l'interphone. Nous répondons en quelques secondes 🤝

       

       if(window.strchfSettings === undefined) window.strchfSettings = {};
   window.strchfSettings.stats = {url: "https://aikido-security.storychief.io/en/snyk-vs-aikido-security-g2-reviews-snyk-alternative?id=843344305&type=26",title: "Snyk vs Aikido Security | G2 Reviews Snyk Alternative",siteId: "5823",id: "f8908bf0-c824-4f3f-9bc9-22cac096e678"};
           (function(d, s, id) {
     var js, sjs = d.getElementsByTagName(s)[0];
     if (d.getElementById(id)) {window.strchf.update(); return;}
     js = d.createElement(s); js.id = id;
     js.src = "https://d37oebn0w9ir6a.cloudfront.net/scripts/v0/strchf.js";
     js.async = true;
     sjs.parentNode.insertBefore(js, sjs);
   }(document, 'script', 'storychief-jssdk'))