Unicode Injection

Reading time: 7 minutes

Introduction

根据后端/前端在接收奇怪的unicode字符时的表现，攻击者可能能够绕过保护并注入任意字符，这些字符可能被用于利用注入漏洞，例如XSS或SQLi。

Unicode Normalization

Unicode规范化发生在unicode字符被规范化为ascii字符时。

这种类型漏洞的一个常见场景是，当系统在检查用户输入后以某种方式修改用户的输入时。例如，在某些语言中，简单地调用将输入转换为大写或小写可能会规范化给定的输入，unicode将被转换为ASCII，生成新字符。
有关更多信息，请查看：

Unicode Normalization

\u to %

Unicode字符通常用**\u前缀表示。例如字符㱋是\u3c4b（在这里查看）。如果后端将前缀\u转换为%，则结果字符串将是%3c4b，URL解码后为：<4b。如你所见，<字符被注入。
如果后端存在漏洞，你可以使用此技术注入任何类型的字符。
查看https://unicode-explorer.com/以找到所需的字符。

这个漏洞实际上源于一位研究人员发现的漏洞，想要更深入的解释请查看https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

后端在接收表情符号时表现得有些奇怪。这就是在这篇文章中发生的情况，研究人员成功利用一个有效载荷实现了XSS，例如：💋img src=x onerror=alert(document.domain)//💛

在这种情况下，错误在于服务器在删除恶意字符后将UTF-8字符串从Windows-1252转换为UTF-8（基本上输入编码和转换编码不匹配）。然后这并没有给出一个正确的<，而是一个奇怪的unicode字符：‹
``所以他们将这个输出再次从UTF-8转换为ASCII。这规范化了‹为<，这就是该系统上漏洞能够工作的方式。
这就是发生的事情：

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Emoji 列表：

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
• https://unicode.org/emoji/charts-14.0/full-emoji-list.html

Windows 最佳适配/最差适配

正如**这篇精彩的文章**中所解释的，Windows 有一个叫做 最佳适配 的功能，它会 用一个相似的字符替换 在 ASCII 模式下无法显示的 unicode 字符。这可能导致 意外行为，当后端 期望一个特定字符 但接收到一个不同的字符时。

可以在 https://worst.fit/mapping/ 找到最佳适配字符。

由于 Windows 通常会在执行的最后阶段将 unicode 字符串转换为 ascii 字符串（通常是从带有 "W" 后缀的 API 转换为带有 "A" 后缀的 API，如 GetEnvironmentVariableA 和 GetEnvironmentVariableW），这将允许攻击者通过发送 unicode 字符来绕过保护，这些字符最后会被转换为执行意外操作的 ASCII 字符。

在博客文章中提出了绕过使用 字符黑名单 修复的漏洞的方法，利用 路径遍历 使用 映射到 “/“ (0x2F) 的字符 和 映射到 “\“ (0x5C) 的字符，甚至绕过像 PHP 的 escapeshellarg 或 Python 的 subprocess.run 的 shell 转义保护，使用一个列表，例如使用 全宽双引号 (U+FF02) 代替双引号，这样最终看起来像一个参数的内容被转化为两个参数。

请注意，应用程序要脆弱，需要使用 "W" Windows API，但最终调用 "A" Windows API，因此会创建 unicode 字符串的 "最佳适配"。

发现的多个漏洞将不会被修复，因为人们对谁应该修复这个问题没有达成一致。