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 s'est intéressée à la manière dont des caractères de format directionnels peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Leur utilisation permet de créer du code que le compilateur interprète différemment de la manière dont il serait interprété par un humain chargé de la révision du code.
Cette vulnérabilité est nouvelle. Cependant, Unicode a déjà été utilisé de manière abusive par le passé. Par exemple, Unicode a été utilisé pour masquer l'extension réelle d'un fichier comme suit. Inverser la direction de la dernière partie du nom de fichier. Des recherches récentes ont montré que, contrairement à de nombreux compilateurs qui ignorent les caractères Unicode dans le code source sans avertissement, les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et le code qui s'y rapporte. Par conséquent, les éditeurs peuvent afficher le code et les commentaires différemment ou dans un ordre différent de celui utilisé par les compilateurs pour les analyser. Il en va de même lorsque le code et les commentaires sont échangés.
Pour plus de détails, veuillez consulter les informations ci-dessous. Si vous souhaitez essayer le piratage simulé de Trojan Source, vous pouvez le faire gratuitement. Mission publique: veuillez en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel) qui traite la manière dont le texte est regroupé dans différents ordres d'affichage, tels que l'anglais (de gauche à droite) et l'arabe (de droite à gauche). L'utilisation de caractères directionnels permet de réorganiser les groupes et d'afficher l'ordre des caractères.
Le tableau ci-dessus contient une partie des caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI Nous nous rendrons à c. PDI
L'acronyme RLI signifie « Right to Left Isolate » (isolement de droite à gauche). Il sépare le texte de son contexte (séparé par PDI). Le texte est lu 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 format indiquant la direction sont simplement ignorés, le contenu suivant sera analysé.
Nous nous rendrons à C.
Transférer un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Jusqu'à présent, les caractères du format de spécification de direction étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Même si une pièce jointe à un e-mail s'affiche sous le nom « myspecialexe.doc », elle peut sembler inoffensive si elle n'est pas destinée à RLO (remplacement de droite à gauche). Cependant, il est important de noter que le nom réel est « myspecialcod.exe ».
Les attaques par cheval de Troie source insèrent des caractères de formatage dans les commentaires et les chaînes de caractères du code source, car elles ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code et font lire au compilateur quelque chose de complètement différent de ce que lit un être humain.
Par exemple, un fichier contenant les octets suivants dans l'ordre suivant.
Les caractères de format d'orientation sont triés comme suit :
Si les caractères de spécification de direction ne sont pas explicitement appelés, le code sera rendu comme suit.
RLO remplace la parenthèse fermante par une parenthèse ouvrante à la dernière ligne. L'inverse est également vrai. L'exécution de ce code donne le résultat « Vous êtes administrateur ». La vérification de l'administrateur est commentée, mais les caractères de contrôle donnent l'impression qu'elle existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela a-t-il sur vous ?
De nombreux langages, tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc., sont vulnérables aux attaques, et d'autres pourraient également l'être. Un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnels dans le code source, tandis qu'un débutant pourrait simplement ignorer ce problème. De plus, la visualisation de ces caractères dépend fortement de l'IDE utilisé, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité s'introduit-elle dans le code source ? Tout d'abord, ce problème peut survenir lorsque l'on utilise du code source provenant de sources non fiables, dont la contribution malveillante a été négligée. Deuxièmement,il est possible que la plupart des développeurs aient déjà copié-collé du code trouvé sur Internet, ce qui est une pratique courante. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. La question se pose donc de savoir dans quelle mesure ce code est fiable et digne de confiance. Comment filtrer le code source afin de détecter les portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les 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 format directionnel dans les chaînes de caractères et les commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne, à moins qu'ils ne soient supprimés.En général, 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 format directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, il ne met pas en évidence l'emplacement de ces caractères dans la ligne.Malgré cela, des changements de direction malveillants peuvent se glisser parmi les changements de direction inoffensifs.
Il est essentiel que les développeurs et les responsables de la révision du code soient informés. À cette fin, nous avons élaboré un guide détaillé expliquant les vulnérabilités. Ce guide est actuellement disponible en Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir davantage, nous vous invitons à essayer notre simulation de cheval de Troie (mission publique)et à consulter notre enquête sur le cheval de Troie.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'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 professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels chez Secure Code Warrior, où elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Mission Lab et Coding Lab.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée « Trojan Horse Source». Cette étude s'est intéressée à la manière dont des caractères de format directionnels peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Leur utilisation permet de créer du code que le compilateur interprète différemment de la manière dont il serait interprété par un humain chargé de la révision du code.
Cette vulnérabilité est nouvelle. Cependant, Unicode a déjà été utilisé de manière abusive par le passé. Par exemple, Unicode a été utilisé pour masquer l'extension réelle d'un fichier comme suit. Inverser la direction de la dernière partie du nom de fichier. Des recherches récentes ont montré que, contrairement à de nombreux compilateurs qui ignorent les caractères Unicode dans le code source sans avertissement, les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et le code qui s'y rapporte. Par conséquent, les éditeurs peuvent afficher le code et les commentaires différemment ou dans un ordre différent de celui utilisé par les compilateurs pour les analyser. Il en va de même lorsque le code et les commentaires sont échangés.
Pour plus de détails, veuillez consulter les informations ci-dessous. Si vous souhaitez essayer le piratage simulé de Trojan Source, vous pouvez le faire gratuitement. Mission publique: veuillez en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel) qui traite la manière dont le texte est regroupé dans différents ordres d'affichage, tels que l'anglais (de gauche à droite) et l'arabe (de droite à gauche). L'utilisation de caractères directionnels permet de réorganiser les groupes et d'afficher l'ordre des caractères.
Le tableau ci-dessus contient une partie des caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI Nous nous rendrons à c. PDI
L'acronyme RLI signifie « Right to Left Isolate » (isolement de droite à gauche). Il sépare le texte de son contexte (séparé par PDI). Le texte est lu 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 format indiquant la direction sont simplement ignorés, le contenu suivant sera analysé.
Nous nous rendrons à C.
Transférer un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Jusqu'à présent, les caractères du format de spécification de direction étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Même si une pièce jointe à un e-mail s'affiche sous le nom « myspecialexe.doc », elle peut sembler inoffensive si elle n'est pas destinée à RLO (remplacement de droite à gauche). Cependant, il est important de noter que le nom réel est « myspecialcod.exe ».
Les attaques par cheval de Troie source insèrent des caractères de formatage dans les commentaires et les chaînes de caractères du code source, car elles ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code et font lire au compilateur quelque chose de complètement différent de ce que lit un être humain.
Par exemple, un fichier contenant les octets suivants dans l'ordre suivant.
Les caractères de format d'orientation sont triés comme suit :
Si les caractères de spécification de direction ne sont pas explicitement appelés, le code sera rendu comme suit.
RLO remplace la parenthèse fermante par une parenthèse ouvrante à la dernière ligne. L'inverse est également vrai. L'exécution de ce code donne le résultat « Vous êtes administrateur ». La vérification de l'administrateur est commentée, mais les caractères de contrôle donnent l'impression qu'elle existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela a-t-il sur vous ?
De nombreux langages, tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc., sont vulnérables aux attaques, et d'autres pourraient également l'être. Un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnels dans le code source, tandis qu'un débutant pourrait simplement ignorer ce problème. De plus, la visualisation de ces caractères dépend fortement de l'IDE utilisé, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité s'introduit-elle dans le code source ? Tout d'abord, ce problème peut survenir lorsque l'on utilise du code source provenant de sources non fiables, dont la contribution malveillante a été négligée. Deuxièmement,il est possible que la plupart des développeurs aient déjà copié-collé du code trouvé sur Internet, ce qui est une pratique courante. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. La question se pose donc de savoir dans quelle mesure ce code est fiable et digne de confiance. Comment filtrer le code source afin de détecter les portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les 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 format directionnel dans les chaînes de caractères et les commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne, à moins qu'ils ne soient supprimés.En général, 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 format directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, il ne met pas en évidence l'emplacement de ces caractères dans la ligne.Malgré cela, des changements de direction malveillants peuvent se glisser parmi les changements de direction inoffensifs.
Il est essentiel que les développeurs et les responsables de la révision du code soient informés. À cette fin, nous avons élaboré un guide détaillé expliquant les vulnérabilités. Ce guide est actuellement disponible en Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir davantage, nous vous invitons à essayer notre simulation de cheval de Troie (mission publique)et à consulter notre enquête sur le cheval de Troie.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée « Trojan Horse Source». Cette étude s'est intéressée à la manière dont des caractères de format directionnels peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Leur utilisation permet de créer du code que le compilateur interprète différemment de la manière dont il serait interprété par un humain chargé de la révision du code.
Cette vulnérabilité est nouvelle. Cependant, Unicode a déjà été utilisé de manière abusive par le passé. Par exemple, Unicode a été utilisé pour masquer l'extension réelle d'un fichier comme suit. Inverser la direction de la dernière partie du nom de fichier. Des recherches récentes ont montré que, contrairement à de nombreux compilateurs qui ignorent les caractères Unicode dans le code source sans avertissement, les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et le code qui s'y rapporte. Par conséquent, les éditeurs peuvent afficher le code et les commentaires différemment ou dans un ordre différent de celui utilisé par les compilateurs pour les analyser. Il en va de même lorsque le code et les commentaires sont échangés.
Pour plus de détails, veuillez consulter les informations ci-dessous. Si vous souhaitez essayer le piratage simulé de Trojan Source, vous pouvez le faire gratuitement. Mission publique: veuillez en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel) qui traite la manière dont le texte est regroupé dans différents ordres d'affichage, tels que l'anglais (de gauche à droite) et l'arabe (de droite à gauche). L'utilisation de caractères directionnels permet de réorganiser les groupes et d'afficher l'ordre des caractères.
Le tableau ci-dessus contient une partie des caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI Nous nous rendrons à c. PDI
L'acronyme RLI signifie « Right to Left Isolate » (isolement de droite à gauche). Il sépare le texte de son contexte (séparé par PDI). Le texte est lu 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 format indiquant la direction sont simplement ignorés, le contenu suivant sera analysé.
Nous nous rendrons à C.
Transférer un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Jusqu'à présent, les caractères du format de spécification de direction étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Même si une pièce jointe à un e-mail s'affiche sous le nom « myspecialexe.doc », elle peut sembler inoffensive si elle n'est pas destinée à RLO (remplacement de droite à gauche). Cependant, il est important de noter que le nom réel est « myspecialcod.exe ».
Les attaques par cheval de Troie source insèrent des caractères de formatage dans les commentaires et les chaînes de caractères du code source, car elles ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code et font lire au compilateur quelque chose de complètement différent de ce que lit un être humain.
Par exemple, un fichier contenant les octets suivants dans l'ordre suivant.
Les caractères de format d'orientation sont triés comme suit :
Si les caractères de spécification de direction ne sont pas explicitement appelés, le code sera rendu comme suit.
RLO remplace la parenthèse fermante par une parenthèse ouvrante à la dernière ligne. L'inverse est également vrai. L'exécution de ce code donne le résultat « Vous êtes administrateur ». La vérification de l'administrateur est commentée, mais les caractères de contrôle donnent l'impression qu'elle existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela a-t-il sur vous ?
De nombreux langages, tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc., sont vulnérables aux attaques, et d'autres pourraient également l'être. Un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnels dans le code source, tandis qu'un débutant pourrait simplement ignorer ce problème. De plus, la visualisation de ces caractères dépend fortement de l'IDE utilisé, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité s'introduit-elle dans le code source ? Tout d'abord, ce problème peut survenir lorsque l'on utilise du code source provenant de sources non fiables, dont la contribution malveillante a été négligée. Deuxièmement,il est possible que la plupart des développeurs aient déjà copié-collé du code trouvé sur Internet, ce qui est une pratique courante. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. La question se pose donc de savoir dans quelle mesure ce code est fiable et digne de confiance. Comment filtrer le code source afin de détecter les portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les 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 format directionnel dans les chaînes de caractères et les commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne, à moins qu'ils ne soient supprimés.En général, 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 format directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, il ne met pas en évidence l'emplacement de ces caractères dans la ligne.Malgré cela, des changements de direction malveillants peuvent se glisser parmi les changements de direction inoffensifs.
Il est essentiel que les développeurs et les responsables de la révision du code soient informés. À cette fin, nous avons élaboré un guide détaillé expliquant les vulnérabilités. Ce guide est actuellement disponible en Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir davantage, nous vous invitons à essayer notre simulation de cheval de Troie (mission publique)et à consulter notre enquête sur le cheval de Troie.
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'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 professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Afficher le rapportVeuillez réserver une démonstration.
Laura Verheyde est développeuse de logiciels chez Secure Code Warrior, où elle se consacre à la recherche de vulnérabilités et à la création de contenu pour Mission Lab et Coding Lab.
Au début du mois de novembre, l'université de Cambridge a publié une étude intitulée « Trojan Horse Source». Cette étude s'est intéressée à la manière dont des caractères de format directionnels peuvent être utilisés pour dissimuler des portes dérobées dans le code source et les commentaires. Leur utilisation permet de créer du code que le compilateur interprète différemment de la manière dont il serait interprété par un humain chargé de la révision du code.
Cette vulnérabilité est nouvelle. Cependant, Unicode a déjà été utilisé de manière abusive par le passé. Par exemple, Unicode a été utilisé pour masquer l'extension réelle d'un fichier comme suit. Inverser la direction de la dernière partie du nom de fichier. Des recherches récentes ont montré que, contrairement à de nombreux compilateurs qui ignorent les caractères Unicode dans le code source sans avertissement, les éditeurs de texte, y compris les éditeurs de code, peuvent réorganiser les lignes contenant des commentaires et le code qui s'y rapporte. Par conséquent, les éditeurs peuvent afficher le code et les commentaires différemment ou dans un ordre différent de celui utilisé par les compilateurs pour les analyser. Il en va de même lorsque le code et les commentaires sont échangés.
Pour plus de détails, veuillez consulter les informations ci-dessous. Si vous souhaitez essayer le piratage simulé de Trojan Source, vous pouvez le faire gratuitement. Mission publique: veuillez en faire l'expérience par vous-même.
Texte bidirectionnel
L'une de ces attaques par cheval de Troie utilise l'algorithme Unicode Bidi (bidirectionnel) qui traite la manière dont le texte est regroupé dans différents ordres d'affichage, tels que l'anglais (de gauche à droite) et l'arabe (de droite à gauche). L'utilisation de caractères directionnels permet de réorganiser les groupes et d'afficher l'ordre des caractères.
Le tableau ci-dessus contient une partie des caractères de remplacement Bidi liés aux attaques. Par exemple,
RLI Nous nous rendrons à c. PDI
L'acronyme RLI signifie « Right to Left Isolate » (isolement de droite à gauche). Il sépare le texte de son contexte (séparé par PDI). Le texte est lu 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 format indiquant la direction sont simplement ignorés, le contenu suivant sera analysé.
Nous nous rendrons à C.
Transférer un vin ancien dans une nouvelle bouteille ?
Bien entendu, ce n'est pas une nouveauté. Jusqu'à présent, les caractères du format de spécification de direction étaient insérés dans les noms de fichiers afin de dissimuler leur nature malveillante. Même si une pièce jointe à un e-mail s'affiche sous le nom « myspecialexe.doc », elle peut sembler inoffensive si elle n'est pas destinée à RLO (remplacement de droite à gauche). Cependant, il est important de noter que le nom réel est « myspecialcod.exe ».
Les attaques par cheval de Troie source insèrent des caractères de formatage dans les commentaires et les chaînes de caractères du code source, car elles ne génèrent pas d'erreurs de syntaxe ou de compilation. Ces caractères de contrôle modifient l'ordre d'affichage de la logique du code et font lire au compilateur quelque chose de complètement différent de ce que lit un être humain.
Par exemple, un fichier contenant les octets suivants dans l'ordre suivant.
Les caractères de format d'orientation sont triés comme suit :
Si les caractères de spécification de direction ne sont pas explicitement appelés, le code sera rendu comme suit.
RLO remplace la parenthèse fermante par une parenthèse ouvrante à la dernière ligne. L'inverse est également vrai. L'exécution de ce code donne le résultat « Vous êtes administrateur ». La vérification de l'administrateur est commentée, mais les caractères de contrôle donnent l'impression qu'elle existe toujours.
(Source : https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Quel impact cela a-t-il sur vous ?
De nombreux langages, tels que C, C++, C#, JavaScript, Java, Rust, Go, Python, etc., sont vulnérables aux attaques, et d'autres pourraient également l'être. Un développeur expérimenté pourrait être préoccupé par la présence de caractères de formatage directionnels dans le code source, tandis qu'un débutant pourrait simplement ignorer ce problème. De plus, la visualisation de ces caractères dépend fortement de l'IDE utilisé, il n'est donc pas garanti qu'ils soient détectés.
Cependant, comment cette vulnérabilité s'introduit-elle dans le code source ? Tout d'abord, ce problème peut survenir lorsque l'on utilise du code source provenant de sources non fiables, dont la contribution malveillante a été négligée. Deuxièmement,il est possible que la plupart des développeurs aient déjà copié-collé du code trouvé sur Internet, ce qui est une pratique courante. La plupart des organisations dépendent de composants logiciels provenant de plusieurs fournisseurs. La question se pose donc de savoir dans quelle mesure ce code est fiable et digne de confiance. Comment filtrer le code source afin de détecter les portes dérobées cachées ?
À qui la faute ?
D'une part, les compilateurs et les pipelines de compilation ne devraient pas autoriser les 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 format directionnel dans les chaînes de caractères et les commentaires peuvent prolonger le changement de direction jusqu'à la fin de la ligne, à moins qu'ils ne soient supprimés.En général, 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 format directionnel. Depuis novembre, GitHub ajoute un symbole d'avertissement et un message à toutes les lignes de code contenant du texte Unicode bidirectionnel. Cependant, il ne met pas en évidence l'emplacement de ces caractères dans la ligne.Malgré cela, des changements de direction malveillants peuvent se glisser parmi les changements de direction inoffensifs.
Il est essentiel que les développeurs et les responsables de la révision du code soient informés. À cette fin, nous avons élaboré un guide détaillé expliquant les vulnérabilités. Ce guide est actuellement disponible en Java, C#, Python, GO et PHP.
Si vous souhaitez en savoir davantage, nous vous invitons à essayer notre simulation de cheval de Troie (mission publique)et à consulter notre enquête sur le cheval de Troie.
Table des matières
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'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 professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.[Télécharger]Ressources pour débuter
Sujets et contenu de la formation sur le code sécurisé
Notre contenu, leader dans le secteur, évolue constamment en fonction de l'environnement de développement logiciel en constante mutation, tout en tenant compte du rôle de nos clients. Il couvre tous les sujets, de l'IA à l'injection XQuery, et s'adresse à divers rôles, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Nous vous invitons à consulter le catalogue de contenu pour découvrir son contenu par sujet 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 pour débuter
Cybermon est de retour : la mission IA consistant à vaincre le boss est désormais disponible à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année sur SCW. Renforcez considérablement le développement sécurisé de l'IA en introduisant des défis de sécurité avancés en matière d'IA/LLM.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la résilience cybernétique (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer en matière de pratiques de sécurité dès la conception, de prévention des vulnérabilités et de développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite prédéfinis et mesurables
Enabler 1 est le premier volet d'une série de dix intitulée « Enablers of Success » (Les catalyseurs de la réussite). Il présente comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et l'accélération des processus afin de faire évoluer le programme à long terme.
