Qu'est-ce qu'un cheval de Troie et comment s'introduit-il dans votre code source ?
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude se concentre sur la manière dont des caractères de formatage ciblés peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Ceux-ci peuvent être employés pour écrire du code que le compilateur interprète différemment de la manière dont un examinateur de code humain l'interpréterait.
Cette vulnérabilité est récente, bien que l'Unicode ait déjà été utilisé à des fins malveillantes, par exemple pour masquer l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ces caractères.Par conséquent, la manière dont les éditeurs affichent le code et les commentaires peut différer de celle utilisée par les compilateurs pour analyser le code et les commentaires, voire inverser le code et les commentaires.
Veuillez continuer votre lecture pour obtenir plus d'informations. Si vous préférez vous lancer et essayer la simulation de piratage informatique de Trojan Source, nous vous invitons à découvrir notre version gratuite Mission publique pour une expérience pratique.
Texte bidirectionnel
L'une des attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la manière dont les textes ayant des ordres d'affichage différents (par exemple, l'anglais (de gauche à droite) et l'arabe (de droite à gauche)) sont combinés. Les caractères de formatage directionnel peuvent être utilisés pour réorganiser les groupes et l'ordre d'affichage des caractères.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI e d o c PDI
L'acronyme RLI signifie « séparation de droite à gauche». Il sépare le texte de son contexte (séparé par PDI, séparation orientée vers le bas) et le lit de droite à gauche. Il en résulte :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnel, ils analyseront :
e d o c
Du vieux vin dans de nouvelles bouteilles ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, les caractères de formatage orientés étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Sans RLO, une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente (contrôle de droite à gauche), mais les caractères affichés révèlent que son véritable nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de formatage ciblés dans les commentaires et les chaînes de caractères du code source, car ces caractères ne génèrent aucune erreur syntaxique ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui conduit le compilateur à lire un contenu différent de celui lu par l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
Les caractères seront réorganisés selon le format indiqué ci-dessous.
Si aucun caractère de formatage n'est explicitement spécifié, le code s'affichera comme suit :
RLO remplace la parenthèse droite par une parenthèse gauche dans la dernière ligne, et inversement. Le résultat de l'exécution de ce code sera : « Vous êtes administrateur ». Le contrôle administrateur est commenté, mais le rôle de contrôle donne l'impression qu'il est toujours présent.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela aura-t-il sur vous ?
De nombreux langages sont vulnérables : C, C++, C#, JavaScript, Java, Rust, Go et Python, et probablement d'autres encore. À l'heure actuelle, les développeurs expérimentés peuvent ignorer les caractères de formatage ciblés dans le code source, tandis que les débutants peuvent simplement hausser les épaules sans y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source au départ ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources non fiables, sans que les contributions de code malveillant ne soient remarquées.Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart d'entre nous avons déjà fait. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment filtrer le code source contenant des portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation doivent empêcher l'utilisation de lignes de code source multidirectionnelles, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter que les caractères de formatage directionnel dans les chaînes de caractères ou les commentaires peuvent étendre le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas mis en évidence.En règle générale, les éditeurs de code doivent clairement afficher et mettre en évidence les caractères Unicode suspects, tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute désormais des avertissements et des messages dans le code contenant du texte Unicode bidirectionnel dans chaque ligne, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut encore permettre à des changements de direction malveillants et à des changements de direction bénins de se glisser dans le code.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé un exercice pour illustrer les vulnérabilités. Actuellement, cet exercice est disponible pour Java, C#, Python, GO et PHP.
Par conséquent, si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation Trojan Source (mission publique), puis à lire l'étude Trojan Source.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude se concentre sur la manière dont des caractères de formatage ciblés peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Ceux-ci peuvent être employés pour écrire du code que le compilateur interprète différemment de la manière dont un examinateur de code humain l'interpréterait.
Cette vulnérabilité est récente, bien que l'Unicode ait déjà été utilisé à des fins malveillantes, par exemple pour masquer l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ces caractères.Par conséquent, la manière dont les éditeurs affichent le code et les commentaires peut différer de celle utilisée par les compilateurs pour analyser le code et les commentaires, voire inverser le code et les commentaires.
Veuillez continuer votre lecture pour obtenir plus d'informations. Si vous préférez vous lancer et essayer la simulation de piratage informatique de Trojan Source, nous vous invitons à découvrir notre version gratuite Mission publique pour une expérience pratique.
Texte bidirectionnel
L'une des attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la manière dont les textes ayant des ordres d'affichage différents (par exemple, l'anglais (de gauche à droite) et l'arabe (de droite à gauche)) sont combinés. Les caractères de formatage directionnel peuvent être utilisés pour réorganiser les groupes et l'ordre d'affichage des caractères.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI e d o c PDI
L'acronyme RLI signifie « séparation de droite à gauche». Il sépare le texte de son contexte (séparé par PDI, séparation orientée vers le bas) et le lit de droite à gauche. Il en résulte :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnel, ils analyseront :
e d o c
Du vieux vin dans de nouvelles bouteilles ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, les caractères de formatage orientés étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Sans RLO, une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente (contrôle de droite à gauche), mais les caractères affichés révèlent que son véritable nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de formatage ciblés dans les commentaires et les chaînes de caractères du code source, car ces caractères ne génèrent aucune erreur syntaxique ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui conduit le compilateur à lire un contenu différent de celui lu par l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
Les caractères seront réorganisés selon le format indiqué ci-dessous.
Si aucun caractère de formatage n'est explicitement spécifié, le code s'affichera comme suit :
RLO remplace la parenthèse droite par une parenthèse gauche dans la dernière ligne, et inversement. Le résultat de l'exécution de ce code sera : « Vous êtes administrateur ». Le contrôle administrateur est commenté, mais le rôle de contrôle donne l'impression qu'il est toujours présent.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela aura-t-il sur vous ?
De nombreux langages sont vulnérables : C, C++, C#, JavaScript, Java, Rust, Go et Python, et probablement d'autres encore. À l'heure actuelle, les développeurs expérimentés peuvent ignorer les caractères de formatage ciblés dans le code source, tandis que les débutants peuvent simplement hausser les épaules sans y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source au départ ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources non fiables, sans que les contributions de code malveillant ne soient remarquées.Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart d'entre nous avons déjà fait. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment filtrer le code source contenant des portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation doivent empêcher l'utilisation de lignes de code source multidirectionnelles, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter que les caractères de formatage directionnel dans les chaînes de caractères ou les commentaires peuvent étendre le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas mis en évidence.En règle générale, les éditeurs de code doivent clairement afficher et mettre en évidence les caractères Unicode suspects, tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute désormais des avertissements et des messages dans le code contenant du texte Unicode bidirectionnel dans chaque ligne, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut encore permettre à des changements de direction malveillants et à des changements de direction bénins de se glisser dans le code.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé un exercice pour illustrer les vulnérabilités. Actuellement, cet exercice est disponible pour Java, C#, Python, GO et PHP.
Par conséquent, si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation Trojan Source (mission publique), puis à lire l'étude Trojan Source.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude se concentre sur la manière dont des caractères de formatage ciblés peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Ceux-ci peuvent être employés pour écrire du code que le compilateur interprète différemment de la manière dont un examinateur de code humain l'interpréterait.
Cette vulnérabilité est récente, bien que l'Unicode ait déjà été utilisé à des fins malveillantes, par exemple pour masquer l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ces caractères.Par conséquent, la manière dont les éditeurs affichent le code et les commentaires peut différer de celle utilisée par les compilateurs pour analyser le code et les commentaires, voire inverser le code et les commentaires.
Veuillez continuer votre lecture pour obtenir plus d'informations. Si vous préférez vous lancer et essayer la simulation de piratage informatique de Trojan Source, nous vous invitons à découvrir notre version gratuite Mission publique pour une expérience pratique.
Texte bidirectionnel
L'une des attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la manière dont les textes ayant des ordres d'affichage différents (par exemple, l'anglais (de gauche à droite) et l'arabe (de droite à gauche)) sont combinés. Les caractères de formatage directionnel peuvent être utilisés pour réorganiser les groupes et l'ordre d'affichage des caractères.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI e d o c PDI
L'acronyme RLI signifie « séparation de droite à gauche». Il sépare le texte de son contexte (séparé par PDI, séparation orientée vers le bas) et le lit de droite à gauche. Il en résulte :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnel, ils analyseront :
e d o c
Du vieux vin dans de nouvelles bouteilles ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, les caractères de formatage orientés étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Sans RLO, une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente (contrôle de droite à gauche), mais les caractères affichés révèlent que son véritable nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de formatage ciblés dans les commentaires et les chaînes de caractères du code source, car ces caractères ne génèrent aucune erreur syntaxique ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui conduit le compilateur à lire un contenu différent de celui lu par l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
Les caractères seront réorganisés selon le format indiqué ci-dessous.
Si aucun caractère de formatage n'est explicitement spécifié, le code s'affichera comme suit :
RLO remplace la parenthèse droite par une parenthèse gauche dans la dernière ligne, et inversement. Le résultat de l'exécution de ce code sera : « Vous êtes administrateur ». Le contrôle administrateur est commenté, mais le rôle de contrôle donne l'impression qu'il est toujours présent.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela aura-t-il sur vous ?
De nombreux langages sont vulnérables : C, C++, C#, JavaScript, Java, Rust, Go et Python, et probablement d'autres encore. À l'heure actuelle, les développeurs expérimentés peuvent ignorer les caractères de formatage ciblés dans le code source, tandis que les débutants peuvent simplement hausser les épaules sans y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source au départ ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources non fiables, sans que les contributions de code malveillant ne soient remarquées.Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart d'entre nous avons déjà fait. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment filtrer le code source contenant des portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation doivent empêcher l'utilisation de lignes de code source multidirectionnelles, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter que les caractères de formatage directionnel dans les chaînes de caractères ou les commentaires peuvent étendre le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas mis en évidence.En règle générale, les éditeurs de code doivent clairement afficher et mettre en évidence les caractères Unicode suspects, tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute désormais des avertissements et des messages dans le code contenant du texte Unicode bidirectionnel dans chaque ligne, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut encore permettre à des changements de direction malveillants et à des changements de direction bénins de se glisser dans le code.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé un exercice pour illustrer les vulnérabilités. Actuellement, cet exercice est disponible pour Java, C#, Python, GO et PHP.
Par conséquent, si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation Trojan Source (mission publique), puis à lire l'étude Trojan Source.
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez consulter le rapport.Veuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels à l'adresse Secure Code Warrior . Elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Missions et Coding labs.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée Trojan-Source. Cette étude se concentre sur la manière dont des caractères de formatage ciblés peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Ceux-ci peuvent être employés pour écrire du code que le compilateur interprète différemment de la manière dont un examinateur de code humain l'interpréterait.
Cette vulnérabilité est récente, bien que l'Unicode ait déjà été utilisé à des fins malveillantes, par exemple pour masquer l'extension réelle d'un fichier en inversant la direction de la dernière partie du nom du fichier. Des recherches récentes ont montré que de nombreux compilateurs ignorent les caractères Unicode dans le code source sans avertissement, tandis que les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et du code basé sur ces caractères.Par conséquent, la manière dont les éditeurs affichent le code et les commentaires peut différer de celle utilisée par les compilateurs pour analyser le code et les commentaires, voire inverser le code et les commentaires.
Veuillez continuer votre lecture pour obtenir plus d'informations. Si vous préférez vous lancer et essayer la simulation de piratage informatique de Trojan Source, nous vous invitons à découvrir notre version gratuite Mission publique pour une expérience pratique.
Texte bidirectionnel
L'une des attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel), qui traite la manière dont les textes ayant des ordres d'affichage différents (par exemple, l'anglais (de gauche à droite) et l'arabe (de droite à gauche)) sont combinés. Les caractères de formatage directionnel peuvent être utilisés pour réorganiser les groupes et l'ordre d'affichage des caractères.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI e d o c PDI
L'acronyme RLI signifie « séparation de droite à gauche». Il sépare le texte de son contexte (séparé par PDI, séparation orientée vers le bas) et le lit de droite à gauche. Il en résulte :
c o d e
Cependant, les compilateurs et les interpréteurs ne traitent généralement pas les caractères de contrôle de format, y compris les remplacements bidirectionnels, avant d'analyser le code source. S'ils ignorent simplement les caractères de formatage directionnel, ils analyseront :
e d o c
Du vieux vin dans de nouvelles bouteilles ?
Bien entendu, ce n'est pas une nouveauté. Par le passé, les caractères de formatage orientés étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Sans RLO, une pièce jointe à un e-mail affichée sous le nom « myspecialexe.doc » pourrait sembler tout à fait innocente (contrôle de droite à gauche), mais les caractères affichés révèlent que son véritable nom est « myspecialcod.exe ».
L'attaque Trojan Source insère des caractères de formatage ciblés dans les commentaires et les chaînes de caractères du code source, car ces caractères ne génèrent aucune erreur syntaxique ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui conduit le compilateur à lire un contenu différent de celui lu par l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans cet ordre :
Les caractères seront réorganisés selon le format indiqué ci-dessous.
Si aucun caractère de formatage n'est explicitement spécifié, le code s'affichera comme suit :
RLO remplace la parenthèse droite par une parenthèse gauche dans la dernière ligne, et inversement. Le résultat de l'exécution de ce code sera : « Vous êtes administrateur ». Le contrôle administrateur est commenté, mais le rôle de contrôle donne l'impression qu'il est toujours présent.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela aura-t-il sur vous ?
De nombreux langages sont vulnérables : C, C++, C#, JavaScript, Java, Rust, Go et Python, et probablement d'autres encore. À l'heure actuelle, les développeurs expérimentés peuvent ignorer les caractères de formatage ciblés dans le code source, tandis que les débutants peuvent simplement hausser les épaules sans y prêter attention. De plus, la visualisation de ces caractères dépend fortement de l'IDE, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité a-t-elle pu s'introduire dans le code source au départ ? Tout d'abord, cela peut se produire lorsque l'on utilise du code source provenant de sources non fiables, sans que les contributions de code malveillant ne soient remarquées.Ensuite, cela peut se produire simplement en copiant-collant du code trouvé sur Internet, ce que la plupart d'entre nous avons déjà fait. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. Cela soulève la question suivante : dans quelle mesure pouvons-nous faire entièrement confiance à ce code et nous y fier ? Comment filtrer le code source contenant des portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation doivent empêcher l'utilisation de lignes de code source multidirectionnelles, sauf si une direction est strictement limitée aux chaînes de caractères et aux commentaires. Veuillez noter que les caractères de formatage directionnel dans les chaînes de caractères ou les commentaires peuvent étendre le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas mis en évidence.En règle générale, les éditeurs de code doivent clairement afficher et mettre en évidence les caractères Unicode suspects, tels que les homoglyphes et les caractères de formatage directionnel. Depuis novembre, GitHub ajoute désormais des avertissements et des messages dans le code contenant du texte Unicode bidirectionnel dans chaque ligne, bien qu'il ne mette pas en évidence l'emplacement de ces caractères dans la ligne. Cela peut encore permettre à des changements de direction malveillants et à des changements de direction bénins de se glisser dans le code.
La sensibilisation des développeurs et des réviseurs de code est essentielle, c'est pourquoi nous avons créé un exercice pour illustrer les vulnérabilités. Actuellement, cet exercice est disponible pour Java, C#, Python, GO et PHP.
Par conséquent, si vous souhaitez en savoir plus, nous vous invitons à essayer notre simulation Trojan Source (mission publique), puis à lire l'étude Trojan Source.
Table des matières
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Formation sur les codes de sécurité : thèmes et contenu
Notre contenu de pointe évolue constamment pour s'adapter au paysage changeant du développement logiciel, tout en tenant compte de votre rôle. Les sujets abordés couvrent tout, de l'IA à l'injection XQuery, et s'adressent à divers postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu par thème et par rôle de ce que notre catalogue de contenu a à offrir.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : la mission AI pour vaincre le boss est désormais disponible sur demande.
Cybermon 2025 : la campagne « Vaincre le boss » est désormais disponible toute l'année dans SCW. La guerre de sécurité avancée de l'IA/LLM tribale, le renforcement de l'IA de sécurité à grande échelle.
Interprétation de la loi sur la résilience des réseaux : que signifie la sécurité par le biais de la conception et du développement de logiciels ?
Comprenez les exigences de la loi européenne sur la résilience des réseaux (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent s'y préparer grâce à des pratiques de conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facteur déterminant 1 : des critères de réussite clairs et mesurables
Le catalyseur n° 1 constitue le premier volet de notre série en dix parties consacrée aux facteurs de réussite. Il démontre comment relier la sécurité du code aux résultats opérationnels, tels que la réduction des risques et l'accélération de la maturité des programmes à long terme.
