iis6.0解析漏洞：一个老漏洞的析漏“新”启示

2008年，某省教育厅官网被挂上了暗链。析漏管理员查了三天日志，析漏最后发现罪魁祸首是析漏IIS6.0的一个“特性”——它把`shell.asp;.jpg`当成了ASP脚本执行。这事当年在安全圈传得沸沸扬扬，析漏不是析漏因为攻击多高明，而是析漏因为修复起来太尴尬：你没法“修复”，只能改代码或换服务器。析漏

IIS6.0的析漏解析漏洞其实分两种，但核心逻辑都源于它对分号和文件名的析漏“过度宽容”。第一种是析漏分号截断：当URL里出现`x.asp;.jpg`时，IIS会把分号后面的析漏内容全部忽略，直接按`.asp`解析。析漏第二种是析漏目录解析：如果服务器上存在`test.asp`这样的目录，那么`test.asp/任意文件名.jpg`也会被当作ASP执行。析漏这两种情况都利用了IIS6.0在“文件扩展名识别”上的缺陷——它不检查文件真实内容，只认路径里的第一个“有效扩展名”。

为什么说这是个“特性”而非“bug”？因为微软的设计初衷是支持“脚本映射到静态文件”的灵活性。比如你有个`news.asp`目录，里面放些图片，IIS希望你能通过`news.asp/logo.jpg`这种路径来访问，同时让`news.asp`目录下的ASP代码能处理请求。结果这个“善意”被攻击者玩坏了——他们上传一个`avatar.asp;.jpg`，图片内容里塞满ASP代码，服务器就乖乖执行了。

实际利用场景比理论更讽刺。很多站长当时喜欢用“图片马”绕过上传限制：先传一个合法图片，再通过IIS漏洞让图片里的代码执行。最经典的案例是某论坛的“头像上传”功能，攻击者把一句话木马写进GIF文件末尾，文件名改成`head.asp;.gif`。上传成功后，访问`http://target/upload/head.asp;.gif`，服务器直接返回ASP执行结果——连`%00`截断都省了。

修复方案简单粗暴：要么升级到IIS7.0+，要么在“Web服务扩展”里禁用ASP脚本映射，要么在“ISAPI筛选器”里加规则拦截分号。但真正坑人的是，很多老系统依赖这种“伪目录”结构，比如某些CMS的附件管理模块，一改配置整个后台就瘫了。所以当年安全圈流行一句话：“IIS6.0解析漏洞不是技术问题，是政治问题——你动它，业务部门跟你急。”

十几年过去，IIS6.0早已被淘汰，但这类漏洞的思维模式还在。你看现在的云WAF，还在专门拦截`;.jpg`这种URL；Nginx的`cgi.fix_pathinfo`漏洞，本质上也是“路径解析歧义”。说白了，服务器对“文件名”的信任程度，决定了攻击面的宽度。IIS6.0教会我们的不是某个具体补丁，而是：任何“宽容”的解析逻辑，都是潜在的后门。

现在偶尔还能在内网扫到IIS6.0的旧机器——多半是没人维护的遗留系统。每次看到`iisstart.htm`那个默认页面，我都觉得它像块墓碑，刻着“这里曾经很信任用户输入”。