解析漏洞

凌晨三点，解析漏洞黑客把一段十六进制字符串塞进URL，解析漏洞服务器端程序员正梦见女朋友。解析漏洞没人理会那个看起来像乱码的解析漏洞尾巴。四小时后，解析漏洞网站后台被拖库，解析漏洞密码哈希散了一地。解析漏洞这不是解析漏洞电影桥段，是解析漏洞某电商平台真实遭遇的解析漏洞攻击。

解析漏洞的解析漏洞本质，说白了就是解析漏洞服务器对文件身份的认知偏差。你递过去一张写着“jpg”的解析漏洞名片，系统就放它进了图片仓库。解析漏洞可那张名片背面，解析漏洞藏着用PHP写的解析漏洞木马。服务器只认后缀，不验内容——像极了只查工牌不看人的前台保安。

拿IIS 6.0时代经典的“分号截断”来说。攻击者上传一个名为“shell.asp;.jpg”的文件，老旧的IIS遇到分号就自动忽略后面内容，直接把文件当作ASP脚本执行。就这么个低级失误，让多少网站沦为肉鸡。后来Nginx又爆出“CVE-2013-4547”，利用空格与十六进制编码的差异，让服务器把“shell.jpg ”（末尾带空格）解析成PHP。你看，漏洞永远追着补丁跑，道高一尺魔高一丈的把戏演了十几年。

更阴险的是图片马。攻击者把PHP代码嵌进一张风景照的EXIF信息里，再配合文件包含漏洞触发。服务器加载图片时，顺带把代码执行了。整个过程悄无声息，日志里只有一次普通的图片访问记录。你查漏洞扫描报告，干干净净——因为问题出在业务逻辑的夹缝里，常规工具根本扫不到。

我见过最讽刺的案例，某安全公司自家官网栽在解析漏洞上。他们用Java写的上传组件，开发图省事直接拼接文件名，没做二次校验。攻击者上传“shell.jsp%00.png”，Java的URI解析器看到%00就截断字符串，最终落盘成“shell.jsp”。安全公司被自己人打脸，这事传出去够写进培训教材。

修补方案其实不复杂：禁用危险后缀、重命名上传文件、用白名单校验MIME类型、把存储目录设为不可执行脚本。可现实里总有开发图省事，运维嫌麻烦，管理层觉得“能跑就行”。于是漏洞像野草，割了一茬又长一茬。

前阵子测试某个政府网站，上传点只过滤了黑名单后缀。我传了个“test.phtml”，服务器直接返回200 OK。那一刻我突然明白，解析漏洞根本不是技术难题，是人性漏洞——懒、侥幸、傲慢，全都写在代码里。

你问怎么防？先扔掉那些花哨的WAF规则。去你的上传目录翻一翻，看看有没有不该存在的文件。没有？那试试直接访问“/upload/xxx.jpg/.php”，再试试“/upload/xxx.jpg%00.php”。如果页面报错，恭喜，你中奖了。真正的安全，从来不是买几台设备就完事，而是每个写上传接口的程序员，在提交代码前多问自己一句：这文件，真的只是图片吗？