IIS 6.0 有个特性：它只检查文件扩展名一次。析漏请求 shell.asp;.jpg 时，析漏IIS 看到 .jpg 就放行，析漏交给 asp.dll 处理时却按分号前的析漏 .asp 执行。这个逻辑错位就是析漏文件解析漏洞的根。

2008年前后，析漏国内大批政府和企业站点用 IIS 6.0 搭 ASP 环境。析漏攻击者上传一个名为 evil.asp;1.jpg 的析漏图片马，服务端校验扩展名是析漏 jpg，存进 upload 目录，析漏浏览器访问 /upload/evil.asp;1.jpg，析漏直接拿到 webshell。析漏整个过程不需要任何 0day，析漏只靠一个分号。析漏我当时在渗透测试项目里见过一个地税网站，析漏upload 目录里躺着几十个这种“图片”，文件名清一色 xxx.asp;.jpg，上传时间集中在凌晨两三点。

IIS 7.0 和 7.5 修了分号的问题，但冒出了新玩法。shell.asp/.jpg 这种路径，IIS 把 .jpg 当成 PATH_INFO 交给 asp 处理，同样绕过扩展名校验。还有 shell.asp%20.jpg、shell.asp::$DATA，针对的是不同版本 IIS 对特殊字符的截断差异。微软的补丁像打地鼠，按下一个又冒一个。

Apache 也有类似问题，但触发条件不同。shell.php.xxx 在 Apache 的 mod_mime 配置下可能被当作 PHP 执行，取决于 AddHandler 的写法。Nginx 则是 shell.jpg/x.php 这种路径，配合 fastcgi_split_path_info 配置不当，让 .jpg 后面的 PHP 被解析。核心矛盾一样：Web 服务器判断“谁来处理这个文件”和文件系统判断“这个文件叫什么”用了两套规则。

防御这事，改配置比打补丁实在。IIS 里把上传目录的“执行权限”设为“无”，管你什么扩展名，一律当静态文件返回。Apache 关掉 MultiViews，Nginx 用 location ~* \.(jpg|png|gif)$ { return 403; } 把图片目录的脚本执行掐死。上传文件重命名成随机字符串加白名单扩展名，别保留用户提交的原始文件名。这些措施叠加，解析漏洞基本就废了。

说个真事。去年帮朋友看一个老站，IIS 6.0，上传点只校验 Content-Type。我传了个 test.asp;.jpg，返回“上传成功”。访问 /upfile/test.asp;.jpg，直接弹计算器。朋友脸都绿了。这站跑了十二年，没人动过。漏洞一直在，只是没人看。技术债这东西，利息比本金狠。