CTF-Web学习笔记:信息泄露篇
目录
引言
一、信息泄露的核心逻辑
二、CTF中最常见的6类信息泄露场景
1. 源码泄露:藏在版本控制里的“明文”
2. 配置文件泄露:写死的“数据库密码”
3. 日志泄露:被记录的“用户输入”
4. 备份文件泄露:“遗忘”的压缩包
5. 目录遍历泄露:“跳出”限制的访问
6. 错误信息泄露:“调试模式”的自曝
三、CTF实战:从“找泄露”到“拿Flag”
步骤1:信息收集——猜测可能的泄露点
步骤2:针对性验证——确认泄露是否存在
步骤3:深度挖掘——从泄露信息到Flag
四、实战案例:一道“目录遍历+日志泄露”综合题
题目背景
解题过程
五、总结与防御建议
对CTF选手的建议
对开发者的防御建议
引言
在CTF(Capture The Flag,夺旗赛)的Web安全赛道中,信息泄露(Information Leakage) 是一类“门槛低但价值高”的考点。它利用的是应用程序因配置不当、代码缺陷或逻辑漏洞,导致敏感信息(如源码、数据库配置、API密钥、用户数据等)被未授权访问的现象。许多新手选手的“第一桶金”(Flag),往往就藏在这些“不经意”的泄露里。
本文将结合CTF实战场景,系统梳理信息泄露的常见类型、挖掘技巧及防御思路,助你快速掌握“找秘密”的核心能力。
一、信息泄露的核心逻辑
信息泄露的本质是敏感数据的“非预期暴露”。这些数据可能存储在服务器文件系统、数据库、日志中,或通过接口、错误信息直接返回给客户端。攻击者的目标是通过各种手段(如直接访问、路径猜测、日志分析),找到这些“本应被保护”的信息。
二、CTF中最常见的6类信息泄露场景
1. 源码泄露:藏在版本控制里的“明文”
开发者常用Git、SVN等版本控制工具管理代码,但如果未正确配置服务器,这些工具的元数据或历史记录可能直接暴露在公网。
-
典型路径:
.git/
(Git仓库目录):可通过.git/config
获取仓库远程地址,通过.git/HEAD
和.git/index
恢复代码历史。.svn/
(SVN仓库目录):通过.svn/entries
文件获取版本控制信息。.hg/
(Mercurial仓库目录):类似Git/SVN,存储版本历史。
-
利用示例:
访问http://target.com/.git/config
,若返回以下内容,则说明存在Git源码泄露:[core]repositoryformatversion = 0filemode = truebare = falselogallrefupdates = true [remote "origin"]url = https://github.com/ctfer/secret-repo.git # 关键信息:仓库地址
攻击者可通过
git clone https://github.com/ctfer/secret-repo.git
直接下载源码,从中寻找Flag。
2. 配置文件泄露:写死的“数据库密码”
开发或测试环境中,配置文件(如config.php
、settings.py
、.env
)常直接存储数据库账号、API密钥等敏感信息。若这些文件被上传到生产环境且未删除,攻击者可直接访问获取。
-
常见文件名:
config.php
/config.yaml
(PHP/Python项目):存储数据库连接、JWT密钥。.env
(Docker/Node.js项目):环境变量文件,含DB_PASSWORD
、SECRET_KEY
。application.properties
(Java Spring项目):spring.datasource.password
等字段。
-
利用示例:
访问http://target.com/config.php
,若页面返回:<?php$db_host = "localhost";$db_user = "admin";$db_pass = "ctf2025"; # 关键信息:数据库密码$flag = "flag{info_leak_123}"; ?>
直接读取
$flag
变量即可拿到Flag。
3. 日志泄露:被记录的“用户输入”
服务器日志(如Nginx/Apache的访问日志、PHP的error_log
)可能意外记录敏感数据(如用户密码、API Key)。例如,若应用在错误日志中打印了用户提交的表单内容,攻击者可通过分析日志获取信息。
-
常见日志路径:
- Nginx:
/var/log/nginx/access.log
(访问日志)、/var/log/nginx/error.log
(错误日志)。 - Apache:
/var/log/apache2/access.log
- Nginx: