上个月帮一个做外贸的附件漏洞朋友看网站，刚打开首页我就愣住了——页脚挂着一个叫“product-list.php.bak”的附件漏洞文件。下载下来一看，附件漏洞数据库账号密码全在里面，附件漏洞明文。附件漏洞朋友还一脸茫然：“这文件谁传的附件漏洞？”没人知道。可能三年前某个离职的附件漏洞程序员顺手备份的，也可能某次服务器迁移时留下的附件漏洞。反正它就那么挂在那里，附件漏洞搜索引擎都能爬到。附件漏洞

这就是附件漏洞附件漏洞最典型的模样。不是附件漏洞什么高深的技术对抗，就是附件漏洞有人把不该放出来的文件放出来了，然后忘了删。附件漏洞

一个备份文件能捅多大篓子

很多人觉得“附件”这个词听起来无关紧要，附件漏洞像是邮件里带的那张图片、论坛里传的那个PDF。但放到Web环境里，附件的范围大得多——上传的文档、编辑器生成的缓存、打包好的源码、数据库导出文件、日志，甚至临时生成的缩略图。这些东西只要能被外部访问到，每一个都是潜在入口。

我见过最离谱的一个案例：某电商平台的后台管理页面需要登录，但它的富文本编辑器上传目录完全没有鉴权。攻击者直接往那个目录传了一个webshell，路径猜都不用猜，就是 /uploads/editor/ 这种默认结构。从上传到拿到服务器权限，前后不到两分钟。

问题出在哪？出在开发者的思维盲区。写上传功能的时候只想着“用户要传图片”，忘了“用户也可能传别的东西”。文件类型校验只查了扩展名，改个 Content-Type 就绕过去了。上传目录还偏偏放在Web根目录下，直接就能访问。三个失误叠在一起，就是一个完整的漏洞链。

那些“不算漏洞”的漏洞

有些附件问题甚至不需要上传功能。比如 .git 目录泄露。开发的时候用Git做版本控制，部署的时候直接把整个项目文件夹拖到服务器上，.git 也跟着上去了。攻击者访问 /.git/config 就能拿到仓库信息，再用工具把源码完整还原出来。源码里有什么？数据库密码、API密钥、内部接口地址，全齐了。

还有 .DS_Store 文件。Mac用户可能知道，这是Finder自动生成的目录索引文件。上传网站的时候如果不注意，这个文件也会跟着上去。它里面记录了当前目录下所有文件的名称，等于给攻击者提供了一份完整的文件清单。哪个文件是备份，哪个是配置文件，一目了然。

这些算漏洞吗？严格来说不算。没有代码执行，没有SQL注入，没有越权访问。但它们泄露的信息，往往比一个普通漏洞更有价值。安全圈有句话：信息泄露本身不是漏洞，但它是所有漏洞的起点。

防御这件事，靠的是习惯

我自己的做法很简单。上传目录独立部署，不放在Web根目录下，通过反向代理来提供访问。文件类型白名单，只允许特定扩展名，而且校验实际文件内容而不是光看后缀。上传后的文件全部重命名，用随机字符串，不给攻击者任何路径线索。部署脚本里加一步，自动清理 .git、.svn、.DS_Store 这些不该出现的文件。

听起来麻烦？其实配置一次就行了。真正麻烦的是出事之后擦屁股。数据被拖走、服务器被当跳板、客户信息在黑市上打包卖，那时候再回头查日志，发现入口就是一个三年前的备份文件。这种事我见得太多了。

附件漏洞的本质不是技术问题，是管理问题。代码写得再漂亮，架不住有人往服务器上随手扔文件。安全审计的时候别光盯着代码逻辑，也看看目录里到底挂了些什么东西。那些不该存在的文件，往往就是最致命的那个。