Les codeurs conquièrent la sécurité : Share & Learn Series - Injection de commande du système d'exploitation
Une attaque par injection de commande du système d'exploitation peut se produire lorsqu'une application permet aux utilisateurs de saisir des données dans un shell, mais ne prend aucune mesure pour vérifier que les chaînes de caractères saisies sont valides. Cela permet à un attaquant d'introduire des commandes directement dans le système d'exploitation hébergeant l'application, et ce quel que soit le niveau d'autorisation défini pour l'application compromise.
Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir. Dans cet épisode, nous allons apprendre :
Comment ils fonctionnent
Pourquoi ils sont si dangereux
Comment vous pouvez mettre en place des défenses pour les arrêter.
Comment les attaquants utilisent-ils l'injection de commandes dans le système d'exploitation ?
La première chose qu'un attaquant doit faire pour lancer une attaque par injection de commande de système d'exploitation est de localiser les entrées de l'utilisateur dans une application. Les formulaires que les utilisateurs remplissent sont potentiellement de bons points de départ. Les attaquants les plus astucieux peuvent également utiliser des éléments tels que les cookies ou même les en-têtes HTTP comme point de départ, un élément utilisé par presque toutes les applications ou tous les sites web.
La deuxième chose à faire est de déterminer le système d'exploitation qui héberge l'application. Étant donné qu'il n'existe qu'une poignée de choix, la méthode des essais et des erreurs peut très bien fonctionner pour cette phase. La plupart des serveurs d'application seront soit basés sur Windows (la version de Windows n'a normalement pas d'importance), soit sur un boîtier Linux, soit éventuellement sur Unix.
À ce stade, le pirate modifie l'entrée pour injecter une commande du système d'exploitation dans une entrée apparemment inoffensive. Cela peut inciter le système d'exploitation hôte à exécuter des commandes non souhaitées, quel que soit le niveau d'autorisation de l'application.
Par exemple, la commande suivante peut être utilisée par des utilisateurs valides au sein d'une application pour voir le contenu d'un fichier, dans ce cas les notes d'une réunion mensuelle du conseil d'administration.
exec("cat " + nom de fichier)
Dans notre exemple, la commande suivante sera exécutée et les notes de réunion seront renvoyées à l'utilisateur.
./cat MeetingNotes.txt
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
C'est ce qui se produit lorsqu'un attaquant ajoute des commandes supplémentaires à la fin de l'entrée, comme celle utilisée pour lister le contenu d'un répertoire sous Linux. Dans ce cas, la commande originale, qui consiste à afficher les notes de réunion, est toujours exécutée. Mais l'utilisateur malveillant voit également tout ce qui se trouve dans le répertoire et les autres commandes qu'il peut utiliser dans le cadre d'attaques par injection de commandes du système d'exploitation. Il entre :
$ ./cat MeetingNotes.txt && ls
Et obtenez ceci à la place :
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
Comme vous pouvez le voir, dans ce cas, non seulement le pirate a vu le contenu du répertoire, mais il a également reçu un menu d'autres commandes qu'il pouvait utiliser " des commandes qu'il sait maintenant pouvoir exécuter sur le système d'exploitation hôte ".
Pourquoi les attaques par injection de commande du système d'exploitation sont-elles si dangereuses ?
Permettre aux utilisateurs de contourner l'objectif de l'application ciblée et de l'utiliser pour exécuter des commandes du système d'exploitation est extrêmement risqué. Un pirate peut facilement réaliser des actions dévastatrices telles que le vol de données confidentielles ou le formatage de l'ensemble du disque du serveur, par exemple. Les options dont dispose un pirate ne sont limitées que par les commandes autorisées dans le système d'exploitation et par la créativité dont il fait preuve pour les utiliser.
Les commandes du système d'exploitation sont exécutées au même niveau d'autorisation que l'application. Les applications fonctionnant avec des privilèges administratifs signifient que les pirates qui les compromettent peuvent exécuter toutes les commandes du système d'exploitation.
Les schémas d'attaque pour l'injection de commandes dans les systèmes d'exploitation sont bien connus et documentés. Une application vulnérable est tout aussi susceptible d'être attaquée par des "script kiddies" que par des pirates professionnels. Les attaquants ayant très peu de compétences peuvent essayer de copier et de coller des commandes de système d'exploitation dans des applications pour voir ce qui se passe.
Obtenir un OK de sécurité contre les injections de commandes du système d'exploitation
Il existe plusieurs techniques efficaces pour empêcher les injections de commandes dans le système d'exploitation. La première étape consiste à exécuter les applications avec le minimum de privilèges nécessaires à l'accomplissement de leur fonction. Cela n'empêchera pas une attaque, mais si une brèche se produit, les dommages seront minimisés.
La plupart des langages de programmation et des frameworks fournissent des appels API pour les méthodes courantes du système d'exploitation, telles que l'énumération du contenu des répertoires, la création ou la lecture de fichiers sur le disque dur. Un moyen idéal d'éliminer les injections de commandes du système d'exploitation de votre environnement consiste à faire en sorte que toutes les applications utilisent ces appels d'API au lieu des commandes du système d'exploitation directement.
Lorsque cela n'est pas possible, validez les entrées de l'utilisateur avant de les utiliser dans les commandes du système d'exploitation. Les listes blanches peuvent être utilisées pour s'assurer que seul un petit ensemble de valeurs de confiance peut être utilisé. Techniquement, il est également possible d'utiliser une liste noire, mais les commandes autorisées étant probablement beaucoup moins nombreuses, l'établissement d'une liste blanche est presque toujours plus facile. N'oubliez pas d'inclure les paramètres POST et GET valides dans votre liste blanche, ainsi que les vecteurs d'entrée utilisateur souvent négligés comme les cookies.
Enfin, s'il n'existe pas d'API de programmation et qu'il n'est pas possible d'utiliser une liste blanche, utilisez une bibliothèque d'assainissement pour échapper à tout caractère spécial dans les entrées utilisateur avant de les utiliser dans les commandes du système d'exploitation.
Plus d'informations sur les attaques par injection de commandes du système d'exploitation
Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les attaques par injection de commandes du système d'exploitation. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .


Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.


