文件泄露漏洞

2023年秋天，文件某家做在线教育的泄露公司出了事。一个离职员工在GitHub上建了个私有仓库，漏洞把公司后台的文件数据库配置文件传了上去——里面躺着AWS的访问密钥。他没多想，泄露觉得私有仓库只有自己看得到。漏洞但GitHub的文件私有仓库有个特性：一旦你fork或者协作者操作失误，权限边界就可能被打破。泄露三天后，漏洞一个安全研究员在扫描公开泄露的文件密钥时发现了它，顺手下载了整张用户表。泄露二十万条学员记录，漏洞包括姓名、文件手机号、泄露课程购买记录，漏洞全部暴露。

这种事不是孤例。文件泄露漏洞的核心往往不在技术多复杂，而在人的操作惯性。开发人员习惯把测试文件、备份文件、日志文件随手扔在Web目录下，运维觉得内网访问就安全，产品经理把含敏感数据的Excel直接传到公开的CDN上。每个环节都觉得自己只是“临时放一下”，但互联网没有真正的临时。

我见过最离谱的一个案例：某电商网站的商品详情页URL后面加个.bak，直接下载到了整个网站的源代码压缩包。那个压缩包是两年前某次更新时运维手动备份的，放在根目录忘了删。两年来，任何知道这个命名规则的人都能拿到数据库密码、支付接口密钥、后台管理员账号。搜索引擎的爬虫甚至已经把它收录了——你在百度搜site:example.com filetype:bak，能翻出一堆类似的东西。

文件泄露的路径比大多数人想象的要多。Web服务器的默认配置会暴露目录列表，.git文件夹忘了删就能被git clone整个仓库，.DS_Store文件会泄露目录结构，phpinfo.php测试页忘了下线直接打印出服务器所有环境变量。还有更隐蔽的：Nginx的alias配置写错一个斜杠，就能通过路径穿越读到/etc/passwd。这些都不是什么高级漏洞，但每年OWASP的统计里，敏感信息泄露始终排在前十。

为什么这类问题反复出现？因为修复成本太低，低到没人当回事。删个文件、改个配置、加条deny all规则，五分钟的事。但发现成本同样低——攻击者不需要什么高深技术，写个脚本遍历常见备份文件后缀就行。.zip、.rar、.tar.gz、.sql、.bak、.old、.swp，这些后缀配上常见的文件名如www、backup、db、test，命中率不低。我做过一次小范围测试，随机选了五十个国内中小企业的网站，用这套字典跑了半小时，有七个能直接下载到数据库备份文件。

更麻烦的是云存储。S3桶权限设成public-read，阿里云OSS的Bucket Policy写错，腾讯云COS的临时密钥有效期设成永久。这些配置错误在控制台里就是一个下拉框的事，但后果是整桶数据裸奔。去年有个做医疗SaaS的公司，把患者影像数据存在OSS上，权限设成了公共读。任何人在浏览器里输入那个URL就能看到CT片和诊断报告。发现的时候，日志显示已经有来自十七个不同IP的访问记录。

防御这事，说复杂也复杂，说简单也简单。Web目录里不该有的文件就别放，放了就设成不可访问。云存储的权限默认私有，需要公开的单独开CDN。代码仓库提交前跑一遍密钥扫描，git-secrets或者trufflehog都行。Nginx配置里加一条location ~ /\. { deny all; }，能挡掉大部分点文件泄露。但真正管用的不是这些技术手段，是习惯——把“临时放一下”改成“放之前想一下”。

那个在线教育公司后来发了公告，说已修复漏洞并通知用户。但泄露的数据已经在Telegram群里转了好几手。有个学员接到诈骗电话，对方准确报出了他的课程名称和购买金额。他打电话给客服投诉，客服说“我们也是受害者”。这话没错，但用户不会这么想。文件泄露这事，漏洞在服务器上，根子在人的脑子里。