Microsoft IIS 安全扩展名输入验证漏洞

2008年夏天，安全一个针对IIS6的扩展畸形URL请求让无数站长后背发凉。你在地址栏里输入 http://victim.com/secret.asp;.jpg，名输服务器居然直接吐出了ASP脚本源码——不是入验执行，是证漏纯文本展示。数据库密码、安全后台路径、扩展连接字符串，名输全裸奔了。入验

问题出在IIS对文件扩展名的证漏解析逻辑上。它用分号当分隔符，安全把 secret.asp;.jpg 拆成两部分：主文件名 secret.asp 和“伪扩展名” .jpg。扩展按设计，名输IIS应该只认最后一个点后面的入验后缀，但这里它犯了傻——它把分号前的证漏 .asp 当作有效脚本映射，同时又把分号后的 .jpg 当作静态文件类型，结果两头都占了。更讽刺的是，这个漏洞在IIS 5.0里就存在，微软在2003年发布过补丁，但IIS 6.0居然把同样的错误原封不动地继承了下来。

攻击者不需要什么高级工具，一个浏览器就够。构造 upload.asp;.jpg 的URL，如果服务器没有正确过滤上传文件的扩展名，你就能把恶意ASP代码伪装成图片上传到服务器，然后直接访问这个“图片”，代码就被执行了。当时国内不少虚拟主机商中招，因为IIS 6.0是那个年代Windows Server 2003的标配。

漏洞的根子在于输入验证逻辑混乱。IIS解析URL时，先按分号切分，再对每段做扩展名映射，却没有检查分号后面是否跟了可执行脚本类型。正规的HTTP规范里，分号是参数分隔符，比如 default.asp;sessionid=abc，但IIS把参数和文件路径混在一起处理，没有严格区分“资源路径”和“额外参数”。

修复方案其实特别直白：要么禁用分号作为路径分隔符，要么严格只认最后一个点作为扩展名边界。微软官方补丁的做法是强制要求“分号后不能跟可执行脚本扩展名”，但如果你没打补丁，就得手动在ISAPI筛选器里拦掉包含分号的请求——麻烦，但有效。

这事给我一个很深的教训：安全漏洞往往不是出在复杂算法上，而是出在“边界条件没想清楚”。IIS团队大概觉得没人会往URL里塞分号加脚本后缀，可黑客偏偏就是那个最较真的用户。如今IIS 10已经彻底改了URL解析引擎，但老漏洞的阴影还在——2017年依然有扫描器在互联网上找没打补丁的IIS 6.0服务器，一抓一个准。

你要是还在维护老系统，别犹豫，直接禁用分号解析，或者把上传目录的脚本执行权限关掉。安全这事，侥幸心理害死人。