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 Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
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.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchen
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.
Inhaltsverzeichnis
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.
