iis解析漏洞

2008年那会儿，析漏国内不少站长用着Windows Server 2003搭配IIS6.0，析漏一个叫“asp木马”的析漏东西让很多人夜不能寐。真正让安全圈炸开锅的析漏，是析漏那个经典的畸形URL——xx.asp/xx.jpg。你明明上传了一张图片，析漏可当你在浏览器里访问它时，析漏服务器居然把它当ASP脚本给执行了。析漏这不是析漏魔法，是析漏IIS的解析顺序出了岔子。

IIS6.0处理请求时有个固执的析漏毛病：它先看分号前面的内容。你给它一个test.asp;.jpg，析漏它只认test.asp，析漏分号后面全当空气。析漏还有那个“目录名+脚本后缀”的析漏玩法，/upload/image.asp/logo.jpg——只要目录名带.asp，里面任何文件都被当脚本跑。问题根源在于，IIS把URL的后缀和路径段的优先级搞反了，而管理员们普遍没关掉“父路径”和脚本映射。

到了IIS7.0/7.5时代，漏洞换了副面孔。这次是FastCGI的配置坑。默认安装下，如果管理员在“处理程序映射”里设置了*.asp，但没正确配置scriptProcessor的路径，攻击者就能用1.jpg/a.asp这类URL触发解析。更常见的是，当服务器存在.asp目录时，整个目录下的文件都会被当作ASP执行——哪怕你传的是个纯文本。这跟IIS6的原理不同，纯粹是配置层面的疏漏。

我见过最离谱的一次渗透测试，对方是个政府网站，上传点设在/upload/下，管理员大概是为了方便，直接建了个upload.asp目录。结果我传了个正常PNG，里面塞了句<%execute request("cmd")%>，访问/upload.asp/logo.png，服务器直接给我吐了个cmd shell。整个过程不到五分钟，没绕过任何WAF，因为请求本身看起来完全合法。

修复方案其实不复杂。IIS6就关掉脚本映射里的“缓存扩展名”，或者干脆不要用分号做URL参数分隔。IIS7以上，检查FastCGI设置，确保*.asp只映射到C:\Windows\System32\inetsrv\asp.dll，同时避免创建带脚本后缀的物理目录。可现实是，很多老系统至今还裸奔着，因为运维怕改坏了业务。

这漏洞的可怕之处不在技术难度，而在它的隐蔽性。你上传个图片没人会警觉，可它偏偏能变成执行代码的入口。安全圈常说“解析漏洞是黑盒里的暗门”，这话一点不假。直到今天，我偶尔还能在新上线的小站点上复现IIS6的经典玩法——那感觉就像在2025年翻出一台还能用的诺基亚3310，按键咔嗒作响，却依然能砸核桃。

很赞哦!（5573）