iis7漏洞

2008年那会儿，IIS6.0的漏洞让多少站长半夜爬起来打补丁。可到了IIS7，事情变得更微妙了——它不再是简单的“缓冲区溢出”或“远程代码执行”，而是把矛头指向了配置层面。你猜怎么着？最典型的攻击入口，居然是那个默认开启的“FastCGI”模块。

具体来说，IIS7搭配PHP时，如果管理员偷懒没改默认的applicationHost.config，攻击者就能通过构造特殊的URL，把PHP_FCGI_MAX_REQUESTS环境变量给篡改了。这招叫“FastCGI环境变量注入”，原理不复杂，但杀伤力极大——直接绕过认证，读取服务器上任意文件。我亲眼见过一个电商站，后台管理员的密码哈希就这么被拖走了，对方只用了三行curl命令。

另一个坑藏在URL重写模块里。IIS7的web.config支持通配符映射，可很多人不知道，*号能匹配到路径分隔符。假设你写了个规则：<add input="{ REQUEST_URI}" pattern="^/admin/(.*)" />，看似只放行admin目录，但攻击者传个/admin/../config/connectionStrings.config，重写引擎照样给放行了。这种畸形路径在Apache上早被过滤了，IIS7却傻乎乎地信任了。

说到个人观察，我发现大部分漏洞报告都盯着代码缺陷，可现实中八成攻击靠的是“配置漂移”。比如某个团队为了调试方便，在服务器上临时开了directoryBrowse，忘了关。IIS7的目录浏览不像老版本会显示403，它直接给你渲染一堆.xml、.env文件列表。有个客户就因为这，把数据库备份文件暴露了三个月，直到被爬虫索引到百度快照里。

还有个细节值得留意：IIS7的system.webServer/security/requestFiltering默认允许双编码URL。攻击者把%252e%252e塞进路径，服务器解码一次，应用层再解一次，就能绕过..过滤。这种“双重解码”在2010年的.NET站点上特别流行，因为微软的补丁总是慢半拍。

说句实在话，IIS7的漏洞本质上是“功能富余”的代价。它集成了太多便捷模块，却把安全决策丢给了用户。不像nginx那样默认拒绝一切未知请求，IIS7总爱自作主张地帮你解析.php、.aspx甚至.ashx。你删了处理程序映射？没关系，还有handler缓存能利用。

最后讲个真实案例。2012年有个金融公司，IT主管为了省事，把IIS7的applicationHost.config里所有overrideModeDefault设为Allow。结果业务部门上传了个web.config到子目录，里面写着<system.webServer><rewrite>...</rewrite></system.webServer>，直接覆盖了全局规则。攻击者利用这个后门，把支付页面重定向到了钓鱼服务器。事后检查日志，发现IIS7根本没记录这次配置变更——它默认信任应用层的配置文件。

所以你看，IIS7的漏洞不是某个函数写错了，而是整个信任模型出了问题。它太相信“配置即代码”，却忘了配置本身会成为攻击面。如果你还在维护老系统，赶紧检查一下requestFiltering里的allowDoubleEscaping，设为false能挡掉一半麻烦。剩下的，就得靠你手动把那些用不到的模块全卸了——毕竟，功能越少，洞越少。