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 aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostración
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.
Haga clic en el enlace siguiente y descargue el PDF de este recurso.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Mostrar el informeReserve una demostración
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.
Índice
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónDescargarRecursos para ayudarle a empezar
Temas y contenidos de formación sobre el código seguro
Nuestro contenido de vanguardia evoluciona constantemente para adaptarse al panorama en constante cambio del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la IA hasta la inyección de XQuery, ofrecidos para una variedad de puestos, desde arquitectos hasta ingenieros, pasando por jefes de producto y control de calidad. Descubra una visión general de lo que nuestro catálogo de contenidos tiene para ofrecer por tema y por función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para ayudarle a empezar
Cybermon está de vuelta: las missions Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible todo el año en SCW. Implemente desafíos de seguridad avanzados relacionados con la IA y el LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la ley sobre ciberresiliencia: lo que significa para el desarrollo de software seguro desde el diseño.
Descubra qué exige la ley europea sobre ciberresiliencia (CRA), a quién se aplica y cómo los equipos de ingenieros pueden prepararse mediante prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el refuerzo de las capacidades de los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 da inicio a nuestra serie de 10 partes titulada «Facilitadores del éxito», mostrando cómo combinar la codificación segura con resultados comerciales, como la reducción de riesgos y la rapidez, para garantizar la madurez a largo plazo de los programas.
