Qu'est-ce que Trojan Source et comment se faufile-t-il dans votre code source
Début novembre, l'université de Cambridge a publié son recherche appelée Trojan-Source. Cette recherche s'est concentrée sur la manière dont les portes dérobées peuvent être masquées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ils 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 été utilisé de manière malveillante par le passé, par exemple en masquant la véritable extension du nom de fichier d'un fichier par inverser le sens de la dernière partie d'un nom de fichier. Les 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 du code et des commentaires.
Lisez la suite pour en savoir plus. Ou si vous souhaitez vous retrousser les manches et essayer le piratage simulé de Trojan Source, rendez-vous sur notre site gratuit et mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de rassembler 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 de Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI e d à c PDI
L'abréviation RLI signifie Isolat de droite à gauche. Il 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 vieux vin dans de nouvelles bouteilles ?
Bien entendu, cela n'a rien de nouveau sous le soleil. Dans le passé, les caractères de mise en forme directionnelle étaient inséré dans les noms de fichiers pour masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le RLO (Remplacer de droite à gauche) caractère 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 à lire quelque chose de complètement différent de ce que ferait un humain.
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 ceci si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO fait basculer l'entretoise de fermeture en une entretoise d'ouverture, et vice versa 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 vulnérables à l'attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il y en a d'autres. Maintenant, 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 rien y penser. 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 faire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, ont déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela pose la question de savoir dans quelle mesure pouvons-nous faire totalement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
C'est le problème de qui ?
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. Notez 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 pas à pas illustrant cette vulnérabilité. Actuellement, cette procédure pas à pas est disponible pour Java, C#, Python, GO et PHP.
Alors si vous voulez en savoir plus, essayez notre simulation (missions publiques) de Trojan Source, et lisez le Recherche sur Trojan Source.
Secure Code Warrior est 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é.
Réservez une démo
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é son recherche appelée Trojan-Source. Cette recherche s'est concentrée sur la manière dont les portes dérobées peuvent être masquées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ils 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 été utilisé de manière malveillante par le passé, par exemple en masquant la véritable extension du nom de fichier d'un fichier par inverser le sens de la dernière partie d'un nom de fichier. Les 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 du code et des commentaires.
Lisez la suite pour en savoir plus. Ou si vous souhaitez vous retrousser les manches et essayer le piratage simulé de Trojan Source, rendez-vous sur notre site gratuit et mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de rassembler 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 de Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI e d à c PDI
L'abréviation RLI signifie Isolat de droite à gauche. Il 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 vieux vin dans de nouvelles bouteilles ?
Bien entendu, cela n'a rien de nouveau sous le soleil. Dans le passé, les caractères de mise en forme directionnelle étaient inséré dans les noms de fichiers pour masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le RLO (Remplacer de droite à gauche) caractère 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 à lire quelque chose de complètement différent de ce que ferait un humain.
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 ceci si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO fait basculer l'entretoise de fermeture en une entretoise d'ouverture, et vice versa 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 vulnérables à l'attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il y en a d'autres. Maintenant, 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 rien y penser. 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 faire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, ont déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela pose la question de savoir dans quelle mesure pouvons-nous faire totalement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
C'est le problème de qui ?
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. Notez 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 pas à pas illustrant cette vulnérabilité. Actuellement, cette procédure pas à pas est disponible pour Java, C#, Python, GO et PHP.
Alors si vous voulez en savoir plus, essayez notre simulation (missions publiques) de Trojan Source, et lisez le Recherche sur Trojan Source.
Début novembre, l'université de Cambridge a publié son recherche appelée Trojan-Source. Cette recherche s'est concentrée sur la manière dont les portes dérobées peuvent être masquées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ils 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 été utilisé de manière malveillante par le passé, par exemple en masquant la véritable extension du nom de fichier d'un fichier par inverser le sens de la dernière partie d'un nom de fichier. Les 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 du code et des commentaires.
Lisez la suite pour en savoir plus. Ou si vous souhaitez vous retrousser les manches et essayer le piratage simulé de Trojan Source, rendez-vous sur notre site gratuit et mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de rassembler 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 de Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI e d à c PDI
L'abréviation RLI signifie Isolat de droite à gauche. Il 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 vieux vin dans de nouvelles bouteilles ?
Bien entendu, cela n'a rien de nouveau sous le soleil. Dans le passé, les caractères de mise en forme directionnelle étaient inséré dans les noms de fichiers pour masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le RLO (Remplacer de droite à gauche) caractère 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 à lire quelque chose de complètement différent de ce que ferait un humain.
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 ceci si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO fait basculer l'entretoise de fermeture en une entretoise d'ouverture, et vice versa 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 vulnérables à l'attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il y en a d'autres. Maintenant, 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 rien y penser. 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 faire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, ont déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela pose la question de savoir dans quelle mesure pouvons-nous faire totalement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
C'est le problème de qui ?
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. Notez 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 pas à pas illustrant cette vulnérabilité. Actuellement, cette procédure pas à pas est disponible pour Java, C#, Python, GO et PHP.
Alors si vous voulez en savoir plus, essayez notre simulation (missions publiques) de Trojan Source, et lisez le Recherche sur Trojan Source.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est 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é.
Afficher le rapportRéservez une démo
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é son recherche appelée Trojan-Source. Cette recherche s'est concentrée sur la manière dont les portes dérobées peuvent être masquées dans le code source et les commentaires, à l'aide de caractères de mise en forme directionnels. Ils 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 été utilisé de manière malveillante par le passé, par exemple en masquant la véritable extension du nom de fichier d'un fichier par inverser le sens de la dernière partie d'un nom de fichier. Les 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 du code et des commentaires.
Lisez la suite pour en savoir plus. Ou si vous souhaitez vous retrousser les manches et essayer le piratage simulé de Trojan Source, rendez-vous sur notre site gratuit et mission publique pour en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques Trojan-Source utilise l'algorithme Unicode Bidi (bidirectionnel), qui permet de rassembler 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 de Bidi pertinents pour l'attaque. Prenons, par exemple,
RLI e d à c PDI
L'abréviation RLI signifie Isolat de droite à gauche. Il 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 vieux vin dans de nouvelles bouteilles ?
Bien entendu, cela n'a rien de nouveau sous le soleil. Dans le passé, les caractères de mise en forme directionnelle étaient inséré dans les noms de fichiers pour masquer leur nature malveillante. Une pièce jointe à un e-mail affichée sous la forme « myspecialexe.doc » pourrait sembler assez innocente, sans le RLO (Remplacer de droite à gauche) caractère 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 à lire quelque chose de complètement différent de ce que ferait un humain.
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 ceci si les caractères de mise en forme directionnels ne sont pas explicitement appelés :
Le RLO fait basculer l'entretoise de fermeture en une entretoise d'ouverture, et vice versa 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 vulnérables à l'attaque : C, C++, C#, JavaScript, Java, Rust, Go et Python, et on suppose qu'il y en a d'autres. Maintenant, 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 rien y penser. 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 faire par un simple copier-coller à partir de code trouvé sur Internet, ce que la plupart d'entre nous, développeurs, ont déjà fait auparavant. La plupart des organisations s'appuient sur des composants logiciels provenant de plusieurs fournisseurs. Cela pose la question de savoir dans quelle mesure pouvons-nous faire totalement confiance à ce code et nous y fier ? Comment pouvons-nous rechercher le code source contenant des portes dérobées cachées ?
C'est le problème de qui ?
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. Notez 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 pas à pas illustrant cette vulnérabilité. Actuellement, cette procédure pas à pas est disponible pour Java, C#, Python, GO et PHP.
Alors si vous voulez en savoir plus, essayez notre simulation (missions publiques) de Trojan Source, et lisez le Recherche sur Trojan Source.
Table des matières
Secure Code Warrior est 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é.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets 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.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à 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 définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