Une attaque par injection de commande du système d'exploitation peut se produire lorsqu'une application permet aux utilisateurs de saisir des données dans un shell, mais ne prend aucune mesure pour vérifier que les chaînes de caractères saisies sont valides. Cela permet à un attaquant d'introduire des commandes directement dans le système d'exploitation hébergeant l'application, et ce quel que soit le niveau d'autorisation défini pour l'application compromise.
Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir. Dans cet épisode, nous allons apprendre :
Comment ils fonctionnent
Pourquoi ils sont si dangereux
Comment vous pouvez mettre en place des défenses pour les arrêter.
Comment les attaquants utilisent-ils l'injection de commandes dans le système d'exploitation ?
La première chose qu'un attaquant doit faire pour lancer une attaque par injection de commande de système d'exploitation est de localiser les entrées de l'utilisateur dans une application. Les formulaires que les utilisateurs remplissent sont potentiellement de bons points de départ. Les attaquants les plus astucieux peuvent également utiliser des éléments tels que les cookies ou même les en-têtes HTTP comme point de départ, un élément utilisé par presque toutes les applications ou tous les sites web.
La deuxième chose à faire est de déterminer le système d'exploitation qui héberge l'application. Étant donné qu'il n'existe qu'une poignée de choix, la méthode des essais et des erreurs peut très bien fonctionner pour cette phase. La plupart des serveurs d'application seront soit basés sur Windows (la version de Windows n'a normalement pas d'importance), soit sur un boîtier Linux, soit éventuellement sur Unix.
À ce stade, le pirate modifie l'entrée pour injecter une commande du système d'exploitation dans une entrée apparemment inoffensive. Cela peut inciter le système d'exploitation hôte à exécuter des commandes non souhaitées, quel que soit le niveau d'autorisation de l'application.
Par exemple, la commande suivante peut être utilisée par des utilisateurs valides au sein d'une application pour voir le contenu d'un fichier, dans ce cas les notes d'une réunion mensuelle du conseil d'administration.
exec("cat " + nom de fichier)
Dans notre exemple, la commande suivante sera exécutée et les notes de réunion seront renvoyées à l'utilisateur.
./cat MeetingNotes.txt
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
C'est ce qui se produit lorsqu'un attaquant ajoute des commandes supplémentaires à la fin de l'entrée, comme celle utilisée pour lister le contenu d'un répertoire sous Linux. Dans ce cas, la commande originale, qui consiste à afficher les notes de réunion, est toujours exécutée. Mais l'utilisateur malveillant voit également tout ce qui se trouve dans le répertoire et les autres commandes qu'il peut utiliser dans le cadre d'attaques par injection de commandes du système d'exploitation. Il entre :
$ ./cat MeetingNotes.txt && ls
Et obtenez ceci à la place :
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
Comme vous pouvez le voir, dans ce cas, non seulement le pirate a vu le contenu du répertoire, mais il a également reçu un menu d'autres commandes qu'il pouvait utiliser " des commandes qu'il sait maintenant pouvoir exécuter sur le système d'exploitation hôte ".
Pourquoi les attaques par injection de commande du système d'exploitation sont-elles si dangereuses ?
Permettre aux utilisateurs de contourner l'objectif de l'application ciblée et de l'utiliser pour exécuter des commandes du système d'exploitation est extrêmement risqué. Un pirate peut facilement réaliser des actions dévastatrices telles que le vol de données confidentielles ou le formatage de l'ensemble du disque du serveur, par exemple. Les options dont dispose un pirate ne sont limitées que par les commandes autorisées dans le système d'exploitation et par la créativité dont il fait preuve pour les utiliser.
Les commandes du système d'exploitation sont exécutées au même niveau d'autorisation que l'application. Les applications fonctionnant avec des privilèges administratifs signifient que les pirates qui les compromettent peuvent exécuter toutes les commandes du système d'exploitation.
Les schémas d'attaque pour l'injection de commandes dans les systèmes d'exploitation sont bien connus et documentés. Une application vulnérable est tout aussi susceptible d'être attaquée par des "script kiddies" que par des pirates professionnels. Les attaquants ayant très peu de compétences peuvent essayer de copier et de coller des commandes de système d'exploitation dans des applications pour voir ce qui se passe.
Obtenir un OK de sécurité contre les injections de commandes du système d'exploitation
Il existe plusieurs techniques efficaces pour empêcher les injections de commandes dans le système d'exploitation. La première étape consiste à exécuter les applications avec le minimum de privilèges nécessaires à l'accomplissement de leur fonction. Cela n'empêchera pas une attaque, mais si une brèche se produit, les dommages seront minimisés.
La plupart des langages de programmation et des frameworks fournissent des appels API pour les méthodes courantes du système d'exploitation, telles que l'énumération du contenu des répertoires, la création ou la lecture de fichiers sur le disque dur. Un moyen idéal d'éliminer les injections de commandes du système d'exploitation de votre environnement consiste à faire en sorte que toutes les applications utilisent ces appels d'API au lieu des commandes du système d'exploitation directement.
Lorsque cela n'est pas possible, validez les entrées de l'utilisateur avant de les utiliser dans les commandes du système d'exploitation. Les listes blanches peuvent être utilisées pour s'assurer que seul un petit ensemble de valeurs de confiance peut être utilisé. Techniquement, il est également possible d'utiliser une liste noire, mais les commandes autorisées étant probablement beaucoup moins nombreuses, l'établissement d'une liste blanche est presque toujours plus facile. N'oubliez pas d'inclure les paramètres POST et GET valides dans votre liste blanche, ainsi que les vecteurs d'entrée utilisateur souvent négligés comme les cookies.
Enfin, s'il n'existe pas d'API de programmation et qu'il n'est pas possible d'utiliser une liste blanche, utilisez une bibliothèque d'assainissement pour échapper à tout caractère spécial dans les entrées utilisateur avant de les utiliser dans les commandes du système d'exploitation.
Plus d'informations sur les attaques par injection de commandes du système d'exploitation
Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les attaques par injection de commandes du système d'exploitation. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Une attaque par injection de commande du système d'exploitation peut se produire lorsqu'une application permet aux utilisateurs de saisir des données dans un shell, mais ne prend aucune mesure pour vérifier que les chaînes de caractères saisies sont valides. Cela permet à un attaquant d'introduire des commandes directement dans le système d'exploitation hébergeant l'application, et ce quel que soit le niveau d'autorisation défini pour l'application compromise.
Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir. Dans cet épisode, nous allons apprendre :
Comment ils fonctionnent
Pourquoi ils sont si dangereux
Comment vous pouvez mettre en place des défenses pour les arrêter.
Comment les attaquants utilisent-ils l'injection de commandes dans le système d'exploitation ?
La première chose qu'un attaquant doit faire pour lancer une attaque par injection de commande de système d'exploitation est de localiser les entrées de l'utilisateur dans une application. Les formulaires que les utilisateurs remplissent sont potentiellement de bons points de départ. Les attaquants les plus astucieux peuvent également utiliser des éléments tels que les cookies ou même les en-têtes HTTP comme point de départ, un élément utilisé par presque toutes les applications ou tous les sites web.
La deuxième chose à faire est de déterminer le système d'exploitation qui héberge l'application. Étant donné qu'il n'existe qu'une poignée de choix, la méthode des essais et des erreurs peut très bien fonctionner pour cette phase. La plupart des serveurs d'application seront soit basés sur Windows (la version de Windows n'a normalement pas d'importance), soit sur un boîtier Linux, soit éventuellement sur Unix.
À ce stade, le pirate modifie l'entrée pour injecter une commande du système d'exploitation dans une entrée apparemment inoffensive. Cela peut inciter le système d'exploitation hôte à exécuter des commandes non souhaitées, quel que soit le niveau d'autorisation de l'application.
Par exemple, la commande suivante peut être utilisée par des utilisateurs valides au sein d'une application pour voir le contenu d'un fichier, dans ce cas les notes d'une réunion mensuelle du conseil d'administration.
exec("cat " + nom de fichier)
Dans notre exemple, la commande suivante sera exécutée et les notes de réunion seront renvoyées à l'utilisateur.
./cat MeetingNotes.txt
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
C'est ce qui se produit lorsqu'un attaquant ajoute des commandes supplémentaires à la fin de l'entrée, comme celle utilisée pour lister le contenu d'un répertoire sous Linux. Dans ce cas, la commande originale, qui consiste à afficher les notes de réunion, est toujours exécutée. Mais l'utilisateur malveillant voit également tout ce qui se trouve dans le répertoire et les autres commandes qu'il peut utiliser dans le cadre d'attaques par injection de commandes du système d'exploitation. Il entre :
$ ./cat MeetingNotes.txt && ls
Et obtenez ceci à la place :
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
Comme vous pouvez le voir, dans ce cas, non seulement le pirate a vu le contenu du répertoire, mais il a également reçu un menu d'autres commandes qu'il pouvait utiliser " des commandes qu'il sait maintenant pouvoir exécuter sur le système d'exploitation hôte ".
Pourquoi les attaques par injection de commande du système d'exploitation sont-elles si dangereuses ?
Permettre aux utilisateurs de contourner l'objectif de l'application ciblée et de l'utiliser pour exécuter des commandes du système d'exploitation est extrêmement risqué. Un pirate peut facilement réaliser des actions dévastatrices telles que le vol de données confidentielles ou le formatage de l'ensemble du disque du serveur, par exemple. Les options dont dispose un pirate ne sont limitées que par les commandes autorisées dans le système d'exploitation et par la créativité dont il fait preuve pour les utiliser.
Les commandes du système d'exploitation sont exécutées au même niveau d'autorisation que l'application. Les applications fonctionnant avec des privilèges administratifs signifient que les pirates qui les compromettent peuvent exécuter toutes les commandes du système d'exploitation.
Les schémas d'attaque pour l'injection de commandes dans les systèmes d'exploitation sont bien connus et documentés. Une application vulnérable est tout aussi susceptible d'être attaquée par des "script kiddies" que par des pirates professionnels. Les attaquants ayant très peu de compétences peuvent essayer de copier et de coller des commandes de système d'exploitation dans des applications pour voir ce qui se passe.
Obtenir un OK de sécurité contre les injections de commandes du système d'exploitation
Il existe plusieurs techniques efficaces pour empêcher les injections de commandes dans le système d'exploitation. La première étape consiste à exécuter les applications avec le minimum de privilèges nécessaires à l'accomplissement de leur fonction. Cela n'empêchera pas une attaque, mais si une brèche se produit, les dommages seront minimisés.
La plupart des langages de programmation et des frameworks fournissent des appels API pour les méthodes courantes du système d'exploitation, telles que l'énumération du contenu des répertoires, la création ou la lecture de fichiers sur le disque dur. Un moyen idéal d'éliminer les injections de commandes du système d'exploitation de votre environnement consiste à faire en sorte que toutes les applications utilisent ces appels d'API au lieu des commandes du système d'exploitation directement.
Lorsque cela n'est pas possible, validez les entrées de l'utilisateur avant de les utiliser dans les commandes du système d'exploitation. Les listes blanches peuvent être utilisées pour s'assurer que seul un petit ensemble de valeurs de confiance peut être utilisé. Techniquement, il est également possible d'utiliser une liste noire, mais les commandes autorisées étant probablement beaucoup moins nombreuses, l'établissement d'une liste blanche est presque toujours plus facile. N'oubliez pas d'inclure les paramètres POST et GET valides dans votre liste blanche, ainsi que les vecteurs d'entrée utilisateur souvent négligés comme les cookies.
Enfin, s'il n'existe pas d'API de programmation et qu'il n'est pas possible d'utiliser une liste blanche, utilisez une bibliothèque d'assainissement pour échapper à tout caractère spécial dans les entrées utilisateur avant de les utiliser dans les commandes du système d'exploitation.
Plus d'informations sur les attaques par injection de commandes du système d'exploitation
Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les attaques par injection de commandes du système d'exploitation. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Une attaque par injection de commande du système d'exploitation peut se produire lorsqu'une application permet aux utilisateurs de saisir des données dans un shell, mais ne prend aucune mesure pour vérifier que les chaînes de caractères saisies sont valides. Cela permet à un attaquant d'introduire des commandes directement dans le système d'exploitation hébergeant l'application, et ce quel que soit le niveau d'autorisation défini pour l'application compromise.
Les attaques par injection de commandes du système d'exploitation peuvent être réalisées par des pirates débutants ou peu qualifiés, ce qui en fait l'une des faiblesses les plus courantes auxquelles les équipes de sécurité sont confrontées. Heureusement, il existe plusieurs moyens très efficaces d'empêcher ces attaques de réussir. Dans cet épisode, nous allons apprendre :
Comment ils fonctionnent
Pourquoi ils sont si dangereux
Comment vous pouvez mettre en place des défenses pour les arrêter.
Comment les attaquants utilisent-ils l'injection de commandes dans le système d'exploitation ?
La première chose qu'un attaquant doit faire pour lancer une attaque par injection de commande de système d'exploitation est de localiser les entrées de l'utilisateur dans une application. Les formulaires que les utilisateurs remplissent sont potentiellement de bons points de départ. Les attaquants les plus astucieux peuvent également utiliser des éléments tels que les cookies ou même les en-têtes HTTP comme point de départ, un élément utilisé par presque toutes les applications ou tous les sites web.
La deuxième chose à faire est de déterminer le système d'exploitation qui héberge l'application. Étant donné qu'il n'existe qu'une poignée de choix, la méthode des essais et des erreurs peut très bien fonctionner pour cette phase. La plupart des serveurs d'application seront soit basés sur Windows (la version de Windows n'a normalement pas d'importance), soit sur un boîtier Linux, soit éventuellement sur Unix.
À ce stade, le pirate modifie l'entrée pour injecter une commande du système d'exploitation dans une entrée apparemment inoffensive. Cela peut inciter le système d'exploitation hôte à exécuter des commandes non souhaitées, quel que soit le niveau d'autorisation de l'application.
Par exemple, la commande suivante peut être utilisée par des utilisateurs valides au sein d'une application pour voir le contenu d'un fichier, dans ce cas les notes d'une réunion mensuelle du conseil d'administration.
exec("cat " + nom de fichier)
Dans notre exemple, la commande suivante sera exécutée et les notes de réunion seront renvoyées à l'utilisateur.
./cat MeetingNotes.txt
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
C'est ce qui se produit lorsqu'un attaquant ajoute des commandes supplémentaires à la fin de l'entrée, comme celle utilisée pour lister le contenu d'un répertoire sous Linux. Dans ce cas, la commande originale, qui consiste à afficher les notes de réunion, est toujours exécutée. Mais l'utilisateur malveillant voit également tout ce qui se trouve dans le répertoire et les autres commandes qu'il peut utiliser dans le cadre d'attaques par injection de commandes du système d'exploitation. Il entre :
$ ./cat MeetingNotes.txt && ls
Et obtenez ceci à la place :
Trois membres du comité exécutif étaient présents à la réunion de juillet. Le nouveau projet de budget a été discuté, mais aucune action ou vote n'a été effectué.
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
Comme vous pouvez le voir, dans ce cas, non seulement le pirate a vu le contenu du répertoire, mais il a également reçu un menu d'autres commandes qu'il pouvait utiliser " des commandes qu'il sait maintenant pouvoir exécuter sur le système d'exploitation hôte ".
Pourquoi les attaques par injection de commande du système d'exploitation sont-elles si dangereuses ?
Permettre aux utilisateurs de contourner l'objectif de l'application ciblée et de l'utiliser pour exécuter des commandes du système d'exploitation est extrêmement risqué. Un pirate peut facilement réaliser des actions dévastatrices telles que le vol de données confidentielles ou le formatage de l'ensemble du disque du serveur, par exemple. Les options dont dispose un pirate ne sont limitées que par les commandes autorisées dans le système d'exploitation et par la créativité dont il fait preuve pour les utiliser.
Les commandes du système d'exploitation sont exécutées au même niveau d'autorisation que l'application. Les applications fonctionnant avec des privilèges administratifs signifient que les pirates qui les compromettent peuvent exécuter toutes les commandes du système d'exploitation.
Les schémas d'attaque pour l'injection de commandes dans les systèmes d'exploitation sont bien connus et documentés. Une application vulnérable est tout aussi susceptible d'être attaquée par des "script kiddies" que par des pirates professionnels. Les attaquants ayant très peu de compétences peuvent essayer de copier et de coller des commandes de système d'exploitation dans des applications pour voir ce qui se passe.
Obtenir un OK de sécurité contre les injections de commandes du système d'exploitation
Il existe plusieurs techniques efficaces pour empêcher les injections de commandes dans le système d'exploitation. La première étape consiste à exécuter les applications avec le minimum de privilèges nécessaires à l'accomplissement de leur fonction. Cela n'empêchera pas une attaque, mais si une brèche se produit, les dommages seront minimisés.
La plupart des langages de programmation et des frameworks fournissent des appels API pour les méthodes courantes du système d'exploitation, telles que l'énumération du contenu des répertoires, la création ou la lecture de fichiers sur le disque dur. Un moyen idéal d'éliminer les injections de commandes du système d'exploitation de votre environnement consiste à faire en sorte que toutes les applications utilisent ces appels d'API au lieu des commandes du système d'exploitation directement.
Lorsque cela n'est pas possible, validez les entrées de l'utilisateur avant de les utiliser dans les commandes du système d'exploitation. Les listes blanches peuvent être utilisées pour s'assurer que seul un petit ensemble de valeurs de confiance peut être utilisé. Techniquement, il est également possible d'utiliser une liste noire, mais les commandes autorisées étant probablement beaucoup moins nombreuses, l'établissement d'une liste blanche est presque toujours plus facile. N'oubliez pas d'inclure les paramètres POST et GET valides dans votre liste blanche, ainsi que les vecteurs d'entrée utilisateur souvent négligés comme les cookies.
Enfin, s'il n'existe pas d'API de programmation et qu'il n'est pas possible d'utiliser une liste blanche, utilisez une bibliothèque d'assainissement pour échapper à tout caractère spécial dans les entrées utilisateur avant de les utiliser dans les commandes du système d'exploitation.
Plus d'informations sur les attaques par injection de commandes du système d'exploitation
Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les attaques par injection de commandes du système d'exploitation. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Aperçu de la gestion des risques pour les développeurs
La gestion des risques pour les développeurs est une approche holistique et proactive de la sécurité des applications, axée sur les contributeurs au code plutôt que sur les bits et les octets de la couche d'application elle-même.
Sécurité dès la conception : Définir les meilleures pratiques, permettre aux développeurs et évaluer les résultats de la sécurité préventive
Dans ce document de recherche, les cofondateurs de Secure Code Warrior , Pieter Danhieux et Matias Madou, Ph.D., ainsi que des contributeurs experts, Chris Inglis, ancien directeur national américain de la cybernétique (aujourd'hui conseiller stratégique du Paladin Capital Group), et Devin Lynch, directeur principal du Paladin Global Institute, révèleront les principales conclusions de plus de vingt entretiens approfondis avec des responsables de la sécurité des entreprises, y compris des RSSI, un vice-président de la sécurité des applications et des professionnels de la sécurité des logiciels.
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Il est notoirement difficile de trouver des données significatives sur le succès des initiatives Secure-by-Design. Les RSSI sont souvent confrontés à des difficultés lorsqu'ils tentent de prouver le retour sur investissement (ROI) et la valeur commerciale des activités du programme de sécurité, tant au niveau des personnes que de l'entreprise. De plus, il est particulièrement difficile pour les entreprises d'obtenir des informations sur la façon dont leurs organisations sont comparées aux normes actuelles du secteur. La stratégie nationale de cybersécurité du président a mis les parties prenantes au défi d'"adopter la sécurité et la résilience dès la conception". Pour que les initiatives de conception sécurisée fonctionnent, il faut non seulement donner aux développeurs les compétences nécessaires pour assurer la sécurité du code, mais aussi garantir aux régulateurs que ces compétences sont en place. Dans cette présentation, nous partageons une myriade de données qualitatives et quantitatives, dérivées de sources primaires multiples, y compris des points de données internes collectés auprès de plus de 250 000 développeurs, des informations sur les clients basées sur des données, et des études publiques. En nous appuyant sur cette agrégation de points de données, nous visons à communiquer une vision de l'état actuel des initiatives Secure-by-Design dans de multiples secteurs verticaux. Le rapport explique en détail pourquoi cet espace est actuellement sous-utilisé, l'impact significatif qu'un programme de perfectionnement réussi peut avoir sur l'atténuation des risques de cybersécurité, et le potentiel d'élimination des catégories de vulnérabilités d'une base de code.
Services professionnels - Accélérer grâce à l'expertise
L'équipe des services de stratégie de programme (PSS) de Secure Code Warriorvous aide à construire, améliorer et optimiser votre programme de codage sécurisé. Que vous partiez de zéro ou que vous affiniez votre approche, nos experts vous fournissent des conseils sur mesure.
Ressources pour vous aider à démarrer
Révélation : Comment l'industrie du cyberespace définit la notion de "Secure by Design" (sécurité dès la conception)
Dans notre dernier livre blanc, nos cofondateurs, Pieter Danhieux et Matias Madou, Ph.D., ont rencontré plus de vingt responsables de la sécurité d'entreprise, notamment des RSSI, des responsables AppSec et des professionnels de la sécurité, afin d'identifier les principales pièces de ce puzzle et de découvrir la réalité qui se cache derrière le mouvement Secure by Design. Il s'agit d'une ambition partagée par les équipes de sécurité, mais il n'y a pas de manuel de jeu commun.
Vibe Coding va-t-il transformer votre base de code en une fête de fraternité ?
Le codage vibratoire est comme une fête de fraternité universitaire, et l'IA est la pièce maîtresse de toutes les festivités, le tonneau. C'est très amusant de se laisser aller, d'être créatif et de voir où votre imagination peut vous mener, mais après quelques barils, boire (ou utiliser l'IA) avec modération est sans aucun doute la solution la plus sûre à long terme.