文件泄露漏洞

关注

转载最新推荐文章于 2026-06-26 13:34:59 发布 6.3k 阅读 AI 写同款· GEO 优化 ›

DS_Store文件泄露漏洞：从信息收集到深度利用的实战指南信息泄露是网络安全中常见且高风险的安全问题，它通常源于系统默认配置或人为疏忽，导致本应隐藏的敏感数据意外暴露。其核心原理在于，应用程序或服务器在缺乏适当访问控制的情况下，将内部信息（如文件路径、配置数据）泄露给未授权方。这类漏洞的技术价值在于，攻击者无需利用复杂的代码执行缺陷，仅通过信息收集和推理，就能获取系统内部结构图，为后续攻击（如未授权访问、敏感文件下载）提供关键路径。在Web安全、渗透测试等应用场景中，信息泄露常作为攻击链的起点，通过暴露后台地址、备份文件位置等关键信息，大幅降低后续攻击难度。本文聚阅读详情

文件泄露：

git

git可以说是当今最受欢迎的版本控制/版本管理软件了, 很多基于git的云端托管仓库都提供了
免费的托管服务, 甚至有不少还支持免费私有仓库, 如bitbucket和国内的gitosc(开源中国)等.

关键文件

git在初始化项目的时候, 会在项目的根目录(可用git rev-parse --show-toplevel查看)创建一个名为
.git的隐藏文件夹, 里面包含了本地所有commit的历史记录. 如果无意间将这个目录置于WEB的路径下让用户可以访问,
那么也就泄露了几乎所有的源代码和其他其他敏感信息.

泄露内容

所有该项目的源代码
私有仓库的地址
私密的配置信息
所有commiter的邮箱帐号信息
(可能)内部的帐号和密码
...

利用方法

常规的利用方法就是下载整个目录, 然后用git命令回滚整个项目:

wget -r --no-parent --mirror http://www.example.com/.git

cd www.example.com && git reset --hard

当然也有一些自动化利用的脚本:

dvcs-ripper: 基于perl的工具,除了git还支持很多版本管理系统

rip-git.pl -v -u http://www.example.com/.git/

GitHack

GitHack.py http://www.example.com/.git/

工具：http://www.freebuf.com/tools/66096.html

GitHack.py下载地址：https://github.com/lijiejie/GitHack
具体可以看一下这篇文章：http://www.lijiejie.com/githack-a-git-disclosure-exploit/

修复建议

一般基于MVC的现代WEB框架都不会直接挂载文件, 但如果是基于PHP,ASP等语言的项目, 还是会存在安全隐患,
虽然可以通过配置WEB服务器(apache/nginx等)来拒绝对.git路径的访问, 但也会出现被意外绕过的风险.
最好的办法就是在项目新建一个www目录来存放源代码文件.

hg/Mercurial

Mercurial的意思是水银, 所以缩写成hg(汞), 也是一个版本管理软件. 用法和git有点类似, 但也保留了svn命令简明的特点,
而且原生地支持Windows/MacOS/Linux三大平台, 不像git需要MinGW才得以运行, 所以当今也有不少人偏向于用hg做版本控制.
关于他们有一些讨论, 如为什么要用hg,
为什么选hg而不是git等等, 我认为也是值得了解的.

关键文件

与git类似, hg在初始化项目时(hg init的时候会生成.hg), 会在项目的根目录下创建一个名为.hg的隐藏文件夹,
里面包含了代码和分支的修改记录和开发人员的相关信息.

泄露内容

项目源代码
项目仓库地址
(可能)仓库的用户名
其他

利用方法

手动利用, 下载+回滚:

wget -r --no-parent --mirror http://www.example.com/.hg

rip-hg.pl -v -u http://www.example.com/.hg/

cd www.example.com && hg revert

也可以用上面提到的dvcs-ripper工具来利用

修复建议

同git

svn/Subversion

svn, 即Subversion, 在github之前曾经也是炙手可热的版本管理工具, 虽然已经日渐式微, 但在很多国企,
研究院等地方依然是作为版本管理的主要工具. 对于一些历史悠久的项目, 比如LLVM, 出于历史原因,
也是主要使用svn管理源代码.

