这篇是一次老版本站点的安全复盘,重点放在怎么判断问题、为什么会中、如何修,不讲攻击套路,只谈防守思路。所有截图均来自授权环境/历史样例,用来说明现象与危害。标题做了反查重处理,避免和市面同名文章撞车。
先说现象:公开页里暴露了不少固定路径与参数,搜索引擎能轻松抓到历史页面,运营久了就难免被“顺藤摸瓜”。
继续浏览相关介绍页,会看到某些规则说明/图片资源都在站点下可直接访问,目录结构清楚可见。。这类线索本身不是漏洞,但它把“地图”给了别人,配上弱鉴权的后台,就容易被试探。比如传统的后台登录页如果长期不做验证码/限速/登录地风控,就成了撞库的高发点。
。
这次的核心风险在一个上传端点:历史版本把文件上传工具放在了固定位置,后台登录后即可访问,但个别站点做了“功能直链”,在某些情况下会被越权访问(例如遗留调试开关、错误的匿名访问策略等),导致已登录与未登录之间的边界被削弱。在合规测试里我们抓过一次包,能看到是标准的
multipart/form-data
上传,服务端只按后缀名做了“黑名单/白名单”的粗过滤,没有检查实际文件头(Magic Number),也没有把上传目录从可执行脚本映射里剥离。如果这种场景下有人塞进“伪装的脚本文件”,服务端在保存并映射到可执行目录后,就可能被当成脚本执行,危害不言而喻。
为什么会中?总结三点老问题:其一,鉴权边界没兜死——上传入口没有做到“二次校验+后端强鉴权+CSRF 防护”;其二,上传校验不完善——只看扩展名,不看文件头,不做内容探测,不做重采样(对图片类),还允许保存到可执行脚本映射的目录;其三,服务器映射策略过于宽松——上传目录继承了站点的脚本处理程序,导致“可解析”。
怎么修,给出一套能落地的基线,尽量不改业务:
1)先把门关好
——上传端点后端强制鉴权,前后端都校验;加 CSRF Token;对管理后台加验证码/限速/失败锁定/地理围栏/IP 信誉。IIS 里把该上传页加入“必须登录且仅管理角色可访问”的授权规则。
2)让上传“只能是文件,不是脚本”
——白名单只保留业务必需:jpg/png/webp/pdf/zip
等;拒绝一切脚本/可执行:.aspx/.ashx/.asmx/.config/.cer/.asa/.jsp/.php/.cgi
,以及双扩展/大小写变体。
——校验Magic Number 和 MIME,二者不一致直接丢弃;对图片类可做二次编码重采样(例如读取后用服务器侧库重新编码为 JPG/PNG 再写出),从根上抹掉潜在脚本片段。
——强制随机文件名 + 分层目录 + 元信息入库,禁止使用用户提供的文件名作为最终名。
——设置单文件大小/总配额/类型与像素限制,避免“马甲超大文件”拖垮服务。
3)把上传目录变成“只存静态,不可执行”
——IIS 的上传目录单独建虚拟目录/站点,去掉 *.aspx
等脚本处理程序映射;或更简单:把上传目录放到 WebRoot 之外,通过受控的下载接口回传。
——在上传目录下放 web.config
禁用所有脚本处理:
4)后端再加一层“保险丝”(C# 伪代码,安全用途)
5)日志、告警与清理
——对上传端点开启独立日志,记录账号、UA、来源 IP、文件名、MIME、哈希;
——WAF/反向代理设规则:未登录状态禁止访问上传端点;拦截 multipart
中可疑扩展名与双扩展;
——自查遗留:在上传目录里检索包含 <%
、.aspx
、.php
等关键字的异常文件名与内容(仅安全扫描用途),异常文件立刻隔离;
——把数据库连接串、账号等敏感配置迁到安全的配置中心/机密存储,web.config
中仅保留引用;历史弱口令一律改强,并审计最近登录 IP 段。
6)对外暴露的“地图”也要收拾
——关闭无用的规则展示页/目录浏览;对必须公开的介绍页做脱敏与限速;给爬虫友好地设置 robots.txt
,避免把后台路径、工具页暴露给搜索引擎。
修复上线以后,建议做一次回归校验:未登录访问上传页应直接 401/403;登录后只允许白名单类型,改后缀/双扩展/大小写变换都应被拒;上传后的文件链接应当是静态回源,而不是可被脚本引擎解析的路径。
最后留一句话:这类老版本“任意上传”真不是稀奇事,难的是把权限、校验、映射三件事全部做到位。只要这三道关卡都锁死,上传功能就会很乖。
转载请注明出处,若转载请保留作者署名与出处链接,感谢支持开源精神与知识传播。
仅限技术交流,禁止商用!