文章总结： 本文解读BlackHatUSA2026议题，指出Unicode已成为贯穿WAF、框架、数据库和AI系统的分布式解析攻击面。展示五大攻击向量：正则绕过、OAuth重定向、Unicode转义RCE、Cookie前缀绕过及数据库排序规则绕过，并延伸至LLM提示注入与供应链隐藏。建议安全工具全面识别Unicode变体、审计正则配置、建立空白字符清单。 综合评分： 85 文章分类： 漏洞分析,web安全,红队,安全工具,ai安全

Beyond Normalization：Unicode 攻击面正在扩张

原创

AIxSec69 AIxSec69

AIxSec69

2026年8月29日 10:32 美国

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

Beyond Normalization：Unicode 攻击面正在扩张

来源：Black Hat USA 2026 Briefings

标题：Beyond Normalization: The Expanding Unicode Attack Surface

作者：Ryan Barnett（Senior Threat Research Manager, Akamai）、Isabella Barnett（Security Researcher / Student）

适合读者：Web 安全研究者、WAF 开发者、应用安全工程师、框架/数据库安全开发者

简介：Unicode 不仅仅是字符”归一化”的问题——它是一个贯穿 WAF、框架、数据库和 AI 系统的分布式解析攻击面。Akamai 研究员 Ryan Barnett 与 Isabella Barnett 在 Black Hat USA 2026 上展示了五个真实攻击向量：非法 UTF-8 绕过 RE2 正则引擎、Unicode 代理对劫持 OAuth 重定向、多种 Unicode 转义变体实现 RCE（CVE-2025-55182）、零宽空格绕过 __Host- Cookie 前缀保护、数据库排序规则零权重字符绕过过滤，以及不可见 Unicode 对 LLM 和软件供应链的威胁。本文基于 Black Hat USA 2026 官方议题和 158 页演讲 Slides 深入解读。

◆ ◆ ◆

