Windows站点搭建常被忽视的3大权限安全断点

　　Windows站点搭建常被忽视的3大权限安全断点——这个标题不是我拍脑袋想的，是我去年一月份在客户现场实打实扒出来的。当时那台Windows Server 2019标准版（补丁号KB5028973刚装完）跑着IIS 10.0，站点首页能打开，但上传文件总报“拒绝访问”，连ApplicationPoolIdentity对C:\\inetpub\\wwwroot\\upload目录的写权限都给了，还是失败。查了三小时Event Viewer日志，最终发现是NTFS继承被手工清空后，子目录没重置——而这种操作，在自动化脚本批量部署时根本没人复核。

　　第一断点：IIS应用池身份对临时ASP.NET编译目录无写权限。具体位置是C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\Temporary ASP.NET Files\\{站点Hash}\\，去年一月份我在三个客户环境里复现过——其中两个用的是自定义AppPoolIdentity（非默认ApplicationPoolIdentity），第三个干脆用了LocalSystem，但都没人意识到：哪怕你给wwwroot加了Full Control，.NET Framework仍会按进程令牌的实际SID去校验该临时目录的ACL。某教育局官网就因此导致.aspx页面首次加载超时47秒，监控显示HTTP 500错误突增182%，排查才发现该目录的Owner竟是SYSTEM，而AppPoolIdentity账户只挂了个“读取”权限条目，连“遍历文件夹/执行文件”都被显式拒绝。这真不是小概率事件——我抓包看到w3wp.exe调用CreateDirectoryExW失败后直接fallback到内存编译，性能跌了60%以上。技术上其实挺新：.NET 4.8之后引入了更细粒度的AssemblyLoadContext级隔离，可绝大多数运维还在用Web.config里硬扛，压根没动NTFS权限策略。

　　第二断点更隐蔽：
LogonUserW API调用失败引发的匿名用户权限溢出。说白了就是IIS把“匿名身份验证”和“Windows身份验证”混搭时搞错了令牌提权路径。去年一月份某金融客户做等保加固，关闭了IUSR账户的密码缓存（注册表HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\HTTP\\Parameters\\EnableNegotiateOnUntrustedProxy=0），结果所有启用Windows认证的API接口，返回的HttpContext.User.Identity.Name却变成了IUSR-xxx而非域账号——因为LogonUserW在没有本地密码缓存支持下，自动降级为创建一个无特权交互式令牌，再被IIS错误映射到匿名上下文。我们抓了Wireshark发现SMB会话里Auth Type居然是0x03（NTLMv2 Session Response），但Server端NTLM解密后丢弃了Session Key，只留了个空SecurityContext。这种细节连微软文档都藏在KB4532947的附件里，没人翻。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!