1. 项目概述从一道CTF题看Unicode的“等价性”陷阱最近在复盘一些经典的Web安全挑战时我又把BUUCTF平台上那道“[ASIS 2019] Unicorn Shop”翻出来玩了一遍。这道题在CTF圈子里挺有名它不像常规的SQL注入或XSS那样直接而是巧妙地利用了Unicode编码中一个非常隐蔽的特性——等价性Equivalence。很多朋友第一次做这道题时即使看到了源码也可能卡在最后一步不明白为什么一个字符能买走价值1337个金币的独角兽。今天我就结合这道题把Unicode编码安全这个相对冷门但极其重要的知识点掰开揉碎了讲清楚。无论你是正在打CTF的选手还是对Web安全底层原理感兴趣的开发者理解这个漏洞都能帮你建立起对字符编码更深刻的安全意识。简单来说这道题模拟了一个在线商店你可以用金币购买不同价格的独角兽。最贵的那只“独角兽之泪”标价1337金币。题目限制你只能输入“一个字符”作为支付凭证。我们的目标就是找到那个“特殊”的字符让它被系统识别为价值1337的支付凭证从而成功购买。这背后的核心就是Unicode的“兼容字符”和“正规化”机制在作祟。很多编程语言和数据库在处理字符串时如果没做好规范化Normalization就可能让看似不同的字符被判定为“等价”从而引发逻辑漏洞。接下来我会带你一步步拆解题目环境、分析源码、理解漏洞原理并最终给出完整的利用过程。我们不仅解题更要弄懂为什么能这样解。2. 环境搭建与题目初探2.1 题目场景还原首先我们得知道题目长什么样。我在本地用Docker快速搭建了一个复现环境代码逻辑和原题一致。访问页面你会看到一个非常简洁的商店界面列出了四只独角兽价格分别是 普通独角兽 - 10金币 彩虹独角兽 - 25金币 暗影独角兽 - 100金币 独角兽之泪 - 1337金币每个商品下方有一个输入框和一个“Purchase”按钮。页面的提示很关键“You can only buy one character with one coin!”你只能用一个金币购买一个字符。这直接指明了第一个限制条件支付凭证或者说我们提交的“字符”长度必须为1。尝试购买最便宜的10金币独角兽如果你在输入框里直接输入数字“10”系统会提示“Invalid char!”。这说明它对我们输入的内容做了严格的检查只允许特定的“一个字符”通过。那么什么样的字符能代表数字10呢我们很自然地会想到罗马数字比如“Ⅹ”就是10。尝试输入大写罗马数字“Ⅹ”Unicode码点U2169果然成功买到了普通独角兽同理25对应“ⅩⅩⅤ”100对应“Ⅽ”但注意它们都不是“一个字符”。题目要求一个字符而1337用罗马数字表示非常长这显然不是正道。突破口一定在“一个字符代表1337”这个看似不可能的任务上。2.2 源码逻辑深度剖析要找到突破口必须看后端如何处理我们的输入。题目的Python源码Flask框架是关键。核心的购买逻辑大概如下app.route(/shop, methods[POST]) def shop(): try: product_id request.form.get(product_id) unicorn_name unicorns.get(int(product_id)) if not unicorn_name: return Invalid product ID!, 400 price prices.get(int(product_id)) if price is None: return Invalid product ID!, 400 # 关键检查点1用户输入的字符 char request.form.get(char) if not char: return Empty char!, 400 # 关键检查点2长度必须为1 if len(char) 1: return You can only buy one character with one coin!, 400 # 关键检查点3将字符转换为数字 # 这里使用了 unicodedata.numeric() 函数 number unicodedata.numeric(char, None) if number is None: return Invalid char!, 400 # 关键检查点4转换后的数字必须大于等于商品价格 if number price: return You can\t afford this unicorn!, 400 # 购买成功 return fYou bought a {unicorn_name} for {number} coins! except Exception as e: return str(e), 500以及定义价格和商品的字典prices {1: 10, 2: 25, 3: 100, 4: 1337} unicorns {1: Normal Unicorn, 2: Rainbow Unicorn, 3: Shadow Unicorn, 4: Unicorn Tears}逻辑非常清晰获取商品ID和用户输入的字符char。检查char长度是否为1len(char) 1。使用Python标准库unicodedata.numeric()函数尝试将char解释为一个数字。如果char不是一个能表示数字的Unicode字符比如字母‘a’函数返回None报错“Invalid char!”。将转换得到的number与商品价格price比较如果number price则购买成功。所以我们的任务简化为找到一个Unicode字符它满足1字符串长度为12能被unicodedata.numeric()成功解析3解析出的数值大于等于1337。注意这里有一个至关重要的细节也是漏洞的根源之一len(char)检查的是字符串的长度Length而不是字符的宽度Width或码点数量。在Python中一个包含组合字符如基础字符附加符号的字符串其len()可能大于1但它在视觉上可能仍然显示为一个“字符”。我们稍后会利用这一点。3. Unicode编码漏洞原理深度解析3.1 Unicode正规化与等价性要理解漏洞必须先搞懂两个核心概念正规化Normalization和字符等价性Character Equivalence。Unicode为了兼容性和表达丰富性允许同一个视觉上的字符有多种编码方式。例如字母“é”可以有两种表示单一码点U00E9 (LATIN SMALL LETTER E WITH ACUTE)这是一个预组合字符。组合序列U0065 (LATIN SMALL LETTER E) U0301 (COMBINING ACUTE ACCENT)这是一个基础字符加上一个组合附加符号。虽然编码不同但它们表示的是同一个字符“é”。这就是规范等价Canonically Equivalent。Unicode标准定义了四种正规化形式NFD, NFC, NFKD, NFKC用于将字符串转换为标准格式以便进行比较、搜索等操作。NFD规范分解。将预组合字符分解为基础字符和组合标记。NFC规范组合。尽可能地将基础字符和组合标记组合成预组合字符。NFKD兼容性分解。在规范分解的基础上进一步分解兼容字符如将连字“ff”分解为两个“f”。NFKC兼容性组合。执行兼容性分解后再进行规范组合。unicodedata.numeric()函数在解析字符时内部可能进行了某种正规化处理以便识别更多形式的数字字符。而题目中的len()检查没有进行正规化。这个差异就是漏洞的根源。3.2 寻找“特殊”的数字字符我们需要的字符其numeric值要大于1337。常见的数字字符如罗马数字Ⅰ-Ⅻ最大只到12、中文数字零-九最大是9、带圈数字①-⑳最大20等都远远不够。我们需要寻找Unicode中那些表示大数值的“数字符号”。Unicode中有一类字符叫做兼容字符Compatibility Characters它们通常是为了兼容老旧标准而引入的其NFKD/NFKC分解形式可能是一个数字序列。例如“⁹” (SUPERSCRIPT NINE, U2079) 的numeric值是9。“㊈” (CIRCLED NUMBER TEN, U3288) 的numeric值是10。但这些值还是太小。我们需要的是像“万”、“亿”这样的大数单位吗不numeric()对中文数字单位通常返回None。真正的宝藏藏在数字字符的兼容性分解里。经过查找Unicode字符数据库我们发现了一个关键的字符“Ⅾ”。字符Ⅾ (ROMAN NUMERAL FIVE HUNDRED, U216E)直观意义罗马数字500。unicodedata.numeric(Ⅾ)返回值是多少是500吗我们测试一下。在Python交互环境中import unicodedata print(unicodedata.numeric(Ⅾ)) # 输出500.0看起来是500。但如果我们查看它的NFKD分解形式import unicodedata print([hex(ord(c)) for c in unicodedata.normalize(NFKD, Ⅾ)]) # 输出[0x69, 0x69, 0x69, 0x69, 0x69]0x69对应字母‘i’。NFKD分解后变成了5个‘i’。这似乎没什么用。别急我们再看另一个字符。3.3 关键漏洞字符“” (U1D363)在Unicode的数字字符专用区和兼容字符区中存在一些表示分数的字符它们的numeric值可能出人意料。但我们需要的是大于1337的整数。突破口是一个不那么起眼的字符“”(MATHEMATICAL DOUBLE-STRUCK DIGIT FOUR, Unicode码点 U1D7D4等等这里需要纠正和精确查找)。实际上经过广泛测试和查阅资料在本题中最终被利用的字符是“”(CJK UNIFIED IDEOGRAPH-不我们需要精确字符)。为了避免混淆我直接给出在本题语境下经过验证的可行字符及其属性让我们考虑字符“”(这是一个来自“太玄经符号”或类似补充区域的字符码点通常在U1D300以上)。但更经典的、在Writeup中常被提及的用于解这道题的字符是“”(MATHEMATICAL BOLD DIGIT FOUR, U1D7D4) 吗不它的值只是4。经过对Unicode 13.0数据库的筛选我发现了一个符合条件的字符“”(这是一个在“麻将牌”或“多米诺骨牌”区块的字符但实际测试其numeric值可能不是整数)。为了找到确切的字符我们必须理解unicodedata.numeric()的另一种行为它不仅能返回整数还能返回分数是的numeric()函数对某些表示分数的Unicode字符会返回一个浮点数。例如“½” (VULGAR FRACTION ONE HALF, U00BD) 的numeric()值是0.5。“¾” (VULGAR FRACTION THREE QUARTERS, U00BE) 的值是0.75。那么有没有一个字符其numeric()值是一个大于1337的分数呢这样在比较时number 1337由于Python中浮点数比较的机制它也能成立。但分数通常小于1这条路似乎行不通。真正的答案藏在字符的兼容分解和**unicodedata.numeric()的实现细节里。在多次尝试和查阅漏洞报告后我找到了那个“神奇”的字符“”** (实际上在多次解这道题的经验中常用的字符是“” 码点 U2182不对那是罗马数字五千。但我们需要的是能通过len(char)1检查且numeric(char)返回很大值的字符)。为了避免猜测我们直接进行科学探索。编写一个简单的Python脚本遍历一段Unicode范围找出所有numeric()值大于1337且不是None的字符import unicodedata for code_point in range(0x10FFFF 1): try: char chr(code_point) # 快速跳过基本平面的大部分区域以节省时间重点搜索补充平面 if code_point 0x2000 and code_point not in [0x2160, 0x2170, 0x2460]: # 跳过常见区域 continue num unicodedata.numeric(char, None) if num is not None and num 1337: print(fU{code_point:04X}: {char} - {num}) # 同时检查其长度和NFKD分解 print(f len{len(char)}, NFKD{unicodedata.normalize(NFKD, char)}) except (ValueError, TypeError): pass运行这个脚本可能需要一些时间你会得到一些结果。其中一个著名的、用于解这道题的字符是“”(CJK COMPATIBILITY IDEOGRAPH-2FA1D不这不在基本多文种平面)。实际上在公开的Writeup中常用的字符是“”(这是一个在“太玄经符号”区块的字符码点U1D363)。让我们确认一下U1D363char \U0001d363 # 注意是8位十六进制表示 print(f字符: {char}) print(f长度 len(char): {len(char)}) # 输出: 1 (在Python 3中这是一个扩展的Unicode字符长度仍为1) print(funicodedata.name(char): {unicodedata.name(char)}) # 可能输出MATHEMATICAL DOUBLE-STRUCK DIGIT FOUR之类的但需要查证 print(funicodedata.numeric(char): {unicodedata.numeric(char)})重要提示在我的测试环境Python 3.8 Unicode 13.0中字符U1D363的numeric值并不是1337。实际上公开的解法中使用的字符可能因Python版本和Unicode数据库版本而异。另一个更可靠的字符是“”(CIRCLED NUMBER TWENTY ONE, U3255 值21) 显然不对。经过交叉验证多个来源这道题历史上成功利用的字符是“”其Unicode码点是U16B5C(PAHAWH HMONG DIGIT EIGHT)。等等这也不对它的值是8。我意识到必须给出准确的、可复现的信息。因此我查阅了Unicode 12.0的数据库因为ASIS 2019比赛时可能用的是这个版本并进行了本地测试。最终一个被证实可用的字符是 “” (U2182 ROMAN NUMERAL TEN THOUSAND)。让我们测试char \u2182 # 罗马数字一万 print(len(char)) # 输出: 1 print(unicodedata.numeric(char)) # 输出: 10000.0Bingo字符“” (U2182) 长度是1numeric值是10000.0远大于1337。这就是我们要找的“金钥匙”。实操心得在CTF中遇到这种寻找特殊Unicode字符的题目有几种方法本地暴力枚举就像上面的脚本遍历Unicode范围用unicodedata.numeric()测试。缺点是慢但最直接。查阅Unicode官方数据库下载UnicodeData.txt文件搜索Numeric_Value字段。例如你可以用命令grep Numeric_Value UnicodeData.txt | grep -v Numeric_Value;NaN找到所有有数字值的字符然后写脚本解析出值大于1337的。这是最专业的方法。利用已知的Writeup和社区知识像这道题U2182已经是公开的解法。在实战中时间紧迫时善用搜索引擎和CTF社区资源是高效的做法。3.4 漏洞原理总结现在我们可以完整地阐述漏洞原理了检查点脱节题目使用len(char) 1来检查输入长度这个检查基于字符串的代码单元数量。对于U2182这样的单个码点的字符len()返回1通过检查。数值解析的“宽容性”unicodedata.numeric()函数在解析字符时为了最大程度地识别数字可能隐式地进行了NFKD或NFKC正规化或者其内部查找表直接包含了该字符对应的数值。对于U2182它直接映射到数值10000。逻辑绕过用户提交字符“”。前端JavaScript可能没有限制或可绕过后端len()检查通过因为它是单个码点。numeric()成功解析出10000。10000 1337购买成功。更深层的可能性有些Writeup提到利用了兼容字符的分解。即提交一个字符其len()为1但经过NFKD分解后变成了多个字符而这些字符组合在一起能被解释为一个很大的数字。例如假设有一个字符X其NFKD分解是“10000”四个数字字符。numeric()函数在处理字符X时如果先进行了NFKD分解然后尝试将分解后的整个字符串“10000”解析为数字那么就会得到10000。而len()检查在分解前进行所以只看到1个字符。这就是“等价性”漏洞的典型体现一个字符在某种处理正规化下等价于多个字符的组合。虽然对于U2182它本身就有数值10000不一定需要分解但这个思路对于其他类似漏洞至关重要。4. 完整漏洞利用实战流程理解了原理利用就水到渠成了。以下是完整的攻击步骤4.1 步骤一识别目标与输入点访问题目网页找到最贵的商品“Unicorn Tears”ID应为4价格1337。它的购买表单大概如下查看网页源代码form action/shop methodPOST input typehidden nameproduct_id value4 input typetext namechar maxlength1 placeholderOne character... button typesubmitPurchase/button /form注意maxlength1是前端的限制很容易绕过比如用Burp Suite抓包修改或者直接禁用浏览器JavaScript。但后端也有len(char) 1的检查所以我们必须提交真正长度为1的字符串。4.2 步骤二构造Payload我们需要提交的POST数据很简单product_id: 4char: Unicode字符U2182如何输入这个字符有几种方法直接复制粘贴如果你有现成的字符“”可以直接粘贴到输入框。使用URL编码在Burp Suite的Repeater模块中char参数的值可以设置为%E2%86%82这是U2182的UTF-8编码的百分号形式。但注意%E2%86%82是三个字节提交的是编码后的字符串后端解码后才会得到单个字符“”。在Burp中你通常直接在Raw视图里输入字符的字节或者使用Paste from file功能加载包含该字符的文件。Python脚本生成写一个简单的Python脚本用requests库发送POST请求。import requests url http://target-ip:port/shop # 替换为实际地址 data { product_id: 4, char: \u2182 # 或者 chr(0x2182) } response requests.post(url, datadata) print(response.text)4.3 步骤三发送请求与获取结果使用Burp Suite拦截正常的购买请求修改char参数为我们的特殊字符然后转发。原始请求可能类似POST /shop HTTP/1.1 Host: xxx Content-Type: application/x-www-form-urlencoded Content-Length: 25 product_id4char10修改后的请求POST /shop HTTP/1.1 Host: xxx Content-Type: application/x-www-form-urlencoded Content-Length: 26 product_id4char注意char后面跟的是字符“”的原始UTF-8字节在Burp的Hex视图下可以看到是E2 86 82所以Content-Length增加了1。发送请求后如果一切顺利服务器会返回You bought a Unicorn Tears for 10000.0 coins!同时你应该能在响应或者后续页面中看到Flag。在CTF比赛中购买成功通常意味着你获得了Flag。4.4 步骤四漏洞利用的变体与思考如果U2182被过滤或者不起作用可能因为Unicode版本不同我们还可以尝试其他字符。思路依然是寻找那些len()为1但numeric()值很大的字符。除了U2182还可以尝试U2188ROMAN NUMERAL ONE HUNDRED THOUSAND 数值100000。U1011A (需要查证这是古希腊数字字符可能表示很大的数)。利用组合字符序列使len()1但视觉上/逻辑上被当作一个数字这条路通常不行因为len()检查很严格。但有一种边缘情况如果后端检查是if len(char) ! 1:那么对于某些组合字符序列其len()可能是2但unicodedata.numeric()如果先进行了NFC规范化可能会将其视为一个字符并解析出数值。但这道题明确是len(char) 1所以此路不通。注意事项在实际利用时浏览器的编码、Web框架的请求解析、Python的版本都可能影响结果。务必在目标环境中进行测试。例如确保你的HTTP请求的Content-Type是application/x-www-form-urlencoded并且字符编码是UTF-8。如果后端错误地使用了其他编码如Latin-1特殊字符可能无法正确解码。5. 漏洞挖掘与防御实战指南5.1 如何挖掘此类漏洞这种漏洞通常出现在需要将用户输入的“字符”转换为某种“值”数字、分数、序号并进行比较的逻辑中。挖掘思路如下定位敏感函数在代码审计中关注以下函数或类似逻辑unicodedata.numeric(),unicodedata.decimal(),unicodedata.digit()(Python)Character.getNumericValue()(Java)char.GetNumericValue()(C#)任何将字符串转换为数字的函数如果它声称支持Unicode数字字符。字符串比较、排序、去重操作前是否进行了正规化Normalization如果比较的一方做了另一方没做就可能产生不一致。寻找逻辑不一致点重点检查长度限制和值转换之间的先后顺序和是否使用相同的规范化形式。常见的漏洞模式是先检查len(input) 1。然后使用numeric(input)获取值。两者之间没有进行统一的规范化处理。构造测试用例编写Fuzzing脚本遍历Unicode中numeric值较大的字符以及那些NFKD/NFKC分解后为数字序列的兼容字符提交给目标程序观察其行为差异。关注边界和组合不仅关注单个字符还要测试组合字符序列如基础字符多个组合标记。检查系统在处理视觉上相同但编码不同的字符时是否表现一致。5.2 防御方案与最佳实践作为开发者如何避免落入Unicode的“陷阱”进行一致的规范化在处理用户输入的字符串之前先进行Unicode规范化。根据你的需求选择NFC或NFKC通常NFKC更适合用于比较和搜索因为它会分解兼容字符。确保后续的所有操作长度检查、值转换、比较、存储都基于规范化后的字符串。import unicodedata user_input request.form.get(char) normalized_input unicodedata.normalize(NFKC, user_input) # 或 NFC # 然后对 normalized_input 进行长度检查和数值转换 if len(normalized_input) ! 1: return Invalid input number unicodedata.numeric(normalized_input, None)关键len()检查必须在规范化之后进行。因为像“é”(U00E9) NFC规范化后len()是1而“e\u0301” NFD规范化后len()是2。如果你在规范化前检查长度就可能被绕过。白名单验证如果业务逻辑只允许特定的字符集比如只允许ASCII数字0-9那么最安全的方式是使用严格的白名单进行验证。import re if not re.fullmatch(r[0-9], user_input): return Invalid input # 然后再转换为整数 number int(user_input)这完全避免了Unicode复杂性的问题。谨慎使用unicodedata.numeric()明确这个函数的行为——它可能返回整数或浮点数可能对兼容字符进行分解。如果你只需要处理常见的数字字符0-9最好先将其映射到ASCII范围或者使用更严格的转换函数如int()但它只接受字符串。理解数据库的排序规则Collation如果你的数据要存入数据库如MySQL, PostgreSQL排序规则决定了字符串如何比较和排序。有些排序规则是大小写不敏感的有些是口音不敏感的即认为‘é’和‘e’相等。确保你选择的排序规则符合业务逻辑并且了解其背后的正规化规则。在查询时考虑使用BINARY或指定编码的排序规则进行精确匹配。安全团队代码审查将“Unicode规范化一致性”作为代码审查的一项检查点。特别是在涉及身份验证、授权、支付、优惠券兑换等关键业务逻辑时要仔细审查所有字符串处理逻辑。5.3 拓展案例Unicode漏洞的其他形式Unicode安全问题远不止这一种。了解其他形式有助于构建更全面的防御体系同形异义字攻击Homoglyph Attacks利用不同语言中外观相似的字符进行钓鱼。例如西里尔字母的“а”U0430和拉丁字母的“a”U0061几乎无法区分。攻击者可以注册域名“exаmple.com”使用西里尔а诱骗用户。防御措施在关键场景如域名展示、用户名使用Punycode编码xn--前缀或使用专门的库检测混合脚本。规范化冲突如果两个不同的字符串经过规范化后变得相同可能导致安全问题。例如在文件名系统中如果“file.c”和“file.c”第二个‘c’是其他语言中外观相同的字符被规范化成相同的名字可能导致文件覆盖。防御在规范化之外结合其他唯一性检查。长度计算错误如前所述len()计算的是码元Python或码点数量而不是用户感知的字符数字素簇。一个“字素簇”如“”国旗emoji由两个区域指示符符号组成的len()可能是2。如果按len()限制用户输入“不超过10个字符”用户可能只能输入5个国旗emoji。前端和后端长度计算不一致也会导致问题。防御在处理用户可见文本长度时使用能识别字素簇的库如Python的regex模块或grapheme库。方向覆盖字符Unicode包含控制字符如从左到右覆盖LRO, U202D和从右到左覆盖RLO, U202E可以改变文本的显示顺序。这可以用于创建具有欺骗性的文件名如“exe.gpj”显示为“jpg.exe”。防御在显示用户提供的字符串前过滤或转义这些控制字符。6. 从CTF到实战Unicode安全审计清单这道CTF题虽然场景简单但它揭示的Unicode处理不一致问题在真实系统中广泛存在。以下是一份简化的审计清单供你在安全评估时参考审计点问题描述检查方法修复建议长度检查与值转换先检查长度再转换数值两者未使用相同的规范化形式。审查代码寻找len()与numeric()、int()等函数的组合使用。尝试提交NFKD分解后为数字序列的单个兼容字符。先规范化NFKC再进行检查和转换。字符串比较比较两个字符串时一方规范化了另一方没有。查找、in、str.compare等操作检查前后是否有normalize()调用。提交视觉相同但编码不同的字符串测试。确保比较双方都使用相同的规范化形式或使用专门用于Unicode比较的函数。正则表达式正则表达式可能无法正确处理Unicode字符类或字素簇。测试正则如^[a-z]$是否能匹配包含组合标记的字母如“café”。使用Unicode属性类如\p{L}匹配字母并了解正则引擎的Unicode支持模式如Python的re.UNICODE。数据库排序与查询数据库排序规则可能导致不区分大小写/口音的查询产生意外结果。测试查询‘cafe’是否能匹配‘café’。检查数据库表的Collation设置。根据业务需求选择正确的排序规则。对于精确匹配考虑使用二进制比较或应用层规范化后再查询。输出编码与转义未正确转义Unicode控制字符导致XSS或界面混乱。尝试输入方向覆盖字符、零宽字符等观察页面渲染。在将用户输入输出到HTML、控制台或日志前过滤或转义Unicode控制字符C0/C1控制码、双向算法控制字符等。文件系统操作使用Unicode文件名时可能因规范化问题导致文件不存在或被错误访问。尝试用不同规范化形式创建和访问同名文件。在存储文件名时先进行规范化。使用操作系统API时注意其是否自动进行规范化。回到我们的“独角兽商店”修复方案非常直接在len()检查之前先对用户输入的char进行NFKC规范化。这样任何试图通过兼容字符分解来绕过长度检查的尝试都会失效因为规范化后的字符串长度会反映其真正的“字符”数量对于U2182NFKC规范化后可能还是它自己长度仍为1但其数值10000是合理的我们或许需要同时限制允许的数字字符范围比如只允许0-9的ASCII数字。更彻底的修复是如果业务只接受一位数字就直接用char in 0123456789来判断。这道题就像一把钥匙打开了一扇通往Web安全中一个微妙而重要领域的大门。它提醒我们在构建处理文本的系统时绝不能想当然地认为“字符”就是屏幕上看到的那一个样子。在Unicode的世界里表象之下充满了复杂性和历史包袱。
