yhy0 Information Disclosure Penetration Testing Patterns
当对 Web 应用进行信息泄露渗透测试时加载此 Skill。覆盖凭证泄露、敏感数据暴露、目录列举、错误信息泄露等。
Attack Surface Discovery
高风险区域：
- 公开代码仓库：GitHub/GitLab commit 历史中的 API key、token、密码
- CI/CD 日志：构建日志中暴露的环境变量、凭证
- 错误页面：详细的 stack trace、数据库连接字符串、内部 IP
- API 响应：多余字段泄露（
password_hash、internal_id、admin_email） - 目录列举：
/backup/、/.git/、/.env、/wp-config.php.bak - JavaScript 文件：硬编码的 API endpoint、token、内部 URL
- 配置文件暴露：
.env、config.yaml、application.properties - HTTP 响应头：
Server、X-Powered-By、自定义调试头
识别信号：
- 响应中包含内部 IP 地址或主机名
- 错误信息暴露框架版本、文件路径
- API 返回不必要的字段（id、hash、internal 字段）
Exploitation Techniques
Git 仓库泄露：
# 检查 .git 目录是否可访问
curl -s https://target.com/.git/HEAD
curl -s https://target.com/.git/config
# 使用 git-dumper 下载完整仓库
git-dumper https://target.com/.git/ ./output
# GitHub 搜索泄露的凭证
# 搜索 org:target "password" 或 "api_key" 或 "secret"
敏感文件探测：
/.env # 环境变量（数据库密码、API 密钥）
/backup.sql # 数据库备份
/wp-config.php.bak # WordPress 配置备份
/.DS_Store # macOS 目录索引
/crossdomain.xml # Flash 跨域策略
/server-status # Apache 状态页
/actuator/env # Spring Boot actuator
/debug/vars # Go pprof 调试
/graphql/playground # GraphQL IDE 暴露
/swagger-ui.html # API 文档
API 信息泄露：
- 请求不存在的资源，对比 "用户不存在" vs "密码错误" 响应差异（用户枚举）
- 检查 API 响应中是否包含多余字段（使用低权限账户对比）
- 测试 GraphQL introspection：
{ __schema { types { name fields { name } } } } - 检查 Verbose 错误模式：触发异常查看是否返回 stack trace
云凭证泄露：
- 搜索 CI/CD 日志中的
AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY - 检查 Docker 镜像层中的环境变量：
docker history --no-trunc image - Slack/Discord webhook URL 泄露（可发送任意消息）
- Datadog/Sentry API key 泄露（可读写监控数据）
Detection Checklist
- 使用 dirsearch/gobuster 扫描常见敏感路径（.git、.env、backup、config）
- 检查 Git commit 历史中的凭证（truffleHog、gitleaks）
- 检查 JavaScript 文件中硬编码的 API key 和 token
- 触发应用错误观察错误信息详细程度（stack trace、SQL 错误、文件路径）
- 检查 API 响应中的多余字段（对比不同权限级别）
- 测试 GraphQL introspection 是否开放
- 检查 HTTP 响应头中的信息泄露（Server、X-Powered-By）
- 搜索 CI/CD 日志和公开文档中的凭证
- 检查 Spring Boot actuator、debug endpoint 是否暴露
- 验证发现的凭证是否仍然有效（谨慎操作，避免超出授权范围）
Impact Assessment
漏洞利用可达到的效果：
- 凭证窃取：API key、数据库密码、云平台凭证 → 直接接管相关服务
- 源代码泄露：通过 .git 获取完整代码 → 发现更多漏洞
- 内部网络映射：通过泄露的 IP/主机名了解内部架构
- 用户数据泄露：PII、邮箱、手机号等敏感信息暴露
- 供应链攻击：CI/CD token 泄露 → 篡改构建产物
严重度判断：
- Critical：有效的云凭证（AWS/GCP/Azure）、数据库密码、管理员 token 泄露
- High：源代码泄露、API key 泄露可读取敏感数据、大量 PII 暴露
- Medium：内部架构信息、版本信息、非敏感配置泄露
Real-World Cases
以下案例来自 HackerOne 公开披露的真实漏洞报告，展示了该类漏洞在实际目标中的表现形式。
Case 1: Bykea — Critical Information Disclosure via /talos/api/v1/files/upload
- 严重度: Critical | CWE: Inclusion of Sensitive Information in an Include File
- 摘要: A vulnerability was discovered in the file upload functionality, where uploaded files were first stored on the server before being sent to S3. Due to a configuration flaw, memory chunks from the serve...
- 报告: https://hackerone.com/reports/3228011
Case 2: HackerOne — The /reports/:id.json endpoint discloses potentially sensitive user attributes when reporter summary is present
- 严重度: Critical | CWE: Information Disclosure
- 摘要: The /reports/:id.json endpoint disclosed potentially sensitive user attributes, including the reporter's email, OTP backup codes, phone number, graphql_secret_token, and t-shirt size when a reporter s...
- 报告: https://hackerone.com/reports/3000510
Case 3: HackerOne — Creation of bounties through Customer API leads to private email disclosure
- 严重度: Critical | CWE: Information Disclosure
- 摘要: The creation of bounties through the Customer API led to the disclosure of private email addresses. The vulnerability was demonstrated by using both the API and GraphQL requests to award a program bou...
- 报告: https://hackerone.com/reports/2382120
Case 4: Khan Academy — Unauthorized Account Access via Leaked Credentials in URL Format (Account Takeover )
- 严重度: Critical | CWE: Cleartext Storage of Sensitive Information
- 摘要: The vulnerability allowed attackers to access user accounts on khanAcademy.com using leaked credentials that were publicly available. The credentials were found in clear text format on a third-party w...
- 报告: https://hackerone.com/reports/3080597
Case 5: Mars — Datadog api keys exposed can be used to do all the read and write access to the instance
- 严重度: Critical | CWE: Information Disclosure
- 摘要: A vulnerability was identified where Datadog API keys were exposed in a JavaScript file, which could have enabled unauthorized access to Datadog services. The issue was responsibly disclosed along wit...
- 报告: https://hackerone.com/reports/2307933
Case 6: Mozilla — Netlify Authentication Token Exposed in Public Mozilla CI Logs
- 严重度: Critical | CWE: Information Disclosure
- 摘要: A critical vulnerability was discovered involving the exposure of a Netlify authentication token within publicly accessible logs. The token provided full access to the "Mozilla IT Web SRE" Netlify acc...
- 报告: https://hackerone.com/reports/2915647
Case 7: Mozilla — two aws access key and secret key and database username and password exposed
- 严重度: Critical | CWE: Information Disclosure
- 摘要: A security vulnerability was identified in a Docker image hosted on Docker Hub. The image, associated with Mozilla's Common Voice project, was found to contain exposed AWS access keys, AWS secret keys...
- 报告: https://hackerone.com/reports/2401648
Case 8: Mozilla — Jira Credential Disclosure within Mozilla Slack
- 严重度: Critical | CWE: Information Disclosure
- 摘要: The Jira admin API keys were disclosed within a Mozilla Slack channel by a staff member. The exposed credentials allowed for the verification of the user's elevated privileges, including being a Jira ...
- 报告: https://hackerone.com/reports/2467999
Case 9: Mozilla — Mozilla Employee's Token for sql.telemetry.mozilla.org Exposed in Git Commit
- 严重度: Critical | CWE: Cleartext Storage of Sensitive Information
- 摘要: A Mozilla employee's API token was exposed in a GitHub repository, granting access to confidential data. The token was rotated and removed from the service.
- 报告: https://hackerone.com/reports/2193815
Case 10: Mozilla — Mozilla FuzzManager API Token Exposed in Git Commit
- 严重度: Critical | CWE: Cleartext Storage of Sensitive Information
- 摘要: An API token for a Mozilla fuzzing service was exposed in a GitHub repository commit. The token provided read-write access to internal fuzzing data. The token was rotated and configured for write-only...
- 报告: https://hackerone.com/reports/2030076