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 ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
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.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
レポートを表示するデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
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.
%20(1).avif)
.avif)
