下午三点十七分，内部运维老张在工位上骂了一句脏话。文件他刚发现，上传溯源公司内部文件系统里多了一个名为“2024年度薪资调整明细.xlsx”的系统文件，上传时间是漏洞两分钟前——而那天根本没有HR提交过任何文件。

我第一反应是分析看上传日志。日志显示来源IP是内部10.24.8.17，一个属于财务部的文件静态地址。但财务部的上传溯源人说他们整个下午都在开会，没人动过电脑。系统这就怪了，漏洞IP没变，分析文件却凭空出现。内部

顺着这个线索往下查，文件系统里所有上传操作都有记录文件路径、上传溯源文件名、大小和上传者账号。但这次操作记录里，账号字段是空的。系统代码里明明写了“未登录用户禁止上传”的逻辑，可这个文件还是进来了。

问题出在文件上传接口的参数校验上。开发当时为了图省事，把前端传来的“user_id”直接拼进SQL查询里，没做类型限制。攻击者只要把user_id改成“0 OR 1=1”，就能让查询永远成立，绕过登录状态检查。更蠢的是，后端只验证了文件扩展名是.xlsx，根本没检查文件头是不是真的Excel格式——攻击者完全可以传一个伪装成.xlsx的PHP脚本。

但攻击者没这么干。他只是传了个正常的Excel文件，里面放了个公式。那公式指向一个外部服务器，只要有人打开这个文件，Excel就会自动去请求那个服务器，把本机IP和用户名带过去。好家伙，这不是偷数据，这是钓鱼。

我试着用那个公式反查外联域名，发现服务器早关了，估计是临时搭的。攻击者目的很明确，想钓出几个打开文件的“高权限用户”，再针对性地搞下一波攻击。他选择上传到“共享文档”目录，因为这个目录经常被各部门翻看，曝光率高。

漏洞修复不难，参数校验加上白名单，文件头检查也补上了。但真正让我后背发凉的是另一件事——这个上传接口是三个月前外包团队写的，当时代码评审还通过了。没人注意到那个“user_id”拼接，因为测试环境里所有账号都是真实存在的，没人试过传一个假ID进去。

后来我问老张，那个文件他打开过没有。他沉默了两秒，说“我双击了一下，然后觉得不对就关了。”我让他赶紧断网查杀，他摆摆手说“怕什么，我就是个运维，电脑里又没秘密。”

你看，系统漏洞往往只是入口，真正致命的是人觉得“自己不重要”。那个攻击者要是真盯上老张，用同样的手法传个带宏的文档，老张这台机器就能当跳板，去摸整个内网的拓扑。别小看任何一次“没登录也能传文件”的报错，那可能不是bug，是有人故意留的门。

(责任编辑：百科)