常见Web源码泄露总结
主要记录一下常见的源码泄漏问题，这些经常在web渗透测试以及CTF中出现。
一、源码泄漏分类
1、.hg源码泄漏
漏洞成因：
hg init的时候会生成.hg
e.g.http://www.example.com/.hg/
漏洞利用：
工具：dvcs-ripper
rip-hg.pl -v -u http://www.example.com/.hg/
2、.git源码泄漏
漏洞成因：
在运行git init初始化代码库的时候，会在当前目录下面产生一个.git的隐藏文件，用来记录代码的变更记录等等。在发布代码的时候，把.git这个目录没有删除，直接发布了。使用这个文件，可以用来恢复源代码。
e.g.http://www.example.com/.git/config
漏洞利用：
工具：GitHack
GitHack.py http://www.example.com/.git/
dvcs-ripper
rip-git.pl -v -u http://www.example.com/.git/
3、.DS_Store文件泄漏
漏洞成因:
在发布代码时未删除文件夹中隐藏的.DS_store，被发现后，获取了敏感的文件名等信息。
漏洞利用:
http://www.example.com/.ds_store
注意路径检查
工具：dsstoreexp
python ds_store_exp.py http://www.example.com/.DS_Store
4、网站备份压缩文件
在网站的使用过程中，往往需要对网站中的文件进行修改、升级。此时就需要对网站整站或者其中某一页面进行备份。当备份文件或者修改过程中的缓存文件因为各种原因而被留在网站web目录下，而该目录又没有设置访问权限时，便有可能导致备份文件或者编辑器的缓存文件被下载，导致敏感信息泄露，给服务器的安全埋下隐患。
漏洞成因及危害:
该漏洞的成因主要有以下两种：
服务器管理员错误地将网站或者网页的备份文件放置到服务器web目录下。
编辑器在使用过程中自动保存的备份文件或者临时文件因为各种原因没有被删除而保存在web目录下。
漏洞检测:
该漏洞往往会导致服务器整站源代码或者部分页面的源代码被下载，利用。源代码中所包含的各类敏感信息，如服务器数据库连接信息，服务器配置信息等会因此而泄露，造成巨大的损失。被泄露的源代码还可能会被用于代码审计，进一步利用而对整个系统的安全埋下隐患。
.rar.zip.7z.tar.gz.bak.swp.txt.html
5、SVN导致文件泄露
Subversion，简称SVN，是一个开放源代码的版本控制系统，相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上越来越多的控制服务从CVS转移到Subversion。
Subversion使用服务端—客户端的结构，当然服务端与客户端可以都运行在同一台服务器上。在服务端是存放着所有受控制数据的Subversion仓库，另一端是Subversion的客户端程序，管理着受控数据的一部分在本地的映射（称为“工作副本”）。在这两端之间，是通过各种仓库存取层（Repository Access，简称RA）的多条通道进行访问的。这些通道中，可以通过不同的网络协议，例如HTTP、SSH等，或本地文件的方式来对仓库进行操作。
e.g.http://vote.lz.taobao.com/admin/s/fckeditor.266/editor/.svn/entries
漏洞利用:
工具：dvcs-ripper
rip-svn.pl -v -u http://www.example.com/.svn/
Seay-Svn
6、WEB-INF/web.xml泄露
WEB-INF是Java的WEB应用的安全目录。如果想在页面中直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问。
WEB-INF主要包含一下文件或目录：
/WEB-INF/web.xml：Web应用程序配置文件，描述了 servlet 和其他的应用组件配置及命名规则。
/WEB-INF/classes/：含了站点所有用的 class 文件，包括 servlet class 和非servlet class，他们不能包含在 .jar文件中
/WEB-INF/lib/：存放web应用需要的各种JAR文件，放置仅在这个应用中要求使用的jar文件,如数据库驱动jar文件
/WEB-INF/src/：源码目录，按照包名结构放置各个java文件。
/WEB-INF/database.properties：数据库配置文件
漏洞成因：
通常一些web应用我们会使用多个web服务器搭配使用，解决其中的一个web服务器的性能缺陷以及做均衡负载的优点和完成一些分层结构的安全策略等。在使用这种架构的时候，由于对静态资源的目录或文件的映射配置不当，可能会引发一些的安全问题，导致web.xml等文件能够被读取。
漏洞检测以及利用方法：
通过找到web.xml文件，推断class文件的路径，最后直接class文件，在通过反编译class文件，得到网站源码。一般情况，jsp引擎默认都是禁止访问WEB-INF目录的，Nginx 配合Tomcat做均衡负载或集群等情况时，问题原因其实很简单，Nginx不会去考虑配置其他类型引擎（Nginx不是jsp引擎）导致的安全问题而引入到自身的安全规范中来（这样耦合性太高了），修改Nginx配置文件禁止访问WEB-INF目录就好了： location ~ ^/WEB-INF/* { deny all; } 或者return 404; 或者其他！
7、CVS泄漏
漏洞利用：
测试的目录
http://url/CVS/Root 返回根信息http://url/CVS/Entries 返回所有文件的结构
取回源码的命令
bk clone http://url/name dir
这个命令的意思就是把远端一个名为name的repo clone到本地名为dir的目录下。
查看所有的改变的命令，转到download的目录
bk changes
8、Bazaar/bzr
工具：dvcs-ripper
rip-bzr.pl -v -u http://www.example.com/.bzr/
二、工具推荐
Bitkeeper
weakfilescan
Web应用中的信息泄漏以及攻击方法
下面内容介绍了在web应用程序中的一些信息泄漏问题，当然也会举例分析，介绍如何发现这些信息泄漏。
一、Banner收集/主动侦查
Banner收集或主动侦察是一种攻击类型，攻击者在此期间向他们的目标系统发送请求，以收集有关它的更多信息。如果系统配置不当，可能会泄漏自己的信息，如服务器版本，PHP或者ASP.NET版本，OpenSSH版本等。
在大多数情况下，Banner收集并不会涉及关键信息泄漏，不过可以让攻击者收集到开发过程中使用环境版本的信息。例如：如果目标在服务器上面使用的是php旧版本，由于没有更新，所以攻击者可以利用已知的漏洞攻击，也许会出现远程命令执行/代码执行的漏洞。
Banner信息收集举例：
Nmap scan report for example.com (x.x.x.x)
Host is up (0.037s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.3 (Ubuntu Linux; protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
在上面例子中，我们使用Nmap扫描器对目标进行端口扫描。结果表明目标开启了22端口，并且OpenSSH版本号是5.9p1。也许这个版本就存在可以被攻击者利用的漏洞。
二、源码泄漏
当Web应用程序的后端环境代码暴露给不涉及应用程序开发的用户时，会发生源代码泄露问题。源代码泄露使攻击者能够通过读取代码和检查逻辑缺陷，以及查看硬编码的用户名/密码对或者API密钥来发现这个应用程序的不足以及漏洞。
漏洞的严重性取决于泄漏源码的多少，以及代码在应用程序中的重要性。总而言之，因为攻击者可以查看源代码，所以很大程度上将渗透测试由黑盒转向白盒。事实上，有很多错误能够导致源码泄漏的漏洞发生，下面这几种错误就包含在其中：
代码库未受保护
为了更加方便的管理站点，大多数站点都会把他们源码上传到云端。这些项目有时会管理不当，攻击者能够直接访问网站源码和网站信息。并且，有些公司将他们的开源软件项目放到了github上面，这样公共用户可以对这个项目作出改进。这种情况下，源码已经是公开的，但是这种情况下泄漏公司重要信息已经是很常见了。
实例：
有些源码库只允许使用第三方帐号进行登录并且符合身份认证的用户查看源码代码。这些源码库有时候配置错误，没有严格控制查看内容的权限，导致任何人都可以查看源码内容。
源代码中存在敏感信息
另一个例子是当公共代码具有硬编码的敏感信息时，例如用户凭证或API密钥。攻击者可以轻松地使用这些信息来破坏这些服务，或者可以使用合法账户进行登录。在信息披露期间通常泄漏的另一条信息是内部IP地址，允许攻击者识别和了解内部网络拓扑，然后可以将这样的信息用于攻击内部服务中，例如服务器端请求伪造（SSRF）攻击来攻击多个系统。
MIME类型不正确
浏览器通过HTTP包头中的Content-Type内容来确定如何解析HTTP服务器响应返回的内容。举个例子，我们想让浏览器将html文件解析，而不是只是纯文本文件。再比如我们想让浏览器下载一个zip，而不是解析这个zip文件。
如果web服务器的配置错误，那么就会出现这样的错误：当我们访问html时候，Conten-Type会是:text/plain,而不是text/html，并且html文件会以纯文档的形式展现给浏览器。因此</>还有一些其他字符都会在页面上显示出来。下面图片是展示当页面访问时服务器设置的Content-Type响应头。
当Web应用程序无法为其中包含源代码的网页发送适当的Content-Type头部时，可能会发生信息泄露问题，并且最终以纯文本形式呈现信息，并披露有关Web应用程序的有价值信息。
实例：
我们假设一个Web服务器用于运行一个PHP
Web应用程序，但现在运行一个ASP.NET。以前由旧的Web应用程序使用并具有敏感信息（如MySQL数据库凭据）的PHP脚本正在被用户访问。如果PHP没有在Web服务器上运行和配置，则Content-Type将从HTTP响应中省略，并且PHP脚本将被解释为纯文本或HTML标记，具体取决于Web浏览器，然后就会泄露里面包含的所有信息。
下面屏幕截图就展示了即使服务器返回头没有设置Content-Type，火狐浏览器还是将php脚本解析成了HTML。我们需要在查看源代码中看到脚本信息。
下面截图展示了chrome浏览器直接返回了纯文本的文件，所以我们可以直接看到源码。
处理敏感信息不当
另一种常见的信息泄漏是由硬编码的账户名和密码以及内部ip在代码的注释中泄漏。在大多数情况下，这些敏感信息在访问web页面时会展现出来。这些敏感信息的泄漏也可能会导致web应用程序遭受攻击。攻击者只需要右键页面查看网页源代码，就可以找到这些注释。如果在发现web应用程序存在这种问题，Netsparker将会提醒您。
缺少认证机制或者认证机制配置不当
在Web应用程序权限设置不正确，不完整或甚至缺少授权检查可能会允许攻击者访问敏感信息或未授权访问登录用户的信息。这些问题很常见，它们也列在OWASP十大最常见和利用漏洞的列表中。
示例：https://www.netsparker.com/blog/web-security/missing-function-level-access-control-vulnerability-maian-support-helpdesk/
一个真实的权限控制不当，导致被拿shell的案例。
文件名或者文件路径泄漏
在某些情况下，Web应用程序可以公开文件名或文件路径，从而显示关于底层系统结构的信息。这可能是由于用户输入的不正确处理，后端的异常或Web服务器的不当配置。有时可以在Web应用程序，错误页面，调试信息等的响应中找到或标识这些信息。
示例：
攻击者可以通过发送访问请求来检查Web应用程序是否公开任何文件名或路径。例如，当发送以下请求时，Web应用程序返回403（禁止）响应：
https://www.example.com/%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
但是当攻击者发送下面请求时，web应用程序返回404（没有文件）的响应：
https://www.example.com/%5C../%5C../%5C../%5C../%5C../%5C../etc/doesntexist
由于第一次请求，攻击者得到了403 Forbidden错误，而对于第二个请求，他得到了404 Not Found，他知道在第一种情况下，该文件存在。因此，攻击者可以利用Web应用程序的行为，了解服务器的结构以及验证系统上是否存在某个文件夹或文件。
三、目录遍历
文件名和路径公开相关的是Web服务器中的目录显示功能。此功能在Web服务器上默认提供。当没有默认网页时，在网站上显示Web服务器显示用户列表中的文件和目录。
因此，在apahce服务器上面默认文件名为Index.php，当没有上传index.php时，服务器就会将文件夹中的内容全部展示出来。如下图：
使用这样一个模块会使服务器产生很大的安全隐患。
实例：
现在很多人都知道这样的功能应该被禁用，所以看到它并不常见。虽然我们假设扫描Web服务器的端口后，攻击者发现在8081端口运行的Web服务器的默认启动此功能。
这样的“默认值”通常被Web服务器管理员忽略，这也意味着它们不太安全。它会允许攻击者浏览目录并访问Web应用程序的源代码，备份和可能的数据库文件。
四、防止信息泄漏应该注意的事项
信息泄漏问题似乎是一件小事情，但对攻击者来说是非常有价值的。它们允许攻击者通过执行基本测试，有时只需在公共页面中查找信息，获得有关攻击目标的非常有用的信息。
事实上，Netsparker在扫描目标网站时会报告知识库节点中可能的信息披露和其他类似的安全问题。你应该解决这些问题，特别是当你认为它们很容易修复时。以下是遵循的一些指导方针，以便您可以确保您的Web应用程序受到良好保护：
1. 确保您的Web服务器不发送显示有关后端技术类型或版本信息的响应头。
2. 确保服务器打开的端口上运行的所有服务都不会显示有关其构建和版本的信息。
3. 确保所有目录的访问权限正确，保证不会让攻击者访问到你的所有文件。
4. 不要在代码中将账户密码硬编码进去。也不要在注释中写入相关信息。
5. 在web服务器中为所有类型的应用程序配置MIME信息
6. 不需要上传到网站上的敏感信息永远都不要上传
7. 始终检查每个创建/编辑/查看/删除资源的请求是否具有适当的访问控制，防止越权访问，并确保所有机密信息保密。
8. 确保您的Web应用程序正确处理用户输入，并且始终为所有不存在/不允许的资源返回通用响应，以便混淆攻击者。
9. 后端代码应该考虑到所有情况，并且当异常发生时，能够保证信息不被泄漏。
10. 配置Web服务器以禁止目录遍历，并确保Web应用程序始终显示默认网页。
本文参考来源于：MottoIN，Pro4hou，转载自计算机与网络安全
别忘了投稿哟！！！
合天公众号开启原创投稿啦！！！
大家有好的技术原创文章。
欢迎投稿至邮箱：edu@heetian.com；
合天会根据文章的时效、新颖、文笔、实用等多方面评判给予100元-500元不等的稿费哟。
有才能的你快来投稿吧！
标签： 客户端是服务端吗