宽字节跨站漏洞

一个GBK编码的宽字网站，把用户输入的节跨“%df”和反斜杠拼在一起，反斜杠就消失了。站漏这不是宽字魔术，是节跨宽字节跨站漏洞最朴素的演示。

2006年，站漏安全研究者发现某些中文、宽字日文、节跨韩文编码环境下，站漏一个多字节字符的宽字第二个字节如果落在ASCII范围内，程序在转义时只处理了第一个字节，节跨第二个字节就被“吃掉”了。站漏具体点说，宽字GBK编码里“%df%5c”会被解析成一个汉字，节跨而“%5c”原本是站漏反斜杠，是转义字符。反斜杠被吞了，后面的单引号就逃逸出来了。

我最早接触这个漏洞是在一个老旧的PHP CMS上。开发者在全局开启了addslashes()，所有单引号、双引号、反斜杠前面都加上了反斜杠。看起来无懈可击。但数据库连接层设置了SET NAMES 'GBK'，而PHP本身没有开启magic_quotes_gpc之外的任何过滤。攻击者提交%df'，addslashes()会把单引号转成\'，也就是%df%5c%27。GBK解码时，%df%5c被合并成一个合法汉字，剩下的%27就是那个没被转义的单引号。SQL注入就这么发生了。

XSS场景更直接。一个搜索框把用户输入回显到页面，页面头声明charset=GBK。你输入%df%22%3E%3Cscript%3Ealert(1)%3C/script%3E，后端如果只对双引号做了HTML实体编码，%df%5c又吃掉了转义符，双引号闭合了属性，后面的脚本标签就执行了。

这个漏洞的根因不在编码本身，而在“字节流处理”和“字符流处理”的错位。程序员以为自己在处理字符，实际上中间件、数据库驱动、转义函数各干各的。你转义的是ASCII反斜杠，GBK解码器看到的却是多字节序列的一部分。两边对不齐，缝隙就出来了。

修复方案说起来简单：统一字符集。要么全用UTF-8，要么数据库连接层设置character_set_client=binary。但现实里，老系统迁移成本高，有些政府项目还在用GB2312。我见过一个内部OA，2018年还在用GBK，因为历史数据里存了一堆生僻字，转UTF-8会丢字。他们只能靠mysql_real_escape_string()加上set names gbk，但PHP版本太老，驱动层还是有问题。

另一个坑是iconv函数。有人想用iconv('GBK', 'UTF-8', $input)来清洗数据，结果输入%df%5c时，iconv报错，返回false，程序没处理false，直接放行原始数据。漏洞照旧。

宽字节漏洞不是SQL注入的专属。文件包含、命令执行、甚至JSON解析都可能中招。关键看数据流里有没有“多字节编码+转义函数+字节级操作”这三样东西同时出现。有，就有风险。

现在新项目基本都用UTF-8了，宽字节漏洞似乎成了历史。但你去翻翻老代码，尤其是那些从Discuz、PHPCMS二次开发来的系统，GBK连接串还躺在配置文件里。攻击者也没闲着，%df不行就换%bf，GBK不行就试GB18030。编码表那么长，总有一个字节序列能绕过你的转义逻辑。

说到底，安全不是靠一个函数、一个配置就能解决的。你得知道数据从浏览器到数据库，中间经过了几次解码、几次编码、几次转义。哪一步对不上，哪一步就是入口。宽字节漏洞教给我们的，就是这个道理。