资产网络系统出现上传漏洞整改报告

上周三凌晨两点十七分，资产整改资产网络系统的网络文件上传接口被触发了异常调用。值班同事在监控面板上看到一串连续请求，系统来源IP指向一个境外云服务商，出现上传的上传文件后缀全是“.jsp”。三分钟内，漏洞系统自动拦截了17次，报告但第18次绕过了校验——一个伪装成图片的资产整改WebShell被写进了临时目录。

问题出在文件类型校验的网络逻辑上。开发团队原本只检查了Content-Type头部和文件扩展名，系统但攻击者把Content-Type改成“image/png”，出现扩展名用“jpg”，上传实际内容却是漏洞JSP代码。更麻烦的报告是，临时目录的资产整改权限配置允许执行脚本。这等于给入侵者留了一扇后门。

我翻了一下近半年的日志，发现类似尝试从年初就开始出现，只是频率极低。三月有一次、五月两次，都被WAF规则挡住了。这次攻击者换了手法，用分块传输编码把恶意载荷拆成多个小包，绕过了基于正则的检测。WAF规则库没及时更新，加上运维人员对临时目录的清理周期设成了7天，给了攻击者足够的时间窗口。

整改从第二天早上八点开始。先把上传接口的校验逻辑重写：不再依赖客户端传来的Content-Type，而是用Apache Tika读取文件魔数，判断真实类型。白名单只允许jpg、png、gif、pdf四种。文件名强制重命名为UUID加时间戳，去掉原始扩展名。上传后的文件全部存到对象存储的私有桶，通过签名URL访问，执行权限彻底剥离。

临时目录的权限也改了。原来挂载时带了exec参数，现在换成noexec、nosuid、nodev。清理周期从7天压缩到2小时，用cron每两小时扫一次。WAF那边加了自定义规则，针对分块传输编码的请求做长度和分片数限制，超过阈值直接丢弃。

还有一处细节容易被忽略：错误日志里暴露了临时目录的绝对路径。攻击者可能通过报错信息推断出文件写入位置。我把所有上传相关的异常返回统一改成“上传失败，请重试”，不再输出具体路径或堆栈。

整改完成后做了三次回归测试。第一次用常规图片上传，正常。第二次用改扩展名的JSP文件，被魔数检测拦下。第三次模拟分块传输的慢速攻击，WAF在第三包时触发规则，连接被重置。测试通过，但我不太放心，又加了一条监控：每分钟统计上传接口的失败率，超过5%就发告警到值班群。

这件事暴露的问题不只是一个上传漏洞。开发、运维、安全三方对临时目录的认知有偏差——开发觉得那是“临时”的，运维觉得是“系统”的，安全团队压根没把它列入资产清单。后来我们拉了一个共享表格，把所有涉及文件写入的路径列出来，标清楚用途、权限、清理策略和负责人。表格放在内网Wiki上，每周五更新一次。

攻击者没拿到什么有价值的东西。那个WebShell被写入后不到四分钟，主机上的EDR就检测到了异常进程创建，自动隔离了文件。但这次事件提醒我们：资产网络系统的边界比想象中模糊。一个上传接口、一个临时目录、一条WAF规则，任何一处松动都可能变成入口。整改不是写报告，是把每个假设都重新验证一遍。