Qu'est-ce qu'un cheval de Troie source et comment s'introduit-il dans votre code source ?
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est intéressée à la manière dont il est possible de dissimuler des portes dérobées dans le code source et les commentaires, en utilisant des caractères de formatage directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien que Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple pour masquer l'extension réelle d'un fichier en inversant l'ordre de la dernière partie du nom du fichier. Des recherches récentes ont révélé que de nombreux compilateurs ignorent les caractères Unicode du code source sans avertissement préalable, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ceux-ci. Par conséquent, il est possible que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analysera, voire qu'il échange le code et les commentaires.
Veuillez continuer votre lecture pour obtenir davantage d'informations. Si vous souhaitez vous lancer et tester le piratage simulé de Trojan Source, veuillez accéder à notre page gratuite et à notre mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques de Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui gère la manière d'assembler du texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de format directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des personnages supprimés de Bidi liés à l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, isolation directionnelle pop) et le lira de droite à gauche. Le résultat sera le suivant :
c a d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les annulations Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de format directionnel, ils analyseront :
e d a c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'a rien de nouveau. Par le passé, des caractères de format directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail apparaissant sous le nom « myspecialexe.doc » pourrait sembler tout à fait inoffensive si ce n'était la présence du caractère RLO (annulation de droite à gauche) qui révèle que le nom réel est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de format directionnel dans les commentaires et les chaînes présents dans le code source, car ils ne génèrent aucune erreur de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce qu'un humain lirait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé de la manière suivante en fonction des caractères de format directionnel
en faisant en sorte que le code soit représenté de la manière suivante si les caractères de format directionnel ne sont pas explicitement invoqués :
Le RLO transforme le corset de fermeture en un corset d'ouverture et vice versa dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification de l'administration était commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Comment cela peut-il vous affecter ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il en existe probablement d'autres. Cependant, si un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnel dans le code source, un novice pourrait simplement ignorer ce problème. De plus, l'affichage de ces caractères dépend largement de l'IDE, il n'y a donc aucune garantie qu'ils seront détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source en premier lieu ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources peu fiables, dans lesquelles des contributions de code malveillant sont passées inaperçues. Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart des développeurs ont déjà fait. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question de savoir dans quelle mesure nous pouvons avoir pleinement confiance en ce code. Comment pouvons-nous détecter le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité de ce problème ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les lignes de code source comportant plus d'une direction, à moins qu'une direction ne soit strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de format directionnel dans une chaîne ou un commentaire peut, s'il n'apparaît pas, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent représenter et mettre en évidence explicitement les caractères Unicode suspects, tels que les homoglyphes et les caractères de format directionnel. Depuis novembre, GitHub ajoute désormais un signal et un message d'avertissement à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement exact de ces caractères dans la ligne. Cela peut encore permettre l'introduction de changements de direction malveillants en même temps que des changements de direction inoffensifs.
Il est essentiel que les développeurs et les réviseurs de code soient sensibilisés à cette question. C'est pourquoi nous avons créé un tutoriel illustrant cette vulnérabilité. Actuellement, ce tutoriel est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur 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é.
Veuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est intéressée à la manière dont il est possible de dissimuler des portes dérobées dans le code source et les commentaires, en utilisant des caractères de formatage directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien que Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple pour masquer l'extension réelle d'un fichier en inversant l'ordre de la dernière partie du nom du fichier. Des recherches récentes ont révélé que de nombreux compilateurs ignorent les caractères Unicode du code source sans avertissement préalable, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ceux-ci. Par conséquent, il est possible que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analysera, voire qu'il échange le code et les commentaires.
Veuillez continuer votre lecture pour obtenir davantage d'informations. Si vous souhaitez vous lancer et tester le piratage simulé de Trojan Source, veuillez accéder à notre page gratuite et à notre mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques de Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui gère la manière d'assembler du texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de format directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des personnages supprimés de Bidi liés à l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, isolation directionnelle pop) et le lira de droite à gauche. Le résultat sera le suivant :
c a d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les annulations Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de format directionnel, ils analyseront :
e d a c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'a rien de nouveau. Par le passé, des caractères de format directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail apparaissant sous le nom « myspecialexe.doc » pourrait sembler tout à fait inoffensive si ce n'était la présence du caractère RLO (annulation de droite à gauche) qui révèle que le nom réel est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de format directionnel dans les commentaires et les chaînes présents dans le code source, car ils ne génèrent aucune erreur de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce qu'un humain lirait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé de la manière suivante en fonction des caractères de format directionnel
en faisant en sorte que le code soit représenté de la manière suivante si les caractères de format directionnel ne sont pas explicitement invoqués :
Le RLO transforme le corset de fermeture en un corset d'ouverture et vice versa dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification de l'administration était commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Comment cela peut-il vous affecter ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il en existe probablement d'autres. Cependant, si un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnel dans le code source, un novice pourrait simplement ignorer ce problème. De plus, l'affichage de ces caractères dépend largement de l'IDE, il n'y a donc aucune garantie qu'ils seront détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source en premier lieu ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources peu fiables, dans lesquelles des contributions de code malveillant sont passées inaperçues. Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart des développeurs ont déjà fait. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question de savoir dans quelle mesure nous pouvons avoir pleinement confiance en ce code. Comment pouvons-nous détecter le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité de ce problème ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les lignes de code source comportant plus d'une direction, à moins qu'une direction ne soit strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de format directionnel dans une chaîne ou un commentaire peut, s'il n'apparaît pas, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent représenter et mettre en évidence explicitement les caractères Unicode suspects, tels que les homoglyphes et les caractères de format directionnel. Depuis novembre, GitHub ajoute désormais un signal et un message d'avertissement à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement exact de ces caractères dans la ligne. Cela peut encore permettre l'introduction de changements de direction malveillants en même temps que des changements de direction inoffensifs.
Il est essentiel que les développeurs et les réviseurs de code soient sensibilisés à cette question. C'est pourquoi nous avons créé un tutoriel illustrant cette vulnérabilité. Actuellement, ce tutoriel est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est intéressée à la manière dont il est possible de dissimuler des portes dérobées dans le code source et les commentaires, en utilisant des caractères de formatage directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien que Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple pour masquer l'extension réelle d'un fichier en inversant l'ordre de la dernière partie du nom du fichier. Des recherches récentes ont révélé que de nombreux compilateurs ignorent les caractères Unicode du code source sans avertissement préalable, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ceux-ci. Par conséquent, il est possible que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analysera, voire qu'il échange le code et les commentaires.
Veuillez continuer votre lecture pour obtenir davantage d'informations. Si vous souhaitez vous lancer et tester le piratage simulé de Trojan Source, veuillez accéder à notre page gratuite et à notre mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques de Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui gère la manière d'assembler du texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de format directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des personnages supprimés de Bidi liés à l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, isolation directionnelle pop) et le lira de droite à gauche. Le résultat sera le suivant :
c a d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les annulations Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de format directionnel, ils analyseront :
e d a c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'a rien de nouveau. Par le passé, des caractères de format directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail apparaissant sous le nom « myspecialexe.doc » pourrait sembler tout à fait inoffensive si ce n'était la présence du caractère RLO (annulation de droite à gauche) qui révèle que le nom réel est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de format directionnel dans les commentaires et les chaînes présents dans le code source, car ils ne génèrent aucune erreur de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce qu'un humain lirait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé de la manière suivante en fonction des caractères de format directionnel
en faisant en sorte que le code soit représenté de la manière suivante si les caractères de format directionnel ne sont pas explicitement invoqués :
Le RLO transforme le corset de fermeture en un corset d'ouverture et vice versa dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification de l'administration était commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Comment cela peut-il vous affecter ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il en existe probablement d'autres. Cependant, si un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnel dans le code source, un novice pourrait simplement ignorer ce problème. De plus, l'affichage de ces caractères dépend largement de l'IDE, il n'y a donc aucune garantie qu'ils seront détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source en premier lieu ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources peu fiables, dans lesquelles des contributions de code malveillant sont passées inaperçues. Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart des développeurs ont déjà fait. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question de savoir dans quelle mesure nous pouvons avoir pleinement confiance en ce code. Comment pouvons-nous détecter le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité de ce problème ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les lignes de code source comportant plus d'une direction, à moins qu'une direction ne soit strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de format directionnel dans une chaîne ou un commentaire peut, s'il n'apparaît pas, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent représenter et mettre en évidence explicitement les caractères Unicode suspects, tels que les homoglyphes et les caractères de format directionnel. Depuis novembre, GitHub ajoute désormais un signal et un message d'avertissement à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement exact de ces caractères dans la ligne. Cela peut encore permettre l'introduction de changements de direction malveillants en même temps que des changements de direction inoffensifs.
Il est essentiel que les développeurs et les réviseurs de code soient sensibilisés à cette question. C'est pourquoi nous avons créé un tutoriel illustrant cette vulnérabilité. Actuellement, ce tutoriel est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur 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é.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est intéressée à la manière dont il est possible de dissimuler des portes dérobées dans le code source et les commentaires, en utilisant des caractères de formatage directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur et par un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien que Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple pour masquer l'extension réelle d'un fichier en inversant l'ordre de la dernière partie du nom du fichier. Des recherches récentes ont révélé que de nombreux compilateurs ignorent les caractères Unicode du code source sans avertissement préalable, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ceux-ci. Par conséquent, il est possible que l'éditeur affiche le code et les commentaires différemment et dans un ordre différent de celui dans lequel le compilateur les analysera, voire qu'il échange le code et les commentaires.
Veuillez continuer votre lecture pour obtenir davantage d'informations. Si vous souhaitez vous lancer et tester le piratage simulé de Trojan Source, veuillez accéder à notre page gratuite et à notre mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques de Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui gère la manière d'assembler du texte avec un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de format directionnel peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des personnages supprimés de Bidi liés à l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « isoler de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, isolation directionnelle pop) et le lira de droite à gauche. Le résultat sera le suivant :
c a d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les annulations Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de format directionnel, ils analyseront :
e d a c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'a rien de nouveau. Par le passé, des caractères de format directionnel étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail apparaissant sous le nom « myspecialexe.doc » pourrait sembler tout à fait inoffensive si ce n'était la présence du caractère RLO (annulation de droite à gauche) qui révèle que le nom réel est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de format directionnel dans les commentaires et les chaînes présents dans le code source, car ils ne génèrent aucune erreur de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce qu'un humain lirait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé de la manière suivante en fonction des caractères de format directionnel
en faisant en sorte que le code soit représenté de la manière suivante si les caractères de format directionnel ne sont pas explicitement invoqués :
Le RLO transforme le corset de fermeture en un corset d'ouverture et vice versa dans la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes un administrateur ». La vérification de l'administration était commentée, mais les caractères de contrôle donnent l'impression qu'elle était toujours présente.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Comment cela peut-il vous affecter ?
De nombreux langages sont vulnérables à cette attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il en existe probablement d'autres. Cependant, si un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnel dans le code source, un novice pourrait simplement ignorer ce problème. De plus, l'affichage de ces caractères dépend largement de l'IDE, il n'y a donc aucune garantie qu'ils seront détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source en premier lieu ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources peu fiables, dans lesquelles des contributions de code malveillant sont passées inaperçues. Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart des développeurs ont déjà fait. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question de savoir dans quelle mesure nous pouvons avoir pleinement confiance en ce code. Comment pouvons-nous détecter le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité de ce problème ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les lignes de code source comportant plus d'une direction, à moins qu'une direction ne soit strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de format directionnel dans une chaîne ou un commentaire peut, s'il n'apparaît pas, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent représenter et mettre en évidence explicitement les caractères Unicode suspects, tels que les homoglyphes et les caractères de format directionnel. Depuis novembre, GitHub ajoute désormais un signal et un message d'avertissement à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement exact de ces caractères dans la ligne. Cela peut encore permettre l'introduction de changements de direction malveillants en même temps que des changements de direction inoffensifs.
Il est essentiel que les développeurs et les réviseurs de code soient sensibilisés à cette question. C'est pourquoi nous avons créé un tutoriel illustrant cette vulnérabilité. Actuellement, ce tutoriel est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions publiques) de Trojan Source et à consulter la recherche sur les sources troyennes.
Table des matières
Secure Code Warrior là pour aider votre organisation à protéger le code tout au long du cycle de vie du développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez administrateur 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é.
Veuillez réserver une démonstration.TéléchargerRessources pour débuter
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu de pointe évolue constamment afin de s'adapter au paysage changeant du développement logiciel, en tenant compte de votre rôle. Nous proposons des thèmes allant de l'IA à l'injection XQuery pour différents postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par thème et par fonction.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions IA de Beat the Boss sont désormais disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année chez SCW. Mettez en œuvre des défis de sécurité avancés basés sur l'IA et le LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer grâce à des pratiques de conception sécurisées, à la prévention des vulnérabilités et au développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en 10 parties intitulée « Les catalyseurs de la réussite », qui montre comment relier la codification sécurisée aux résultats commerciaux, tels que la réduction des risques et la rapidité d'atteinte de la maturité du programme à long terme.