关键文件

svn同样在项目根目录下会创建一个名为.svn的隐藏文件夹, 包含了所有分支commit信息和代码记录.

泄露内容

所有该项目的源代码
svn仓库的地址
svn仓库所属用户的用户名
...

利用方法

https://pan.baidu.com/s/1eQiRF02

同样是先下载目录, 然后回滚:

wget -r --no-parent --mirror http://www.example.com/.svn

cd www.example.com && svn revert --recursive .

工具&脚本:

dvcs-ripper: 支持旧版和新版的svn

rip-svn.pl -v -u http://www.example.com/.svn/

Seay-Svn: 法师的工具,基于Windows平台

测试链接

http://url/.svn

这个已经有利用工具了 http://pan.baidu.com/s/1mrNpB

修复建议

同git

bzr/Bazaar

bzr也是个版本控制工具, 虽然不是很热门, 但它也是多平台支持, 并且有不错的图形界面,
所以也有一些人认为bzr比git要好用,
只是对于渗透测试人员来说, 其实都无所谓就是了.

关键文件

bzr在初始化项目时(bzr init/init-repo), 会在项目根目录产生名为.bzr的隐藏目录, 同样暴露了源代码和用户信息.

泄露内容

源代码
仓库地址
开发者的信息
...

利用方法

没用过bzr工具, 不过查询文档得知可用bzr revert命令来进行回滚:

wget -r --no-parent --mirror http://www.example.com/.bzr

cd www.example.com && bzr revert

当然dvcs-ripper工具也是可以的.

修复建议

同git

cvs

CVS是一个年代比较久远的版本控制系统, 通过它可以追踪源代码的历史变化记录.
但是因为功能比较简单, 而且不支持分支, 所以很早前就被上面提到的svn替代了.

关键文件

cvs项目在初始化(cvs checkout project)的时候, 会在project目录下创建一个名为CVS的目录,
其中保存了各个文件的修改和commit记录. 通过此目录可以获取代码的历史版本. 其中两个关键文件为:
CVS/Root和CVS/Entries, 分别记录了项目的根信息和所有文件的结构

泄露内容

因为是纯客户端的工具, 所以只会泄露源代码

利用方法

下载CVS文件夹然后通过cvs命令获取源码信息, 不过似乎没有直接的回滚操作, 需要做点额外的处理.

wget -r --no-parent --mirror http://www.example.com/CVS

cd www.example.com && cvs diff *

取回源码的命令

bk clone http://url/name dir

这个命令的意思就是把远端一个名为name的repo clone到本地名为dir的目录下。

查看所有的改变的命令，转到download的目录

bk changes

或者直接用工具dvcs-ripper

rip-bzr.pl -v -u http://www.example.com/.bzr/

修复建议

如果你还在用CVS, 没准你还在用perl写cgi吧? ...

其他

版本管理工具有很多, 除了上面提到的这些, 还有曾经比较知名的如BitKeeper, 现在已经很少用了, 不过偶尔还是会在CTF比赛中炸尸.

Bitkeeper

这真的是上古神器了，我后面要介绍的其他几款工具推出的时候都是要号称取代bitkeeper…

该款软件如何安装的说明，上面附带有把试用版本发送到自己的邮箱…：http://www.bitkeeper.com/installation.instructions

测试的目录

http://url/.bk 403 Forbidden

取回源码的命令

bk clone http://url/name dir

这个命令的意思就是把远端一个名为name的repo clone到本地名为dir的目录下。

查看所有的改变的命令，转到download的目录

bk changes

文件包含导致的泄露：

`.DS_Store`文件泄露

.DS_Store(Desktop Services Store)是macOS目录下的隐藏文件, 包含了当前目录结构和一些的自定义信息,
如背景和图标位置等, 在windows下类似的文件为desktop.ini. 暴露了.DS_Store文件也就相当于暴露了该目录下的所有内容.
可以说是比较严重的泄露.

