什么是木马源，它是如何潜入你的源代码的？
11月初，剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码，而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过，例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示，许多编译器会忽略源代码中的Unicode字符而不发出警告，而文本编辑器，包括代码编辑器，可能会将包含注释和代码的行回流。因此，编辑器可能会以不同的方式显示代码和注释，并且以不同的顺序显示，这与编译器的解析方式不同，甚至是代码和注释的互换。
继续阅读以了解更多信息。或者，如果你想卷起袖子，尝试模拟黑客攻击木马源，请跳进我们的免费公开任务，亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi（双向）算法，该算法处理如何将显示顺序不同的文本放在一起，如英语（从左到右）和阿拉伯语（从右到左）。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文（由PDI，Pop-Directional-Isolate划定）中分离出来，并从右到左进行阅读。结果是。
ǞǞǞ
然而，编译器和解释器在解析源代码之前通常不处理格式化控制字符，包括Bidi重写。如果他们简单地忽略了方向性的格式化字符，他们就会进行解析。
e d o c
新瓶装旧酒？
当然，这在阳光下并不新鲜。在过去，定向格式化字符被插入文件名中，以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜，如果不是因为出现了RLO（从右到左的覆盖）字符，揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符，因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序，导致编译器读取的内容与人类完全不同。
例如，一个包含以下字节的文件，按这个顺序排列。
将通过方向性的格式化字符重新排序如下
导致代码被渲染成这样，如果方向性的格式化字符没有被明确地叫出来。
在最后一行，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现在为每一行包含双向单码文本的代码添加警告标志和信息，尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的，这就是为什么我们创建了一个说明该漏洞的演练。目前，该演练适用于Java、C#、Python、GO和PHP。
因此，如果你想了解更多，可以试试我们对木马源的模拟（公共missions ），并阅读木马源研究报告。
11月初，剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码，而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过，例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示，许多编译器会忽略源代码中的Unicode字符而不发出警告，而文本编辑器，包括代码编辑器，可能会将包含注释和代码的行回流。因此，编辑器可能会以不同的方式显示代码和注释，并且以不同的顺序显示，这与编译器的解析方式不同，甚至是代码和注释的互换。
继续阅读以了解更多信息。或者，如果你想卷起袖子，尝试模拟黑客攻击木马源，请跳进我们的免费公开任务，亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi（双向）算法，该算法处理如何将显示顺序不同的文本放在一起，如英语（从左到右）和阿拉伯语（从右到左）。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文（由PDI，Pop-Directional-Isolate划定）中分离出来，并从右到左进行阅读。结果是。
ǞǞǞ
然而，编译器和解释器在解析源代码之前通常不处理格式化控制字符，包括Bidi重写。如果他们简单地忽略了方向性的格式化字符，他们就会进行解析。
e d o c
新瓶装旧酒？
当然，这在阳光下并不新鲜。在过去，定向格式化字符被插入文件名中，以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜，如果不是因为出现了RLO（从右到左的覆盖）字符，揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符，因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序，导致编译器读取的内容与人类完全不同。
例如，一个包含以下字节的文件，按这个顺序排列。
将通过方向性的格式化字符重新排序如下
导致代码被渲染成这样，如果方向性的格式化字符没有被明确地叫出来。
在最后一行，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现在为每一行包含双向单码文本的代码添加警告标志和信息，尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的，这就是为什么我们创建了一个说明该漏洞的演练。目前，该演练适用于Java、C#、Python、GO和PHP。
因此，如果你想了解更多，可以试试我们对木马源的模拟（公共missions ），并阅读木马源研究报告。
11月初，剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码，而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过，例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示，许多编译器会忽略源代码中的Unicode字符而不发出警告，而文本编辑器，包括代码编辑器，可能会将包含注释和代码的行回流。因此，编辑器可能会以不同的方式显示代码和注释，并且以不同的顺序显示，这与编译器的解析方式不同，甚至是代码和注释的互换。
继续阅读以了解更多信息。或者，如果你想卷起袖子，尝试模拟黑客攻击木马源，请跳进我们的免费公开任务，亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi（双向）算法，该算法处理如何将显示顺序不同的文本放在一起，如英语（从左到右）和阿拉伯语（从右到左）。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文（由PDI，Pop-Directional-Isolate划定）中分离出来，并从右到左进行阅读。结果是。
ǞǞǞ
然而，编译器和解释器在解析源代码之前通常不处理格式化控制字符，包括Bidi重写。如果他们简单地忽略了方向性的格式化字符，他们就会进行解析。
e d o c
新瓶装旧酒？
当然，这在阳光下并不新鲜。在过去，定向格式化字符被插入文件名中，以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜，如果不是因为出现了RLO（从右到左的覆盖）字符，揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符，因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序，导致编译器读取的内容与人类完全不同。
例如，一个包含以下字节的文件，按这个顺序排列。
将通过方向性的格式化字符重新排序如下
导致代码被渲染成这样，如果方向性的格式化字符没有被明确地叫出来。
在最后一行，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现在为每一行包含双向单码文本的代码添加警告标志和信息，尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的，这就是为什么我们创建了一个说明该漏洞的演练。目前，该演练适用于Java、C#、Python、GO和PHP。
因此，如果你想了解更多，可以试试我们对木马源的模拟（公共missions ），并阅读木马源研究报告。
11月初，剑桥大学发布了他们 名为Trojan-Source的研究。这项研究的重点是如何利用定向格式化字符将后门隐藏在源代码和注释中。这些可以被用来制作代码，而编译器对这些代码的逻辑解释与人类代码审查者不同。
这个漏洞是新的--尽管Unicode在过去曾被邪恶地使用过，例如通过颠倒文件名的最后部分的方向来隐藏文件的真正扩展名。最近的研究显示，许多编译器会忽略源代码中的Unicode字符而不发出警告，而文本编辑器，包括代码编辑器，可能会将包含注释和代码的行回流。因此，编辑器可能会以不同的方式显示代码和注释，并且以不同的顺序显示，这与编译器的解析方式不同，甚至是代码和注释的互换。
继续阅读以了解更多信息。或者，如果你想卷起袖子，尝试模拟黑客攻击木马源，请跳进我们的免费公开任务，亲自体验。
双向文本
其中一个木马源攻击利用了Unicode Bidi（双向）算法，该算法处理如何将显示顺序不同的文本放在一起，如英语（从左到右）和阿拉伯语（从右到左）。方向性的格式化字符可以用来重新组织分组和显示字符的顺序。
上表包含了一些与攻击有关的比迪覆盖字符。以此为例。
RLIe d o cPDI
缩写RLI是指从右到左的隔离。它将把文本从其上下文（由PDI，Pop-Directional-Isolate划定）中分离出来，并从右到左进行阅读。结果是。
ǞǞǞ
然而，编译器和解释器在解析源代码之前通常不处理格式化控制字符，包括Bidi重写。如果他们简单地忽略了方向性的格式化字符，他们就会进行解析。
e d o c
新瓶装旧酒？
当然，这在阳光下并不新鲜。在过去，定向格式化字符被插入文件名中，以掩盖其恶意的性质。一个显示为 "myspecialexe.doc "的电子邮件附件可能看起来很无辜，如果不是因为出现了RLO（从右到左的覆盖）字符，揭示了真正的名称是 "myspecialcod.exe"。
木马源码攻击在源代码中存在的注释和字符串中插入定向格式化字符，因为这些不会产生任何语法或编译错误。这些控制字符改变了代码的逻辑显示顺序，导致编译器读取的内容与人类完全不同。
例如，一个包含以下字节的文件，按这个顺序排列。
将通过方向性的格式化字符重新排序如下
导致代码被渲染成这样，如果方向性的格式化字符没有被明确地叫出来。
在最后一行，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现在为每一行包含双向单码文本的代码添加警告标志和信息，尽管它没有突出显示这些字符在行中的位置。这仍然可能使恶意的方向变化与良性的方向变化一起潜入。
开发人员和代码审查人员的认识是至关重要的，这就是为什么我们创建了一个说明该漏洞的演练。目前，该演练适用于Java、C#、Python、GO和PHP。
因此，如果你想了解更多，可以试试我们对木马源的模拟（公共missions ），并阅读木马源研究报告。
资源
OpenText 应用程序安全性的强大功能 + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
