Qu'est-ce qu'un cheval de Troie et comment s'introduit-il dans le code source ?
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée « Trojan Horse-Source ». Cette étude se concentrait sur la manière dont il était possible de dissimuler des portes dérobées dans le code source et les commentaires à l'aide de caractères de formatage directionnels. Cela peut être utilisé pour créer du code que le compilateur interprète différemment des vérificateurs de code humains.
Bien qu'il y ait eu des cas d'utilisation malveillante d'Unicode, par exemple pour masquer l'extension réelle d'un nom de fichier, cette vulnérabilité est nouvelle. Inversion de la dernière partie du nom de fichier. Selon des études récentes, 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 réorganiser les lignes contenant des commentaires et du code sur cette base. Par conséquent, les éditeurs peuvent afficher le code et les commentaires dans un ordre différent de celui utilisé par les compilateurs pour l'analyse syntaxique. Il en va de même même lorsque le code et les commentaires sont intervertis.
Pour en savoir plus, veuillez continuer votre lecture. Si vous souhaitez essayer la simulation de piratage de Trojan Source, veuillez accéder directement au service gratuit. Découvrez par vous-même les missions publiques.
Texte bidirectionnel
L'une de ces attaques de type « trojan source » utilise l'algorithme Unicode Bidi (bidirectionnel). Cet algorithme gère l'alignement des textes dont l'ordre d'affichage diffère, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Il est possible de réorganiser les groupes et d'afficher l'ordre des caractères à l'aide de caractères de formatage directionnel.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés à l'attaque. Par exemple,
RLI e d o c 피디
L'acronyme RLI signifie « séparation de droite à gauche ». Il sépare le texte du contexte (distingué par PDI). Cliquez sur « Pop Directional Isolate » et lisez de droite à gauche. Le résultat est le suivant.
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. Si les caractères de spécification de direction sont simplement ignorés, l'analyse se déroule comme suit.
e d o c
Un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Dans le passé, des caractères de direction étaient utilisés. Ils étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail nommée « myspecialexe.doc » pouvait sembler tout à fait innocente si elle n'avait pas étéremplacée de droite à gauche(RLO), révélant ainsi que son nom réel était « myspecialcod.exe ».
Les attaques par injection SQL consistent à insérer des caractères de formatage directionnel dans les commentaires et les chaînes de caractères du code source. Dans ce cas, aucune erreur de syntaxe ou de compilation ne se produit. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce que lit l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans l'ordre :
Les caractères de spécification de direction sont réorganisés comme suit.
Si le caractère de spécification de direction n'est pas explicitement appelé, le code est rendu comme suit.
RLO remplace l'accolade fermante de la dernière ligne par une accolade ouvrante, et inversement. L'exécution de ce code produit le résultat suivant : « Vous êtes administrateur ». Bien que la vérification d'administrateur ait été commentée, l'examen des caractères de contrôle donne l'impression que cette vérification existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc. sont vulnérables aux attaques, et il est présumé que d'autres langages le sont également. et l'on suppose que d'autres le sont également. À présent, les développeurs expérimentés peuvent froncer les sourcils en voyant des caractères directionnels dans le code source, mais les débutants feraient mieux de hausser les épaules et de ne pas y prêter attention. De plus, la visualisation de ces caractères varie considérablement selon l'IDE, il n'y a donc aucune garantie qu'ils seront 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, dont la contribution malveillante passe inaperçue. Deuxièmement, cela peut également se produire simplement en copiant-collant du code trouvé sur Internet. La plupart d'entre nous, développeurs, avons déjà procédé de cette manière. La plupart des organisations dépendent des composants logiciels de plusieurs fournisseurs. Cela soulève la question de la fiabilité et de la confiance que l'on peut accorder à ce code. Comment identifier le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité ?
D'une part, le compilateur et le pipeline de construction ne doivent pas autoriser les lignes de code source comportant plus d'une direction, à moins que la direction ne soit strictement limitée aux chaînes de caractères et aux commentaires.À titre indicatif, les caractères de formatage directionnel des chaînes de caractères ou des commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas supprimés. En règle générale, les éditeurs de code doivent explicitement 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 un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, la position de ces caractères dans la ligne n'est pas mise en évidence. Cela signifie que des changements d'orientation malveillants peuvent toujours s'infiltrer discrètement.
La communication entre les développeurs et les réviseurs de code est essentielle, c'est pourquoi nous avons créé un guide expliquant les vulnérabilités. Cet exercice est actuellement disponible en Java, C#, Python, GO et PHP.
Pour en savoir plus, nous vous invitons à essayer notre produit, la simulation de source Trojan (mission publique), et à consulter la recherche sur la source Trojan.
Secure Code Warrior est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez prendre rendez-vous pour 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 Horse-Source ». Cette étude se concentrait sur la manière dont il était possible de dissimuler des portes dérobées dans le code source et les commentaires à l'aide de caractères de formatage directionnels. Cela peut être utilisé pour créer du code que le compilateur interprète différemment des vérificateurs de code humains.
Bien qu'il y ait eu des cas d'utilisation malveillante d'Unicode, par exemple pour masquer l'extension réelle d'un nom de fichier, cette vulnérabilité est nouvelle. Inversion de la dernière partie du nom de fichier. Selon des études récentes, 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 réorganiser les lignes contenant des commentaires et du code sur cette base. Par conséquent, les éditeurs peuvent afficher le code et les commentaires dans un ordre différent de celui utilisé par les compilateurs pour l'analyse syntaxique. Il en va de même même lorsque le code et les commentaires sont intervertis.
Pour en savoir plus, veuillez continuer votre lecture. Si vous souhaitez essayer la simulation de piratage de Trojan Source, veuillez accéder directement au service gratuit. Découvrez par vous-même les missions publiques.
Texte bidirectionnel
L'une de ces attaques de type « trojan source » utilise l'algorithme Unicode Bidi (bidirectionnel). Cet algorithme gère l'alignement des textes dont l'ordre d'affichage diffère, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Il est possible de réorganiser les groupes et d'afficher l'ordre des caractères à l'aide de caractères de formatage directionnel.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés à l'attaque. Par exemple,
RLI e d o c 피디
L'acronyme RLI signifie « séparation de droite à gauche ». Il sépare le texte du contexte (distingué par PDI). Cliquez sur « Pop Directional Isolate » et lisez de droite à gauche. Le résultat est le suivant.
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. Si les caractères de spécification de direction sont simplement ignorés, l'analyse se déroule comme suit.
e d o c
Un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Dans le passé, des caractères de direction étaient utilisés. Ils étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail nommée « myspecialexe.doc » pouvait sembler tout à fait innocente si elle n'avait pas étéremplacée de droite à gauche(RLO), révélant ainsi que son nom réel était « myspecialcod.exe ».
Les attaques par injection SQL consistent à insérer des caractères de formatage directionnel dans les commentaires et les chaînes de caractères du code source. Dans ce cas, aucune erreur de syntaxe ou de compilation ne se produit. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce que lit l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans l'ordre :
Les caractères de spécification de direction sont réorganisés comme suit.
Si le caractère de spécification de direction n'est pas explicitement appelé, le code est rendu comme suit.
RLO remplace l'accolade fermante de la dernière ligne par une accolade ouvrante, et inversement. L'exécution de ce code produit le résultat suivant : « Vous êtes administrateur ». Bien que la vérification d'administrateur ait été commentée, l'examen des caractères de contrôle donne l'impression que cette vérification existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc. sont vulnérables aux attaques, et il est présumé que d'autres langages le sont également. et l'on suppose que d'autres le sont également. À présent, les développeurs expérimentés peuvent froncer les sourcils en voyant des caractères directionnels dans le code source, mais les débutants feraient mieux de hausser les épaules et de ne pas y prêter attention. De plus, la visualisation de ces caractères varie considérablement selon l'IDE, il n'y a donc aucune garantie qu'ils seront 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, dont la contribution malveillante passe inaperçue. Deuxièmement, cela peut également se produire simplement en copiant-collant du code trouvé sur Internet. La plupart d'entre nous, développeurs, avons déjà procédé de cette manière. La plupart des organisations dépendent des composants logiciels de plusieurs fournisseurs. Cela soulève la question de la fiabilité et de la confiance que l'on peut accorder à ce code. Comment identifier le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité ?
D'une part, le compilateur et le pipeline de construction ne doivent pas autoriser les lignes de code source comportant plus d'une direction, à moins que la direction ne soit strictement limitée aux chaînes de caractères et aux commentaires.À titre indicatif, les caractères de formatage directionnel des chaînes de caractères ou des commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas supprimés. En règle générale, les éditeurs de code doivent explicitement 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 un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, la position de ces caractères dans la ligne n'est pas mise en évidence. Cela signifie que des changements d'orientation malveillants peuvent toujours s'infiltrer discrètement.
La communication entre les développeurs et les réviseurs de code est essentielle, c'est pourquoi nous avons créé un guide expliquant les vulnérabilités. Cet exercice est actuellement disponible en Java, C#, Python, GO et PHP.
Pour en savoir plus, nous vous invitons à essayer notre produit, la simulation de source Trojan (mission publique), et à consulter la recherche sur la source Trojan.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée « Trojan Horse-Source ». Cette étude se concentrait sur la manière dont il était possible de dissimuler des portes dérobées dans le code source et les commentaires à l'aide de caractères de formatage directionnels. Cela peut être utilisé pour créer du code que le compilateur interprète différemment des vérificateurs de code humains.
Bien qu'il y ait eu des cas d'utilisation malveillante d'Unicode, par exemple pour masquer l'extension réelle d'un nom de fichier, cette vulnérabilité est nouvelle. Inversion de la dernière partie du nom de fichier. Selon des études récentes, 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 réorganiser les lignes contenant des commentaires et du code sur cette base. Par conséquent, les éditeurs peuvent afficher le code et les commentaires dans un ordre différent de celui utilisé par les compilateurs pour l'analyse syntaxique. Il en va de même même lorsque le code et les commentaires sont intervertis.
Pour en savoir plus, veuillez continuer votre lecture. Si vous souhaitez essayer la simulation de piratage de Trojan Source, veuillez accéder directement au service gratuit. Découvrez par vous-même les missions publiques.
Texte bidirectionnel
L'une de ces attaques de type « trojan source » utilise l'algorithme Unicode Bidi (bidirectionnel). Cet algorithme gère l'alignement des textes dont l'ordre d'affichage diffère, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Il est possible de réorganiser les groupes et d'afficher l'ordre des caractères à l'aide de caractères de formatage directionnel.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés à l'attaque. Par exemple,
RLI e d o c 피디
L'acronyme RLI signifie « séparation de droite à gauche ». Il sépare le texte du contexte (distingué par PDI). Cliquez sur « Pop Directional Isolate » et lisez de droite à gauche. Le résultat est le suivant.
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. Si les caractères de spécification de direction sont simplement ignorés, l'analyse se déroule comme suit.
e d o c
Un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Dans le passé, des caractères de direction étaient utilisés. Ils étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail nommée « myspecialexe.doc » pouvait sembler tout à fait innocente si elle n'avait pas étéremplacée de droite à gauche(RLO), révélant ainsi que son nom réel était « myspecialcod.exe ».
Les attaques par injection SQL consistent à insérer des caractères de formatage directionnel dans les commentaires et les chaînes de caractères du code source. Dans ce cas, aucune erreur de syntaxe ou de compilation ne se produit. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce que lit l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans l'ordre :
Les caractères de spécification de direction sont réorganisés comme suit.
Si le caractère de spécification de direction n'est pas explicitement appelé, le code est rendu comme suit.
RLO remplace l'accolade fermante de la dernière ligne par une accolade ouvrante, et inversement. L'exécution de ce code produit le résultat suivant : « Vous êtes administrateur ». Bien que la vérification d'administrateur ait été commentée, l'examen des caractères de contrôle donne l'impression que cette vérification existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc. sont vulnérables aux attaques, et il est présumé que d'autres langages le sont également. et l'on suppose que d'autres le sont également. À présent, les développeurs expérimentés peuvent froncer les sourcils en voyant des caractères directionnels dans le code source, mais les débutants feraient mieux de hausser les épaules et de ne pas y prêter attention. De plus, la visualisation de ces caractères varie considérablement selon l'IDE, il n'y a donc aucune garantie qu'ils seront 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, dont la contribution malveillante passe inaperçue. Deuxièmement, cela peut également se produire simplement en copiant-collant du code trouvé sur Internet. La plupart d'entre nous, développeurs, avons déjà procédé de cette manière. La plupart des organisations dépendent des composants logiciels de plusieurs fournisseurs. Cela soulève la question de la fiabilité et de la confiance que l'on peut accorder à ce code. Comment identifier le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité ?
D'une part, le compilateur et le pipeline de construction ne doivent pas autoriser les lignes de code source comportant plus d'une direction, à moins que la direction ne soit strictement limitée aux chaînes de caractères et aux commentaires.À titre indicatif, les caractères de formatage directionnel des chaînes de caractères ou des commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas supprimés. En règle générale, les éditeurs de code doivent explicitement 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 un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, la position de ces caractères dans la ligne n'est pas mise en évidence. Cela signifie que des changements d'orientation malveillants peuvent toujours s'infiltrer discrètement.
La communication entre les développeurs et les réviseurs de code est essentielle, c'est pourquoi nous avons créé un guide expliquant les vulnérabilités. Cet exercice est actuellement disponible en Java, C#, Python, GO et PHP.
Pour en savoir plus, nous vous invitons à essayer notre produit, la simulation de source Trojan (mission publique), et à consulter la recherche sur la source Trojan.
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Consulter le rapportVeuillez prendre rendez-vous pour 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 Horse-Source ». Cette étude se concentrait sur la manière dont il était possible de dissimuler des portes dérobées dans le code source et les commentaires à l'aide de caractères de formatage directionnels. Cela peut être utilisé pour créer du code que le compilateur interprète différemment des vérificateurs de code humains.
Bien qu'il y ait eu des cas d'utilisation malveillante d'Unicode, par exemple pour masquer l'extension réelle d'un nom de fichier, cette vulnérabilité est nouvelle. Inversion de la dernière partie du nom de fichier. Selon des études récentes, 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 réorganiser les lignes contenant des commentaires et du code sur cette base. Par conséquent, les éditeurs peuvent afficher le code et les commentaires dans un ordre différent de celui utilisé par les compilateurs pour l'analyse syntaxique. Il en va de même même lorsque le code et les commentaires sont intervertis.
Pour en savoir plus, veuillez continuer votre lecture. Si vous souhaitez essayer la simulation de piratage de Trojan Source, veuillez accéder directement au service gratuit. Découvrez par vous-même les missions publiques.
Texte bidirectionnel
L'une de ces attaques de type « trojan source » utilise l'algorithme Unicode Bidi (bidirectionnel). Cet algorithme gère l'alignement des textes dont l'ordre d'affichage diffère, comme l'anglais (de gauche à droite) et l'arabe (de droite à gauche). Il est possible de réorganiser les groupes et d'afficher l'ordre des caractères à l'aide de caractères de formatage directionnel.
Le tableau ci-dessus contient certains caractères de remplacement Bidi liés à l'attaque. Par exemple,
RLI e d o c 피디
L'acronyme RLI signifie « séparation de droite à gauche ». Il sépare le texte du contexte (distingué par PDI). Cliquez sur « Pop Directional Isolate » et lisez de droite à gauche. Le résultat est le suivant.
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. Si les caractères de spécification de direction sont simplement ignorés, l'analyse se déroule comme suit.
e d o c
Un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Dans le passé, des caractères de direction étaient utilisés. Ils étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Une pièce jointe à un e-mail nommée « myspecialexe.doc » pouvait sembler tout à fait innocente si elle n'avait pas étéremplacée de droite à gauche(RLO), révélant ainsi que son nom réel était « myspecialcod.exe ».
Les attaques par injection SQL consistent à insérer des caractères de formatage directionnel dans les commentaires et les chaînes de caractères du code source. Dans ce cas, aucune erreur de syntaxe ou de compilation ne se produit. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code, ce qui fait que le compilateur lit quelque chose de complètement différent de ce que lit l'utilisateur.
Par exemple, un fichier contenant les octets suivants dans l'ordre :
Les caractères de spécification de direction sont réorganisés comme suit.
Si le caractère de spécification de direction n'est pas explicitement appelé, le code est rendu comme suit.
RLO remplace l'accolade fermante de la dernière ligne par une accolade ouvrante, et inversement. L'exécution de ce code produit le résultat suivant : « Vous êtes administrateur ». Bien que la vérification d'administrateur ait été commentée, l'examen des caractères de contrôle donne l'impression que cette vérification existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela pourrait-il avoir sur vous ?
De nombreux langages tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc. sont vulnérables aux attaques, et il est présumé que d'autres langages le sont également. et l'on suppose que d'autres le sont également. À présent, les développeurs expérimentés peuvent froncer les sourcils en voyant des caractères directionnels dans le code source, mais les débutants feraient mieux de hausser les épaules et de ne pas y prêter attention. De plus, la visualisation de ces caractères varie considérablement selon l'IDE, il n'y a donc aucune garantie qu'ils seront 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, dont la contribution malveillante passe inaperçue. Deuxièmement, cela peut également se produire simplement en copiant-collant du code trouvé sur Internet. La plupart d'entre nous, développeurs, avons déjà procédé de cette manière. La plupart des organisations dépendent des composants logiciels de plusieurs fournisseurs. Cela soulève la question de la fiabilité et de la confiance que l'on peut accorder à ce code. Comment identifier le code source contenant des portes dérobées cachées ?
À qui incombe la responsabilité ?
D'une part, le compilateur et le pipeline de construction ne doivent pas autoriser les lignes de code source comportant plus d'une direction, à moins que la direction ne soit strictement limitée aux chaînes de caractères et aux commentaires.À titre indicatif, les caractères de formatage directionnel des chaînes de caractères ou des commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne s'ils ne sont pas supprimés. En règle générale, les éditeurs de code doivent explicitement 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 un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, la position de ces caractères dans la ligne n'est pas mise en évidence. Cela signifie que des changements d'orientation malveillants peuvent toujours s'infiltrer discrètement.
La communication entre les développeurs et les réviseurs de code est essentielle, c'est pourquoi nous avons créé un guide expliquant les vulnérabilités. Cet exercice est actuellement disponible en Java, C#, Python, GO et PHP.
Pour en savoir plus, nous vous invitons à essayer notre produit, la simulation de source Trojan (mission publique), et à consulter la recherche sur la source Trojan.
Table des matières
Secure Code Warrior est là pour aider les organisations à protéger leur 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, responsable de la sécurité des systèmes d'information ou tout autre professionnel de la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez prendre rendez-vous pour une démonstration.TéléchargerRessources utiles pour débuter
Thèmes et contenus de la formation sur les codes de sécurité
Le contenu le plus pertinent du secteur évolue constamment pour s'adapter à l'environnement de développement logiciel en constante évolution, en tenant compte du rôle des clients. Des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité, tous les rôles sont couverts, de l'IA à l'injection XQuery. Veuillez consulter le catalogue de contenu pour découvrir ce qui est proposé par thème et par rôle.
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 utiles pour débuter
Cybermon est de retour : la mission IA de défaite du boss est désormais disponible à la demande.
Cybermon 2025 Bit The Boss est désormais disponible toute l'année sur SCW. Renforcez le développement de l'IA de sécurité à grande échelle en déployant des défis de sécurité IA/LLM avancés.
Explication de la loi sur la cyber-résilience : l'importance de la conception sécurisée dans le développement de logiciels
Découvrez les exigences de la loi européenne sur la résilience des réseaux et des services (CRA), son champ d'application et comment votre équipe d'ingénieurs peut se préparer en toute sécurité grâce à la conception, aux pratiques, à la prévention des vulnérabilités et à la mise en place d'un environnement de développement.
Facteur de réussite n° 1 : des critères de réussite clairement définis et mesurables
Enabler 1 présente une série de dix articles consacrés aux facteurs de réussite, en démontrant comment le codage sécurisé peut améliorer les performances commerciales, notamment en accélérant la réduction des risques et des coûts pour la maturité des programmes à long terme.