利用方法

https://github.com/lijiejie/ds_store_exp

.DS_Store的格式为二进制, 内部数据结构为Proprietary格式,
可以自行解析并递归下载所有文件, 参考lijiejie的ds_store_exp.

工具：

dsstoreexp

python ds_store_exp.py http://www.example.com/.DS_Store

修复建议

使用macOS开发的同学, 可以把.DS_Store加入忽略列表中(如.gitignore), 但本质上其只是泄露目录结构, 就算删掉.DS_Store,
文件也依然存在于web服务器可以访问得到的地方, 所以治本的方法还是不要将敏感信息放在web路径中.

WEB-INF泄露

在Java的Servlet 文档中,

(WEB-INF是Java的WEB应用的安全目录。如果想在页面中直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问。)
说到WEB-INF目录"包含了所有web应用会用到但是不处于web路径中的资源", 也就是说, WEB-INF目录下的内容是不属于公开页面的.
web应用可以通过getResource等API在servlet的上下文中访问到这些资源.

通常开发者会把许多JSP文件,Jar包,Java的类文件放在该目录下. 一般目录的内容都是可以预测的:

WEB-INF/web.xml : Web应用程序配置文件, 描述了servlet和其他的应用组件配置及命名规则.

WEB-INF/database.properties : 数据库配置文件

WEB-INF/classes/ : 一般用来存放Java类文件(.class)

WEB-INF/lib/ : 用来存放打包好的库(.jar)

WEB-INF/src/ : 用来放源代码(.asp和.php等)

漏洞检测以及利用方法：

通过找到web.xml文件，推断class文件的路径，最后直接class文件，在通过反编译class文件，得到网站源码。