2021 年 12 月 9 日晚上 10 点 55 分（美国东部时间），一条关于 Apache Log4j 的推文让整个互联网安全圈陷入紧急响应状态。Log4Shell（CVE-2021-44228）的发现方式很简单：攻击者注意到 Log4j 会对 ${jndi:ldap://...} 这样的字符串执行 JNDI 查找——而传入的字符串中含有 Unicode 编码的字符在解析后被还原，轻易绕过了当时的输入过滤。

Log4Shell 已经过去将近五年。但 Unicode 作为攻击面，是否真的得到了系统性的审视？

2025 年 Black Hat USA 上，Ryan Barnett 和 Isabella Barnett 发表了”Lost in Translation: Exploiting Unicode Normalization”，展示了 Unicode 归一化不一致带来的安全问题。一年后的 Black Hat USA 2026，他们带着更深度的研究回来了——“Beyond Normalization”。

他们给出的核心判断是：”Unicode is no longer just a normalization problem. It is an architectural attack surface.”（Unicode 不再只是一个归一化问题，它已经成为一种架构级的攻击面。）

为什么 Unicode 是”分布式”攻击面？

任何一个现代 Web 应用的输入处理管道都包含多个层次：URL 解码器、UTF-8 验证器、WAF 规则引擎、框架参数解析器、HTML 实体解码器、数据库排序规则、以及越来越常见的 LLM 预处理层。

关键不在于每一层有没有做编码处理——而在于每一层对”什么是合法字符””什么是等价字符””什么应该被过滤”的定义不同。演讲者将这种层与层之间的处理差异定义为分布式解析漏洞（distributed parsing vulnerability），并为每类攻击映射了对应的 CWE（Common Weakness Enumeration）和 CAPEC（Common Attack Pattern Enumeration and Classification）。

▲ Unicode 攻击面概览：从 Log4Shell 到多层解析管道（来源：Black Hat USA 2026 Slides）

五大攻击向量

演讲者通过 158 页 Slides 系统性地展示了五个独立但相互关联的 Unicode 攻击向量，每个都绕过了不同层次的安全控制。

1. 正则表达式绕过：UTF-8 vs. Latin1

第一个攻击向量针对的是正则引擎的配置差异。现代应用中广泛使用的 Google RE2 正则引擎在匹配时，对字符串的编码假设取决于配置选项。

核心问题在于：当 WAF 或验证层使用 UTF-8 对输入做正则匹配时，攻击者可能传入一个被解析为 Latin1 的字节序列。同一个字节在两种编码下对应不同的字符——在 UTF-8 下可能被识别为非法序列并被过滤，在 Latin1 下却是一个”看起来无害”的普通字符。攻击者利用这种编码上下文的不一致，让恶意 payload 在 WAF 的正则检查”通过”，然后在后端框架的解析器中被还原为攻击字符。

Slides 中展示了一个具体的例子：一个看似被正则匹配”成功拦截”的 payload，实际上在后续处理层中因为 Latin1 解码还原了攻击意图。用演讲者的话说：”The regex matched the payload. What’s the problem???”

与此相关的 CWE 是 CWE-185: Incorrect Regular Expression，而攻击模式分类为 CAPEC-43: Exploiting Multiple Input Interpretation Layers——多层输入解释的攻击利用。

2. OAuth 开放重定向：Unicode 代理对的妙用

第二个攻击向量利用了 Unicode 代理对（Surrogate Pairs）在 URI 解析中的”消失”行为。

Unicode 代理对是 UTF-16 编码中用于表示 BMP（基本多文种平面）之外字符的机制。一个”低代理”（Low Surrogate）单独出现时，在不同的 URI 解析库中会被不同地处理——有些库会将其转换为替换字符 U+FFFD，有些库会直接丢弃，有些库则原样保留。

攻击通过在 OAuth 回调 URL 或开放重定向参数中插入低代理字符，使得 WAF 和安全网关在检查 URL 时看到的是”安全”的目标域名，但浏览器在渲染时（经过替换或丢弃处理）将用户实际重定向到恶意域名。这本质上是一种解析器失配攻击。

对应的 CWE 为 CWE-176: Improper Handling of Unicode Encoding，CAPEC 分类为 CAPEC-43。

3. Unicode 转义 RCE：不止一种写法（CVE-2025-55182）

演讲者花了大量篇幅（Slides Page 60-85）展示 Unicode 转义序列的多样性如何导致 RCE。

一个 JSON 格式的攻击 payload 可能长这样：

{"id":"fs#readFileSync","bound":["/etc/passwd"]}

Unicode 转义有至少六种不同的写法变体：

• JavaScript 标准 \uHHHH 格式

• ECMAScript 6 码点转义 \u{HHHH} 格式

• Microsoft 特有的 %uHHHH 格式

• C/C++/Go 的 \U00XX 格式

• Unicode 命名转义 \N{NAME} 格式

• 十六进制字节编码 \xHH 格式

问题在于：不同的解析层认识不同的转义格式。WAF 可能认识 \uHHHH 并做了过滤，但后端 JavaScript 引擎（如 Jackson）在处理十六进制溢出时，charToHex() 的字节截断行为产生了意料之外的字符还原。攻击者可以利用 Jackson 对某些中间状态的容忍性，构造经过多层转义编码的 payload，让 WAF 看到的是”安全的”JSON 对象，而 JavaScript 引擎执行的是任意代码。Slides 引用了 CVE-2025-55182 作为此类 Unicode 编码 RCE 的实例进行分析，并展示了 Hackvertor 扩展如何用于 Unicode 转义编解码测试。相关 CWE 为 CWE-176 和 CWE-129: Improper Validation of Array Index，CAPEC 为 CAPEC-71: Using Unicode Encoding to Bypass Validation Logic。

▲ Unicode 转义 RCE 攻击示例：JSON payload 经多种转义变体绕过 WAF（来源：Black Hat USA 2026 Slides）

4. Cookie 前缀绕过：空白字符的细微差异

\_\_Host- 是 HTTP Cookie 的一个安全前缀，用于确保 cookie 仅通过 HTTPS 传输、且不能被子域名覆盖。理论上，加了 \_\_Host- 前缀的 cookie 不应该被 JavaScript 篡改。

但演讲者发现了一个微妙的问题：Unicode 中有大量被视为”空白”但并非 ASCII 空格（0x20）的字符——包括零宽空格（Zero Width Space, U+200B）、不间断空格（U+00A0）等。当这些字符出现在 \_\_Host-name 这样的 cookie 名称中时：

– ASP.NET Core（Microsoft.AspNetCore.Http）在调用 Request.Cookies["\_\_Host-name"] 时，返回的是 cookie 数组中的最后一个匹配值——可能被攻击者覆盖。

– 旧版 .NET Framework（System.Web）则返回第一个匹配值——可能是合法的原始值。

这意味着同一个攻击在不同的 .NET 版本上产生截然不同的结果。攻击者可以同时注入一个带空白变体的冒牌 \_\_Host- cookie 和一个恶意的同名 cookie，根据目标框架的取值逻辑，通过 JavaScript 或中间人篡改来覆盖合法会话。

此外，微软旧版系统的 Best-Fit 映射会将某些 Unicode 字符”最佳匹配”到 ASCII 等价字符——例如某些带重音的拉丁字母会被映射到无重音版本。这种行为在 Windows 环境中引入了另一层不可见的字符等价关系。

相关 CWE 为 CWE-156: Improper Neutralization of Whitespace 和 CWE-697: Incorrect Comparison，CAPEC 为 CAPEC-153: Input Data Manipulation。

5. 数据库排序规则绕过：零权重字符

第五个攻击向量针对的是 MySQL utf8mb4 排序规则（Collation）中的”零权重”（zero-weight）字符。

在 MySQL 中，排序规则决定了字符如何比较和排序。演讲者通过 WEIGHT\_STRING() 函数演示了令人吃惊的结果：

-- 在 utf8mb4\_0900\_ai\_ci（accent insensitive, case insensitive）下

SELECT 'ȁ' = 'a' COLLATE utf8mb4\_0900\_ai\_ci AS comparison\_result;

-- 结果：1（相等）

这意味着带双重音符的拉丁字母 ȁ 在比较时被视作等同于 a。攻击者可以利用这一点，在一个设置了 accent-insensitive 排序规则的列中，用 ȁ 代替 a 来构造 SQL 查询——在应用层的输入过滤器中 ȁ 和 a 是不同的字符串，但在数据库层面它们被判定为相等，从而绕过了基于字符串精确匹配的过滤逻辑。

更隐蔽的是 零宽空格（U+200B）。在 accent-sensitive 的排序规则 utf8mb4\_0900\_as\_cs 下：

SELECT 'ab' = 'ab' COLLATE utf8mb4\_0900\_as\_cs AS comparison\_result;

-- 结果：1（相等——零宽空格在排序比较中被忽略）

只有当使用二进制排序规则 utf8mb4\_bin 时，零宽空格才会被正确区分。

这个问题的本质是：排序规则定义了一个”比较空间”，而这个空间中的等价关系与肉眼所见不同。攻击者可以在不改变字符串视觉效果的情况下，注入比较层面等价但过滤层面不等价的字符，实现绕过。

Unicode 的新战场：LLM 和供应链

议题的后三分之一讨论了 Unicode 在两个新兴领域的威胁。

LLM 提示注入。零宽空格、从右到左覆盖（RLO, U+202E）等不可见或格式控制字符可以被嵌入自然语言文本中，对 LLM 的 tokenizer 产生干扰。Slides 演示了在”make explosives”这样的短语中嵌入 “ 零宽空格，tokenizer 可能将单词拆散为不同的 token 片段，导致内容过滤失效。同时，RLO 字符可以反转文本的视觉方向——人类读者看到的是一段无害文本，但 LLM 读取的实际字符顺序可能完全相反。对应的 CWE 为 CWE-1427: Improper Neutralization of Input Used for LLM Prompting。

软件供应链隐藏。Unicode Plane 14（补充特殊用途平面）中包含标签字符（Tags block），设计用于嵌入不可见的元数据。攻击者利用这些字符将加密的恶意载荷隐藏在看似正常的开源代码文件中。Slides 演示了在 GitHub 仓库的源代码中，利用标签字符编码整个加密 payload——肉眼完全看不到，GitHub 的代码审查界面也不会显示，但脚本可以通过解码 Plane 14 字符还原并执行恶意代码。相关的 CWE 为 CWE-829: Inclusion of Functionality from Untrusted Control Sphere。

▲ Unicode Plane 14 标签字符：在开源仓库中隐藏加密恶意载荷（来源：Black Hat USA 2026 Slides）

防御建议

演讲者在总结中给出了”Key Takeaways”五条核心建议：

1. 解码能力审视：确保安全检测工具（WAF、SAST、DAST）能够识别和处理所有 Unicode 转义变体（不仅仅是 \uHHHH），包括 ES6 码点转义、C/Go 变体、命名转义等。

2. 正则配置审计：检查 WAF 和应用中使用的正则引擎配置——RE2、PCRE、Java Pattern 等对 Unicode 的处理模式不同。确认 UTF-8 vs. Latin1 的处理一致性。

3. 空白字符处理：建立一份超出 ASCII 空格（0x20）的完整空白字符清单，审计所有输入处理层对这些字符的处理行为。特别注意零宽空格（U+200B）、不间断空格（U+00A0）和从右到左标记（RLO, U+202E）。

4. 数据库排序规则：检查生产数据库中各列的排序规则设置。避免使用 accent-insensitive 和 case-insensitive 排序规则处理安全敏感的数据比较。安全关键的比较应使用二进制排序规则（如 utf8mb4\_bin）。

5. 不可见字符处理：在 LLM 输入预处理的 tokenization 之前去除不可见 Unicode 字符（零宽空格、变体选择器、格式控制字符、Plane 14 标签字符）。代码审查工具应考虑检测隐藏的 Unicode 元数据。

演讲者同时预告了 Burp Suite Activescan++ 扫描器已新增 Unicode 相关的检测规则，以及 Hackvertor 扩展的编解码功能更新。

写在最后

“Beyond Normalization”这个议题标题本身就说明了一切。五年前，Log4Shell 告诉我们 Unicode 可以绕过安全控制。今天，Ryan Barnett 和 Isabella Barnett 告诉我们：Unicode 的问题远远超出了归一化——它是一个架构级的攻击面，需要系统性的方法论来审计。

从正则引擎的编码假设，到 URI 解析器的代理对处理，到 JavaScript 引擎的多格式转义支持，到 Cookie 前缀的空白字符歧义，再到数据库排序规则的零权重等价——Unicode 的复杂性与 Web 技术栈的多层架构交织在一起，形成了一个边界模糊、责任分散的安全盲区。

最后一点尤其值得关注：Unicode 作为 LLM 和供应链攻击的载体正在快速演化。当不可见字符可以骗过大语言模型的内容过滤器，当 Plane 14 标签字符可以在开源仓库中隐藏恶意载荷——这些不是明天的问题，是今天的问题。

◆ ◆ ◆

原文链接：https://www.blackhat.com/us-26/briefings/schedule/#beyond-normalization-the-expanding-unicode-attack-surface-52318

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AIxSec69 AIxSec69 AIxSec69《Beyond Normalization：Unicode 攻击面正在扩张》