潜伏在代码中的“幽灵”：Glassworm Unicode 攻击再次席卷开源社区

引言：看不见的供应端威胁

最近，安全研究人员发现一种名为 Glassworm 的攻击手段正卷土重来。这种攻击利用 Unicode 字符的特殊属性，在 GitHub 仓库、npm 软件包以及 IDE（如 VS Code）中植入肉眼不可见的恶意代码。这种攻击之所以危险，是因为它直接针对开发者的信任链——你看到的代码与编译器实际执行的代码完全不同。

技术深挖：什么是 Glassworm 攻击？

Glassworm 攻击的核心在于利用 Unicode 编码的复杂性。它通常结合了以下几种技术手段：

• 零宽字符 (Zero-Width Characters)： 例如 U+200B (Zero Width Space) 或 U+200C (ZWNJ)。这些字符在大多数编辑器中完全不占空间，但会被编译器视为代码的一部分或标识符的差异。
• 同形文字攻击 (Homoglyph Attacks)： 使用外观极其相似但编码不同的字符（如拉丁字母 ‘a’ 和西里尔字母 ‘а’）来替换变量名。
• 双向文本 (BiDi) 操纵： 利用 U+202E (Right-to-Left Override) 等控制字符改变代码的显示顺序，使原本属于注释的恶意代码在视觉上移动到了可执行区域，即所谓的 Trojans Source 漏洞。

攻击场景分析：从 VS Code 到 npm

在这一波 Glassworm 攻击中，研究人员观察到攻击者正试图通过以下路径渗透开发环境：

首先是 VS Code 渲染漏洞。尽管许多 IDE 已经增加了对可疑 Unicode 字符的警告，但 Glassworm 变种通过复杂的嵌套组合，成功绕过了部分检测逻辑，使得开发者在进行 Code Review 时无法识别出异常。其次是 npm 生态系统，攻击者在 package.json 或 install scripts 中混入这些不可见字符，导致自动化构建工具执行了非预期的恶意逻辑。

为什么传统的扫描工具会失效？

大多数静态代码分析 (SAST) 工具和正则表达式扫描器主要针对 ASCII 字符设计。当遇到复杂的 Unicode 混淆时，这些工具往往会将其视为普通字符串或合法标识符。此外，Git 在处理差异对比 (git diff) 时，如果不开启特定参数，也很难直观地展示这些微小的编码差异。

关键要点：开发者如何防范？

• 启用 IDE 警告： 在 VS Code 中，确保开启 Editor: Unicode Highlight 相关设置，以高亮显示非 ASCII 字符。
• 强制执行 Linter 规则： 在 CI/CD 流程中加入 ESLint 等工具，并配置禁用不可见字符或非标 Unicode 字符的规则。
• 审视第三方依赖： 使用 npm audit 或专门的供应链安全工具（如 Aikido）来监测代码库中是否存在已知的 Glassworm 模式。
• 透明度检查： 在处理敏感业务逻辑时，使用文本渲染器的“显示所有字符”模式，确保代码的“所见即所得”。