Qu'est-ce que Trojan Source et comment s'introduit-il dans votre code source ?
Début novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est concentrée sur la manière dont les portes dérobées peuvent être dissimulées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur par rapport à un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien qu'Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple en dissimulant 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, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent redistribuer les lignes contenant des commentaires et du code basé sur ceux-ci. Ainsi, l'éditeur peut afficher le code et les commentaires différemment et dans un ordre différent de la façon dont le compilateur les analysera, voire en échangeant le code et les commentaires.
Veuillez lire la suite pour obtenir plus d'informations. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à visiter notre site gratuit et notre mission publique afin de vivre cette expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de regrouper du texte dans un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de mise en forme directionnelle peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « Isolation de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, Isolation directionnelle pop) et le lira de droite à gauche. Résultat :
c ou d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de mise en forme, y compris les remplacements Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de mise en forme directionnelle, ils analyseront :
e d à c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'est pas nouveau. Dans le passé, des caractères de mise en forme directionnelle étaient insérés dans les noms de fichiers afin de masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le caractère RLO (Remplacer de droite à gauche) présent qui révèle que le vrai nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de mise en forme directionnels dans les commentaires et les chaînes présents dans le code source, car ils ne généreront 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 amène le compilateur à interpréter quelque chose de complètement différent de ce qu'un humain comprendrait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit en fonction des caractères de mise en forme directionnels
provoquant le rendu du code comme suit si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO transforme l'entretoise de fermeture en une entretoise d'ouverture, et inversement sur la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes administrateur ». La vérification d'administration a été 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 pourrait-il vous affecter ?
De nombreux langages sont susceptibles d'être affectés par cette vulnérabilité : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il est probable qu'il y en ait d'autres. À présent, le développeur moyen peut froncer les sourcils en voyant des caractères de mise en forme directionnelle dans le code source, mais un novice pourrait tout aussi bien hausser les épaules et ne pas y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc jamais garanti qu'ils seront repérés.
Mais comment cette vulnérabilité a-t-elle pu se faufiler dans le code source ? Tout d'abord, cela peut se produire lors de l'utilisation de code source provenant de sources non fiables, où les contributions de code malveillant sont passées inaperçues. Deuxièmement, cela peut se produire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
À qui incombe ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plusieurs directions, sauf si l'une des directions est strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de mise en forme directionnel dans une chaîne ou un commentaire peut, s'il n'est pas affiché, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent afficher et mettre en évidence de manière explicite les caractères Unicode suspects, tels que les homoglyphes et les caractères de mise en forme directionnelle. Depuis novembre, GitHub ajoute désormais un signe d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères sur la ligne. Cela peut tout de même permettre à des changements de direction malveillants de se faufiler, ainsi qu'à des changements de direction bénins.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé une procédure étape par étape illustrant cette vulnérabilité. Actuellement, cette procédure étape par étape est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions ) de Trojan Source et à consulter la Recherche sur Trojan Source.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Début novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est concentrée sur la manière dont les portes dérobées peuvent être dissimulées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur par rapport à un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien qu'Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple en dissimulant 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, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent redistribuer les lignes contenant des commentaires et du code basé sur ceux-ci. Ainsi, l'éditeur peut afficher le code et les commentaires différemment et dans un ordre différent de la façon dont le compilateur les analysera, voire en échangeant le code et les commentaires.
Veuillez lire la suite pour obtenir plus d'informations. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à visiter notre site gratuit et notre mission publique afin de vivre cette expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de regrouper du texte dans un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de mise en forme directionnelle peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « Isolation de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, Isolation directionnelle pop) et le lira de droite à gauche. Résultat :
c ou d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de mise en forme, y compris les remplacements Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de mise en forme directionnelle, ils analyseront :
e d à c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'est pas nouveau. Dans le passé, des caractères de mise en forme directionnelle étaient insérés dans les noms de fichiers afin de masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le caractère RLO (Remplacer de droite à gauche) présent qui révèle que le vrai nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de mise en forme directionnels dans les commentaires et les chaînes présents dans le code source, car ils ne généreront 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 amène le compilateur à interpréter quelque chose de complètement différent de ce qu'un humain comprendrait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit en fonction des caractères de mise en forme directionnels
provoquant le rendu du code comme suit si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO transforme l'entretoise de fermeture en une entretoise d'ouverture, et inversement sur la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes administrateur ». La vérification d'administration a été 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 pourrait-il vous affecter ?
De nombreux langages sont susceptibles d'être affectés par cette vulnérabilité : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il est probable qu'il y en ait d'autres. À présent, le développeur moyen peut froncer les sourcils en voyant des caractères de mise en forme directionnelle dans le code source, mais un novice pourrait tout aussi bien hausser les épaules et ne pas y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc jamais garanti qu'ils seront repérés.
Mais comment cette vulnérabilité a-t-elle pu se faufiler dans le code source ? Tout d'abord, cela peut se produire lors de l'utilisation de code source provenant de sources non fiables, où les contributions de code malveillant sont passées inaperçues. Deuxièmement, cela peut se produire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
À qui incombe ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plusieurs directions, sauf si l'une des directions est strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de mise en forme directionnel dans une chaîne ou un commentaire peut, s'il n'est pas affiché, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent afficher et mettre en évidence de manière explicite les caractères Unicode suspects, tels que les homoglyphes et les caractères de mise en forme directionnelle. Depuis novembre, GitHub ajoute désormais un signe d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères sur la ligne. Cela peut tout de même permettre à des changements de direction malveillants de se faufiler, ainsi qu'à des changements de direction bénins.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé une procédure étape par étape illustrant cette vulnérabilité. Actuellement, cette procédure étape par étape est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions ) de Trojan Source et à consulter la Recherche sur Trojan Source.
Début novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est concentrée sur la manière dont les portes dérobées peuvent être dissimulées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur par rapport à un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien qu'Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple en dissimulant 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, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent redistribuer les lignes contenant des commentaires et du code basé sur ceux-ci. Ainsi, l'éditeur peut afficher le code et les commentaires différemment et dans un ordre différent de la façon dont le compilateur les analysera, voire en échangeant le code et les commentaires.
Veuillez lire la suite pour obtenir plus d'informations. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à visiter notre site gratuit et notre mission publique afin de vivre cette expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de regrouper du texte dans un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de mise en forme directionnelle peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « Isolation de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, Isolation directionnelle pop) et le lira de droite à gauche. Résultat :
c ou d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de mise en forme, y compris les remplacements Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de mise en forme directionnelle, ils analyseront :
e d à c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'est pas nouveau. Dans le passé, des caractères de mise en forme directionnelle étaient insérés dans les noms de fichiers afin de masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le caractère RLO (Remplacer de droite à gauche) présent qui révèle que le vrai nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de mise en forme directionnels dans les commentaires et les chaînes présents dans le code source, car ils ne généreront 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 amène le compilateur à interpréter quelque chose de complètement différent de ce qu'un humain comprendrait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit en fonction des caractères de mise en forme directionnels
provoquant le rendu du code comme suit si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO transforme l'entretoise de fermeture en une entretoise d'ouverture, et inversement sur la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes administrateur ». La vérification d'administration a été 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 pourrait-il vous affecter ?
De nombreux langages sont susceptibles d'être affectés par cette vulnérabilité : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il est probable qu'il y en ait d'autres. À présent, le développeur moyen peut froncer les sourcils en voyant des caractères de mise en forme directionnelle dans le code source, mais un novice pourrait tout aussi bien hausser les épaules et ne pas y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc jamais garanti qu'ils seront repérés.
Mais comment cette vulnérabilité a-t-elle pu se faufiler dans le code source ? Tout d'abord, cela peut se produire lors de l'utilisation de code source provenant de sources non fiables, où les contributions de code malveillant sont passées inaperçues. Deuxièmement, cela peut se produire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
À qui incombe ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plusieurs directions, sauf si l'une des directions est strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de mise en forme directionnel dans une chaîne ou un commentaire peut, s'il n'est pas affiché, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent afficher et mettre en évidence de manière explicite les caractères Unicode suspects, tels que les homoglyphes et les caractères de mise en forme directionnelle. Depuis novembre, GitHub ajoute désormais un signe d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères sur la ligne. Cela peut tout de même permettre à des changements de direction malveillants de se faufiler, ainsi qu'à des changements de direction bénins.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé une procédure étape par étape illustrant cette vulnérabilité. Actuellement, cette procédure étape par étape est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions ) de Trojan Source et à consulter la Recherche sur Trojan Source.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Début novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude s'est concentrée sur la manière dont les portes dérobées peuvent être dissimulées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ceux-ci peuvent être utilisés pour créer du code dont la logique est interprétée différemment par le compilateur par rapport à un réviseur de code humain.
Cette vulnérabilité est nouvelle, bien qu'Unicode ait déjà été utilisé de manière malveillante par le passé, par exemple en dissimulant 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, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent redistribuer les lignes contenant des commentaires et du code basé sur ceux-ci. Ainsi, l'éditeur peut afficher le code et les commentaires différemment et dans un ordre différent de la façon dont le compilateur les analysera, voire en échangeant le code et les commentaires.
Veuillez lire la suite pour obtenir plus d'informations. Si vous souhaitez vous impliquer et essayer le piratage simulé de Trojan Source, nous vous invitons à visiter notre site gratuit et notre mission publique afin de vivre cette expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de regrouper du texte dans un ordre d'affichage différent, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Les caractères de mise en forme directionnelle peuvent être utilisés pour réorganiser le regroupement et afficher l'ordre des caractères.
Le tableau ci-dessus contient certains des caractères de remplacement Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI et PDI
L'abréviation RLI signifie « Isolation de droite à gauche ». Elle isolera le texte de son contexte (délimité par PDI, Isolation directionnelle pop) et le lira de droite à gauche. Résultat :
c ou d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de mise en forme, y compris les remplacements Bidi, avant d'analyser le code source. S'ils ignorent simplement les caractères de mise en forme directionnelle, ils analyseront :
e d à c
Du vin ancien dans des bouteilles neuves ?
Bien entendu, cela n'est pas nouveau. Dans le passé, des caractères de mise en forme directionnelle étaient insérés dans les noms de fichiers afin de masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le caractère RLO (Remplacer de droite à gauche) présent qui révèle que le vrai nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de mise en forme directionnels dans les commentaires et les chaînes présents dans le code source, car ils ne généreront 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 amène le compilateur à interpréter quelque chose de complètement différent de ce qu'un humain comprendrait.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
sera réorganisé comme suit en fonction des caractères de mise en forme directionnels
provoquant le rendu du code comme suit si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO transforme l'entretoise de fermeture en une entretoise d'ouverture, et inversement sur la dernière ligne. Le résultat de l'exécution de ce code serait : « Vous êtes administrateur ». La vérification d'administration a été 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 pourrait-il vous affecter ?
De nombreux langages sont susceptibles d'être affectés par cette vulnérabilité : C, C++, C#, JavaScript, Java, Rust, Go et Python, et il est probable qu'il y en ait d'autres. À présent, le développeur moyen peut froncer les sourcils en voyant des caractères de mise en forme directionnelle dans le code source, mais un novice pourrait tout aussi bien hausser les épaules et ne pas y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc jamais garanti qu'ils seront repérés.
Mais comment cette vulnérabilité a-t-elle pu se faufiler dans le code source ? Tout d'abord, cela peut se produire lors de l'utilisation de code source provenant de sources non fiables, où les contributions de code malveillant sont passées inaperçues. Deuxièmement, cela peut se produire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, avons déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
À qui incombe ce problème ?
D'une part, les compilateurs et les pipelines de compilation devraient interdire les lignes de code source comportant plusieurs directions, sauf si l'une des directions est strictement limitée aux chaînes et aux commentaires. Veuillez noter qu'un caractère de mise en forme directionnel dans une chaîne ou un commentaire peut, s'il n'est pas affiché, prolonger un changement de direction jusqu'à la fin de la ligne. En général, les éditeurs de code doivent afficher et mettre en évidence de manière explicite les caractères Unicode suspects, tels que les homoglyphes et les caractères de mise en forme directionnelle. Depuis novembre, GitHub ajoute désormais un signe d'avertissement et un message à chaque ligne de code contenant du texte Unicode bidirectionnel, bien qu'il ne mette pas en évidence l'emplacement de ces caractères sur la ligne. Cela peut tout de même permettre à des changements de direction malveillants de se faufiler, ainsi qu'à des changements de direction bénins.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé une procédure étape par étape illustrant cette vulnérabilité. Actuellement, cette procédure étape par étape est disponible pour Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation (missions ) de Trojan Source et à consulter la Recherche sur Trojan Source.
Table des matières
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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 vous aider à démarrer
Thèmes et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
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 vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au 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énieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