一般情况，jsp引擎默认都是禁止访问WEB-INF目录的，Nginx 配合Tomcat做均衡负载或集群等情况时，问题原因其实很简单，Nginx不会去考虑配置其他类型引擎（Nginx不是jsp引擎）导致的安全问题而引入到自身的安全规范中来（这样耦合性太高了），修改Nginx配置文件禁止访问WEB-INF目录就好了： location ~ ^/WEB-INF/* { deny all; } 或者return 404; 或者其他！

利用方法

通过web.xml文件推测应用组件相关类的名字, 然后在src目录下查找代码, 如果没有源代码可以直接下载class文件反编译即可.

修复建议

发布前确认WEB-INF目录是禁止访问的, 或者在server设置好对于的过滤规则.

备份文件泄露

网站备份压缩文件

在网站的使用过程中，往往需要对网站中的文件进行修改、升级。此时就需要对网站整站或者其中某一页面进行备份。当备份文件或者修改过程中的缓存文件因为各种原因而被留在网站web目录下，而该目录又没有设置访问权限时，便有可能导致备份文件或者编辑器的缓存文件被下载，导致敏感信息泄露，给服务器的安全埋下隐患。

漏洞成因及危害:

该漏洞的成因主要有以下两种：

服务器管理员错误地将网站或者网页的备份文件放置到服务器web目录下。

编辑器在使用过程中自动保存的备份文件或者临时文件因为各种原因没有被删除而保存在web目录下。

漏洞检测:

该漏洞往往会导致服务器整站源代码或者部分页面的源代码被下载，利用。源代码中所包含的各类敏感信息，如服务器数据库连接信息，服务器配置信息等会因此而泄露，造成巨大的损失。被泄露的源代码还可能会被用于代码审计，进一步利用而对整个系统的安全埋下隐患。

.rar .zip .7z .tar.gz .bak .swp .txt .html

备份文件泄露又分为两种情况, 一种是运维人员偷懒地直接在网站根目录用类似

tar -czvf bakup.tgz *的命令将网站进行备份,
这样整站的源代码都能直接被用户打包下载了；另一种是开发或者运维人员使用的编辑器修改文件时自动备份了所编辑的网页内容,
如vim的.swp, 从而泄露了该网页的源代码.

利用方法

对于打包文件而言, 渗透测试人员可以用{常用文件名}+{常用压缩包后缀}的方式扫描网站, 说不定会有意外惊喜.
对于网页的临时备份文件, 可以扫描对应页面的.swp或者.bak等后缀, 说不定也能找到有用的信息.

修复建议

做好版本管理, 并利用版本管理工具过滤掉这些类型的文件, 同时不要直接在生产环境中修改或者添加文件.

配置文件泄露

现代WEB开发往往不会重新造轮子, 而是基于成熟的框架进行配置, 如果渗透测试人员知道该网站是基于什么类型的框架,
就可能通过该框架的文档获得重要配置文件的路径, 如果是开源框架, 同时也能获得源代码, 因此配置文件泄露的严重性也是不言而喻的.

利用方法

通过识别网站指纹得知其框架类型, 然后手工测试重要的配置文件是否可以获取. 如果是批量测试, 则可以事先准备好
常见的配置文件路径, 如wordpress的/wp-config.php等, 组织成字典然后用脚本进行批量测试. 可以参考猪猪侠的字典.

修复建议

修改配置文件的默认路径, 同时在服务器端阻止对这些路径的访问.

配置错误有关的错误：（）

Windows IIS / Apache 目录穿越

目录穿越漏洞原理比较简单, 程序在实现上没有充分过滤用户输入的../之类的目录跳转符, 导致恶意用户可以访问web根目录的上级从而遍历服务器上的任意文件.
虽然web服务器本身会禁止访问web文件夹以外的地方, 但如果是智障开发引入的动态页面, 又没有过滤好用户输入, 就可能会出现穿越甚至目录遍历.
甚至web服务器本身也曾经有类似的漏洞, 比如Apache Tomcat的UTF-8解析漏洞, 具体利用和绕过可以参考其他网上的文章, 这里限于篇幅就不展开了.

Nginx配置安全

Nginx的配置选项之多,并不是所有人都能熟悉,但不表示随便百度一下复制粘贴就配置了,最好还是先看下官方文档对应选项的作用和用法,
可以避免许多致命的错误. 例如Nginx在代理静态文件时, 如果不小心在配置文件中写错了一个字符:

location /static {

    alias /home/web/static/;

就会导致访问http://example.com/static../时可以访问上级目录, 从而访问到敏感的信息.
关于nginx配置安全, 离别歌的这篇文章其实写得很不错, 值得每个开发和运维人员仔细了解.

文件泄露在ctf中：

web题目中源码泄露还是比较常见的，在什么时候需要去考虑源码泄漏呢，一是题目中所有猜测的可能存在漏洞的点都确认应该没有漏洞的时候，比如说在有一次比赛中题目中给了个登录框…后来确认是静态的页面，那这个时候就必须考虑源码泄露了。二是已经确认了解题思路，但是对漏洞的测试非常难以进行的，比如说这次bctf，xss在我们这里没有回显，而管理的页面也看不到，每次都要等到robot看过了我们提交的页面之后才能确认xss是否成功，这是非常麻烦的，而主办方也不希望因为自己的机器人出问题而影响大家漏洞的测试，这次比赛中robot屡次出现问题…有源码泄漏的可能性还是很高的。为什么要强调这一点，这一点其实只有在比赛中才会比较有用，因为一道题没有人做出来的话，才有放hint的可能性，如果你的思路比较跳，你就容易在这样的比赛中获得优势。本次bctf因为第二道homework太久没人做出来才放的hint，如果说很早就有人发现了源码泄露，那么这道题估计注定只有一个人能做出来了。

Mercurial

也是这次bctf使用的，测试目录

http://url/.hg 403 Forbidden

clone下来的命令:

hg clone url

查看更改的

hg log

实际上版本控制工具还有很多，这里介绍了几个比较常用的，其他的需要参考wiki:https://zh.wikipedia.org/zh/%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6

有关知识网站：

https://www.cnblogs.com/pannengzhi/p/2017-09-23-web-file-disclosure.html

http://www.mottoin.com/95749.html

https://zhuanlan.zhihu.com/p/21296806