Unicode Normalization

Reading time: 8 minutes

这是一个总结: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. 查看以获取更多详细信息（图像来自那里）。

理解 Unicode 和规范化

Unicode 规范化是一个确保字符的不同二进制表示标准化为相同二进制值的过程。这个过程在编程和数据处理中的字符串处理至关重要。Unicode 标准定义了两种字符等价性：

1. 规范等价性：如果字符在打印或显示时具有相同的外观和含义，则认为它们是规范等价的。
2. 兼容等价性：一种较弱的等价形式，其中字符可能表示相同的抽象字符，但可以以不同的方式显示。

有 四种 Unicode 规范化算法：NFC、NFD、NFKC 和 NFKD。每种算法以不同的方式采用规范和兼容性规范化技术。要深入了解，可以在 Unicode.org 上探索这些技术。

关于 Unicode 编码的关键点

理解 Unicode 编码至关重要，特别是在处理不同系统或语言之间的互操作性问题时。以下是主要要点：

• 代码点和字符：在 Unicode 中，每个字符或符号被分配一个称为“代码点”的数值。
• 字节表示：代码点（或字符）在内存中由一个或多个字节表示。例如，LATIN-1 字符（在英语国家常见）使用一个字节表示。然而，字符集较大的语言需要更多字节进行表示。
• 编码：这个术语指的是字符如何转换为一系列字节。UTF-8 是一种流行的编码标准，其中 ASCII 字符使用一个字节表示，其他字符最多使用四个字节。
• 处理数据：处理数据的系统必须了解所使用的编码，以正确地将字节流转换为字符。
• UTF 的变体：除了 UTF-8，还有其他编码标准，如 UTF-16（使用最少 2 个字节，最多 4 个）和 UTF-32（对所有字符使用 4 个字节）。

理解这些概念对于有效处理和减轻因 Unicode 的复杂性及其各种编码方法而产生的潜在问题至关重要。

Unicode 如何规范化两个表示相同字符的不同字节的示例：

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

Unicode 等效字符列表可以在这里找到： https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html 和 https://0xacb.com/normalization_table

发现

如果你能在一个 webapp 中找到一个被回显的值，你可以尝试发送 ‘KELVIN SIGN’ (U+0212A)，它 规范化为 "K"（你可以将其发送为 %e2%84%aa）。 如果回显了 "K"，那么某种 Unicode 规范化 正在进行。

另一个 例子：%F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 在 unicode 之后是 Leonishan。

易受攻击的示例

SQL 注入过滤器绕过

想象一个网页，它使用字符 ' 来创建带有用户输入的 SQL 查询。这个网页作为安全措施，删除 用户输入中所有出现的字符 '，但 在删除之后 和 在创建 查询之前，它 使用 Unicode 规范化 用户的输入。

然后，一个恶意用户可以插入一个不同的 Unicode 字符，等效于 ' (0x27)，如 %ef%bc%87，当输入被规范化时，会创建一个单引号，从而出现 SQL 注入漏洞：

一些有趣的 Unicode 字符

• o -- %e1%b4%bc
• r -- %e1%b4%bf
• 1 -- %c2%b9
• = -- %e2%81%bc
• / -- %ef%bc%8f
• --- %ef%b9%a3
• #-- %ef%b9%9f
• *-- %ef%b9%a1
• ' -- %ef%bc%87
• " -- %ef%bc%82
• | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap 模板

GitHub - carlospolop/sqlmap_to_unicode_template

XSS（跨站脚本攻击）

您可以使用以下字符之一来欺骗 web 应用程序并利用 XSS：

请注意，例如，第一个提议的 Unicode 字符可以发送为：%e2%89%ae 或 %u226e

模糊测试正则表达式

当后端 使用正则表达式检查用户输入 时，输入 可能会为 正则表达式 进行 规范化，但 不 会为其 使用 的地方进行 规范化。例如，在开放重定向或 SSRF 中，正则表达式可能会 规范化发送的 URL，但随后 按原样访问。

工具 recollapse **** 允许 生成输入的变体 以模糊测试后端。有关更多信息，请查看 github 和这篇 文章。

参考文献

• https://labs.spotify.com/2013/06/18/creative-usernames/
• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work
• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html