什么是特洛伊木马源以及它是如何潜入您的源代码的
11月初，剑桥大学发布了他们的 名为 Trojan-Source 的研究。这项研究的重点是如何使用定向格式化字符将后门隐藏在源代码和注释中。它们可用于编写代码，编译器对逻辑的解释与人工代码审查员的解释有所不同。
这个漏洞是新出现的，尽管过去曾有人恶意使用 Unicode，例如通过以下方式隐藏文件的真实文件扩展名 反转文件名最后一部分的方向。最近的研究表明，许多编译器会在没有警告的情况下忽略源代码中的Unicode字符，而包括代码编辑器在内的文本编辑器可能会重排包含注释和基于这些字符的代码的行。因此，编辑器显示代码和注释的方式可能与编译器解析代码和注释的方式有所不同，甚至可以互换代码和注释。
请继续阅读以了解更多信息。或者，如果你想卷起袖子试一试 Trojan Source 的模拟黑客攻击，可以试试我们的免费版 公共使命 亲自体验一下。
双向文本
其中一种特洛伊木马源攻击使用了 Unicode Bidi（双向）算法，该算法处理如何将具有不同显示顺序（例如英语（从左到右）和阿拉伯语（从右到左）的文本组合在一起。定向格式化字符可用于重新组织分组和显示字符顺序。
上表包含一些与攻击有关的 Bidi 替换角色。举个例子，
RLI e d o c PDI
缩写 RLI 代表 从右到左隔离。它将把文本与其上下文隔离开来（由 PDI 分隔， 流行定向隔离），并将从右向左读取。导致：
c o d e
但是，编译器和解释器通常不会在解析源代码之前处理格式控制字符，包括 Bidi 覆盖。如果他们只是忽略方向格式化字符，他们就会解析：
e d o c
新瓶装旧酒？
当然，这在阳光下并不是什么新鲜事。过去，定向格式化字符是 插入到文件名中 掩盖他们的恶意本质。如果不是 RLO，显示为 “myspecialexe.doc” 的电子邮件附件可能看起来足够纯真 (从右到左的超控) 出现的角色显示真名是 “myspecialcod.exe”。
Trojan Source 攻击会在源代码中的注释和字符串中插入定向格式化字符，因为这些字符不会生成任何语法或编译错误。这些控制字符改变了代码逻辑的显示顺序，导致编译器读取的内容与人类读取的内容完全不同。
例如，一个按此顺序包含以下字节的文件：
将按方向格式化字符进行重新排序，如下所示
如果没有明确调出方向格式化字符，则会导致代码像这样呈现：
RLO 在最后一行将右大括号翻转为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
（来源：https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx）
这会对你产生什么影响？
许多语言都容易受到攻击：C、C++、C#、JavaScript、Java、Rust、Go 和 Python，据推测还有更多。现在，普通的开发人员可能会对在源代码中看到定向格式化字符不屑一顾，但新手也可能耸了耸肩，什么都不想。此外，这些角色的可视化高度依赖于 IDE，因此不能保证它们会被发现。
但是，这个漏洞一开始怎么会潜入源代码呢？首先，当使用来自不可信来源的源代码时，可能会发生这种情况，而恶意代码贡献却没有被注意到。其次，这可以通过简单地从互联网上找到的代码中复制粘贴来实现，这是我们大多数开发人员以前做过的事情。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题，我们可以在多大程度上完全信任和依赖这段代码？我们如何筛选包含隐藏后门的源代码？
这是谁的问题？
一方面，编译器和编译管道应禁止使用多个方向的源代码行，除非一个方向严格限于字符串和注释。请注意，字符串或注释中的方向格式化字符如果没有弹出，则可以将方向变化延伸到行尾。通常，代码编辑器应明确呈现和突出显示可疑的 Unicode 字符，例如同形文字和定向格式化字符。自 11 月以来，GitHub 现在会在每行包含双向 unicode 文本的代码中添加警告标志和消息，尽管它没有突出显示这些字符在行中的位置。这仍可能允许恶意的方向改变以及良性的方向变化潜入。
开发人员和代码审查者的意识至关重要，这就是为什么我们创建了一个演练来说明漏洞。目前，本演练可用于 Java、C#、Python、GO 和 PHP。
因此，如果您想了解更多，请尝试我们的 Trojan Source 的模拟（公共任务），然后阅读 特洛伊木马来源研究。
Secure Code Warrior可以帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全放在首位的文化。无论您是 AppSec 经理、开发人员、首席信息安全官还是任何与安全相关的人，我们都可以帮助您的组织降低与不安全代码相关的风险。
预订演示
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
11月初，剑桥大学发布了他们的 名为 Trojan-Source 的研究。这项研究的重点是如何使用定向格式化字符将后门隐藏在源代码和注释中。它们可用于编写代码，编译器对逻辑的解释与人工代码审查员的解释有所不同。
这个漏洞是新出现的，尽管过去曾有人恶意使用 Unicode，例如通过以下方式隐藏文件的真实文件扩展名 反转文件名最后一部分的方向。最近的研究表明，许多编译器会在没有警告的情况下忽略源代码中的Unicode字符，而包括代码编辑器在内的文本编辑器可能会重排包含注释和基于这些字符的代码的行。因此，编辑器显示代码和注释的方式可能与编译器解析代码和注释的方式有所不同，甚至可以互换代码和注释。
请继续阅读以了解更多信息。或者，如果你想卷起袖子试一试 Trojan Source 的模拟黑客攻击，可以试试我们的免费版 公共使命 亲自体验一下。
双向文本
其中一种特洛伊木马源攻击使用了 Unicode Bidi（双向）算法，该算法处理如何将具有不同显示顺序（例如英语（从左到右）和阿拉伯语（从右到左）的文本组合在一起。定向格式化字符可用于重新组织分组和显示字符顺序。
上表包含一些与攻击有关的 Bidi 替换角色。举个例子，
RLI e d o c PDI
缩写 RLI 代表 从右到左隔离。它将把文本与其上下文隔离开来（由 PDI 分隔， 流行定向隔离），并将从右向左读取。导致：
c o d e
但是，编译器和解释器通常不会在解析源代码之前处理格式控制字符，包括 Bidi 覆盖。如果他们只是忽略方向格式化字符，他们就会解析：
e d o c
新瓶装旧酒？
当然，这在阳光下并不是什么新鲜事。过去，定向格式化字符是 插入到文件名中 掩盖他们的恶意本质。如果不是 RLO，显示为 “myspecialexe.doc” 的电子邮件附件可能看起来足够纯真 (从右到左的超控) 出现的角色显示真名是 “myspecialcod.exe”。
Trojan Source 攻击会在源代码中的注释和字符串中插入定向格式化字符，因为这些字符不会生成任何语法或编译错误。这些控制字符改变了代码逻辑的显示顺序，导致编译器读取的内容与人类读取的内容完全不同。
例如，一个按此顺序包含以下字节的文件：
将按方向格式化字符进行重新排序，如下所示
如果没有明确调出方向格式化字符，则会导致代码像这样呈现：
RLO 在最后一行将右大括号翻转为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
（来源：https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx）
这会对你产生什么影响？
许多语言都容易受到攻击：C、C++、C#、JavaScript、Java、Rust、Go 和 Python，据推测还有更多。现在，普通的开发人员可能会对在源代码中看到定向格式化字符不屑一顾，但新手也可能耸了耸肩，什么都不想。此外，这些角色的可视化高度依赖于 IDE，因此不能保证它们会被发现。
但是，这个漏洞一开始怎么会潜入源代码呢？首先，当使用来自不可信来源的源代码时，可能会发生这种情况，而恶意代码贡献却没有被注意到。其次，这可以通过简单地从互联网上找到的代码中复制粘贴来实现，这是我们大多数开发人员以前做过的事情。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题，我们可以在多大程度上完全信任和依赖这段代码？我们如何筛选包含隐藏后门的源代码？
这是谁的问题？
一方面，编译器和编译管道应禁止使用多个方向的源代码行，除非一个方向严格限于字符串和注释。请注意，字符串或注释中的方向格式化字符如果没有弹出，则可以将方向变化延伸到行尾。通常，代码编辑器应明确呈现和突出显示可疑的 Unicode 字符，例如同形文字和定向格式化字符。自 11 月以来，GitHub 现在会在每行包含双向 unicode 文本的代码中添加警告标志和消息，尽管它没有突出显示这些字符在行中的位置。这仍可能允许恶意的方向改变以及良性的方向变化潜入。
开发人员和代码审查者的意识至关重要，这就是为什么我们创建了一个演练来说明漏洞。目前，本演练可用于 Java、C#、Python、GO 和 PHP。
因此，如果您想了解更多，请尝试我们的 Trojan Source 的模拟（公共任务），然后阅读 特洛伊木马来源研究。
11月初，剑桥大学发布了他们的 名为 Trojan-Source 的研究。这项研究的重点是如何使用定向格式化字符将后门隐藏在源代码和注释中。它们可用于编写代码，编译器对逻辑的解释与人工代码审查员的解释有所不同。
这个漏洞是新出现的，尽管过去曾有人恶意使用 Unicode，例如通过以下方式隐藏文件的真实文件扩展名 反转文件名最后一部分的方向。最近的研究表明，许多编译器会在没有警告的情况下忽略源代码中的Unicode字符，而包括代码编辑器在内的文本编辑器可能会重排包含注释和基于这些字符的代码的行。因此，编辑器显示代码和注释的方式可能与编译器解析代码和注释的方式有所不同，甚至可以互换代码和注释。
请继续阅读以了解更多信息。或者，如果你想卷起袖子试一试 Trojan Source 的模拟黑客攻击，可以试试我们的免费版 公共使命 亲自体验一下。
双向文本
其中一种特洛伊木马源攻击使用了 Unicode Bidi（双向）算法，该算法处理如何将具有不同显示顺序（例如英语（从左到右）和阿拉伯语（从右到左）的文本组合在一起。定向格式化字符可用于重新组织分组和显示字符顺序。
上表包含一些与攻击有关的 Bidi 替换角色。举个例子，
RLI e d o c PDI
缩写 RLI 代表 从右到左隔离。它将把文本与其上下文隔离开来（由 PDI 分隔， 流行定向隔离），并将从右向左读取。导致：
c o d e
但是，编译器和解释器通常不会在解析源代码之前处理格式控制字符，包括 Bidi 覆盖。如果他们只是忽略方向格式化字符，他们就会解析：
e d o c
新瓶装旧酒？
当然，这在阳光下并不是什么新鲜事。过去，定向格式化字符是 插入到文件名中 掩盖他们的恶意本质。如果不是 RLO，显示为 “myspecialexe.doc” 的电子邮件附件可能看起来足够纯真 (从右到左的超控) 出现的角色显示真名是 “myspecialcod.exe”。
Trojan Source 攻击会在源代码中的注释和字符串中插入定向格式化字符，因为这些字符不会生成任何语法或编译错误。这些控制字符改变了代码逻辑的显示顺序，导致编译器读取的内容与人类读取的内容完全不同。
例如，一个按此顺序包含以下字节的文件：
将按方向格式化字符进行重新排序，如下所示
如果没有明确调出方向格式化字符，则会导致代码像这样呈现：
RLO 在最后一行将右大括号翻转为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
（来源：https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx）
这会对你产生什么影响？
许多语言都容易受到攻击：C、C++、C#、JavaScript、Java、Rust、Go 和 Python，据推测还有更多。现在，普通的开发人员可能会对在源代码中看到定向格式化字符不屑一顾，但新手也可能耸了耸肩，什么都不想。此外，这些角色的可视化高度依赖于 IDE，因此不能保证它们会被发现。
但是，这个漏洞一开始怎么会潜入源代码呢？首先，当使用来自不可信来源的源代码时，可能会发生这种情况，而恶意代码贡献却没有被注意到。其次，这可以通过简单地从互联网上找到的代码中复制粘贴来实现，这是我们大多数开发人员以前做过的事情。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题，我们可以在多大程度上完全信任和依赖这段代码？我们如何筛选包含隐藏后门的源代码？
这是谁的问题？
一方面，编译器和编译管道应禁止使用多个方向的源代码行，除非一个方向严格限于字符串和注释。请注意，字符串或注释中的方向格式化字符如果没有弹出，则可以将方向变化延伸到行尾。通常，代码编辑器应明确呈现和突出显示可疑的 Unicode 字符，例如同形文字和定向格式化字符。自 11 月以来，GitHub 现在会在每行包含双向 unicode 文本的代码中添加警告标志和消息，尽管它没有突出显示这些字符在行中的位置。这仍可能允许恶意的方向改变以及良性的方向变化潜入。
开发人员和代码审查者的意识至关重要，这就是为什么我们创建了一个演练来说明漏洞。目前，本演练可用于 Java、C#、Python、GO 和 PHP。
因此，如果您想了解更多，请尝试我们的 Trojan Source 的模拟（公共任务），然后阅读 特洛伊木马来源研究。
点击下面的链接并下载此资源的PDF。
Secure Code Warrior可以帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全放在首位的文化。无论您是 AppSec 经理、开发人员、首席信息安全官还是任何与安全相关的人，我们都可以帮助您的组织降低与不安全代码相关的风险。
查看报告预订演示
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
11月初，剑桥大学发布了他们的 名为 Trojan-Source 的研究。这项研究的重点是如何使用定向格式化字符将后门隐藏在源代码和注释中。它们可用于编写代码，编译器对逻辑的解释与人工代码审查员的解释有所不同。
这个漏洞是新出现的，尽管过去曾有人恶意使用 Unicode，例如通过以下方式隐藏文件的真实文件扩展名 反转文件名最后一部分的方向。最近的研究表明，许多编译器会在没有警告的情况下忽略源代码中的Unicode字符，而包括代码编辑器在内的文本编辑器可能会重排包含注释和基于这些字符的代码的行。因此，编辑器显示代码和注释的方式可能与编译器解析代码和注释的方式有所不同，甚至可以互换代码和注释。
请继续阅读以了解更多信息。或者，如果你想卷起袖子试一试 Trojan Source 的模拟黑客攻击，可以试试我们的免费版 公共使命 亲自体验一下。
双向文本
其中一种特洛伊木马源攻击使用了 Unicode Bidi（双向）算法，该算法处理如何将具有不同显示顺序（例如英语（从左到右）和阿拉伯语（从右到左）的文本组合在一起。定向格式化字符可用于重新组织分组和显示字符顺序。
上表包含一些与攻击有关的 Bidi 替换角色。举个例子，
RLI e d o c PDI
缩写 RLI 代表 从右到左隔离。它将把文本与其上下文隔离开来（由 PDI 分隔， 流行定向隔离），并将从右向左读取。导致：
c o d e
但是，编译器和解释器通常不会在解析源代码之前处理格式控制字符，包括 Bidi 覆盖。如果他们只是忽略方向格式化字符，他们就会解析：
e d o c
新瓶装旧酒？
当然，这在阳光下并不是什么新鲜事。过去，定向格式化字符是 插入到文件名中 掩盖他们的恶意本质。如果不是 RLO，显示为 “myspecialexe.doc” 的电子邮件附件可能看起来足够纯真 (从右到左的超控) 出现的角色显示真名是 “myspecialcod.exe”。
Trojan Source 攻击会在源代码中的注释和字符串中插入定向格式化字符，因为这些字符不会生成任何语法或编译错误。这些控制字符改变了代码逻辑的显示顺序，导致编译器读取的内容与人类读取的内容完全不同。
例如，一个按此顺序包含以下字节的文件：
将按方向格式化字符进行重新排序，如下所示
如果没有明确调出方向格式化字符，则会导致代码像这样呈现：
RLO 在最后一行将右大括号翻转为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
（来源：https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx）
这会对你产生什么影响？
许多语言都容易受到攻击：C、C++、C#、JavaScript、Java、Rust、Go 和 Python，据推测还有更多。现在，普通的开发人员可能会对在源代码中看到定向格式化字符不屑一顾，但新手也可能耸了耸肩，什么都不想。此外，这些角色的可视化高度依赖于 IDE，因此不能保证它们会被发现。
但是，这个漏洞一开始怎么会潜入源代码呢？首先，当使用来自不可信来源的源代码时，可能会发生这种情况，而恶意代码贡献却没有被注意到。其次，这可以通过简单地从互联网上找到的代码中复制粘贴来实现，这是我们大多数开发人员以前做过的事情。大多数组织依赖来自多个供应商的软件组件。这就提出了一个问题，我们可以在多大程度上完全信任和依赖这段代码？我们如何筛选包含隐藏后门的源代码？
这是谁的问题？
一方面，编译器和编译管道应禁止使用多个方向的源代码行，除非一个方向严格限于字符串和注释。请注意，字符串或注释中的方向格式化字符如果没有弹出，则可以将方向变化延伸到行尾。通常，代码编辑器应明确呈现和突出显示可疑的 Unicode 字符，例如同形文字和定向格式化字符。自 11 月以来，GitHub 现在会在每行包含双向 unicode 文本的代码中添加警告标志和消息，尽管它没有突出显示这些字符在行中的位置。这仍可能允许恶意的方向改变以及良性的方向变化潜入。
开发人员和代码审查者的意识至关重要，这就是为什么我们创建了一个演练来说明漏洞。目前，本演练可用于 Java、C#、Python、GO 和 PHP。
因此，如果您想了解更多，请尝试我们的 Trojan Source 的模拟（公共任务），然后阅读 特洛伊木马来源研究。
帮助您入门的资源
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
