Testing For Sensitive Data Exposure

测试敏感数据暴露（Testing for Sensitive Data Exposure）

适用场景

• 在授权渗透测试中评估数据保护控制措施
• 评估应用程序的 GDPR、PCI DSS、HIPAA 或其他数据保护合规性
• 识别应用程序响应中泄露的 API 密钥、凭据、Token 和密钥
• 测试敏感数据在传输和静止时是否已正确加密
• 对处理 PII、金融数据或健康记录的 API 进行安全评估

前置条件

• 授权：书面渗透测试协议（含数据处理范围）
• Burp Suite Professional：用于拦截和分析响应中的敏感数据
• trufflehog：密钥扫描工具（pip install trufflehog）
• gitleaks：Git 仓库密钥扫描器（go install github.com/gitleaks/gitleaks/v8@latest）
• curl/httpie：用于手动端点测试
• 浏览器 DevTools：用于检查本地存储、会话存储和缓存数据
• testssl.sh：TLS 配置测试工具

工作流程

步骤 1：扫描客户端代码中的密钥

在 JavaScript 文件、HTML 源码及其他客户端资源中搜索暴露的密钥。

# 下载并扫描 JavaScript 文件中的密钥
curl -s "https://target.example.com/" | \
  grep -oP 'src="[^"]*\.js[^"]*"' | \
  grep -oP '"[^"]*"' | tr -d '"' | while read js; do
    echo "=== 扫描：$js ==="
    # 处理相对 URL
    if [[ "$js" == /* ]]; then
      curl -s "https://target.example.com$js"
    else
      curl -s "$js"
    fi | grep -inE \
      "(api[_-]?key|apikey|api[_-]?secret|aws[_-]?access|aws[_-]?secret|private[_-]?key|password|secret|token|auth|credential|AKIA[0-9A-Z]{16})" \
      | head -20
done

# 搜索常见密钥模式
curl -s "https://target.example.com/static/app.js" | grep -nP \
  "(AIza[0-9A-Za-z-_]{35}|AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{48}|ghp_[a-zA-Z0-9]{36}|xox[bpsa]-[0-9a-zA-Z-]{10,})"

# 检查 Source Map 是否暴露了源代码
curl -s "https://target.example.com/static/app.js.map" | head -c 500
# Source Map 可能包含含有嵌入密钥的原始源代码

# 在 HTML 源码中搜索暴露的数据
curl -s "https://target.example.com/" | grep -inE \
  "(api_key|secret|password|token|private_key|database_url|smtp_password)" | head -20

# 检查暴露的 .env 或配置文件
for file in .env .env.local .env.production config.json settings.json \
  .aws/credentials .docker/config.json; do
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    "https://target.example.com/$file")
  if [ "$status" == "200" ]; then
    echo "发现：$file ($status)"
  fi
done

步骤 2：分析 API 响应是否存在数据过度暴露

检查 API 端点是否返回了超出必要范围的数据。

# 获取用户资料并检查响应字段
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users/me" | jq .

# 检查不应暴露的敏感字段：
# - password, password_hash, password_salt
# - ssn, social_security_number, national_id
# - credit_card_number, card_cvv, card_expiry
# - api_key, secret_key, access_token, refresh_token
# - internal_id, database_id
# - ip_address, session_id
# - date_of_birth, drivers_license

# 检查列表端点是否返回过多数据
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users" | jq '.[0] | keys'

# 比较公开与已认证响应的差异
echo "=== 公开 ==="
curl -s "https://target.example.com/api/users/1" | jq 'keys'
echo "=== 已认证 ==="
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users/1" | jq 'keys'

# 检查错误响应是否泄露信息
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"invalid": "data"}' \
  "https://target.example.com/api/users" | jq .
# 检查：堆栈跟踪、数据库查询、内部路径、版本信息

# 测试搜索/自动补全响应是否包含 PII
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/search?q=john" | jq .
# 可能返回完整用户记录而非仅返回姓名

步骤 3：测试数据传输安全性

验证敏感数据在传输过程中是否已加密。

# 检查 TLS 配置
# 使用 testssl.sh
./testssl.sh "https://target.example.com"

# 使用 curl 进行快速 TLS 检查
curl -s -v "https://target.example.com/" 2>&1 | grep -E "(SSL|TLS|cipher|subject)"

# 检查 HTTP（非 HTTPS）端点
curl -s -I "http://target.example.com/" | head -5
# 应重定向到 HTTPS

# 检查混合内容（HTTPS 页面中的 HTTP 资源）
curl -s "https://target.example.com/" | grep -oP "http://[^\"'> ]+" | head -20

# 检查敏感表单是否通过 HTTPS 提交
curl -s "https://target.example.com/login" | grep -oP 'action="[^"]*"'
# 表单 action 应使用 HTTPS

# 检查 URL 参数中是否含有敏感数据（查询字符串）
# URL 会被记录在浏览器历史、服务器日志、代理日志、Referer 头部中
# 检查：/login?username=admin&password=secret
# /api/data?ssn=123-45-6789
# /search?credit_card=4111111111111111

# 检查 WebSocket 加密
curl -s "https://target.example.com/" | grep -oP "(ws|wss)://[^\"'> ]+"
# ws:// 未加密；应只使用 wss://

步骤 4：检查浏览器存储中的敏感数据

检查本地存储、会话存储、Cookie 和缓存响应。

# 检查已设置的 Cookie 及其安全属性
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"

# 在浏览器 DevTools（Application 标签）中：
# 1. Local Storage：检查存储的 Token、PII、凭据
# 2. Session Storage：检查临时敏感数据
# 3. IndexedDB：检查缓存的应用程序数据
# 4. Cache Storage：检查包含 PII 的缓存 API 响应
# 5. Cookies：检查 Cookie 值中是否含有敏感数据

# 常见不安全存储模式：
# localStorage.setItem('access_token', 'eyJ...');  // XSS 可窃取
# localStorage.setItem('user', JSON.stringify({email: '...', ssn: '...'}));
# sessionStorage.setItem('credit_card', '4111...');

# 检查敏感表单是否开启了自动补全
curl -s "https://target.example.com/login" | \
  grep -oP '<input[^>]*(password|credit|ssn|card)[^>]*>' | \
  grep -v 'autocomplete="off"'
# 密码和信用卡字段应设置 autocomplete="off"

# 检查敏感页面的 Cache-Control 头部
for page in /account/profile /api/users/me /transactions /billing; do
  echo -n "$page: "
  curl -s -I "https://target.example.com$page" \
    -H "Authorization: Bearer $TOKEN" | \
    grep -i "cache-control" | tr -d '\r'
  echo
done
# 敏感页面应包含：Cache-Control: no-store

步骤 5：扫描 Git 仓库和源代码中的密钥

搜索版本控制中意外提交的密钥。

# 检查是否暴露了 .git 目录
curl -s "https://target.example.com/.git/config"
curl -s "https://target.example.com/.git/HEAD"

# 若 .git 已暴露，使用 git-dumper 下载
# pip install git-dumper
git-dumper https://target.example.com/.git /tmp/target-repo

# 使用 trufflehog 扫描下载的仓库
trufflehog filesystem /tmp/target-repo

# 使用 gitleaks 扫描
gitleaks detect --source /tmp/target-repo -v

# 若 GitHub/GitLab 仓库可访问（授权范围内）
trufflehog github --org target-organization --token $GITHUB_TOKEN
gitleaks detect --source https://github.com/org/repo -v

# 仓库中常见的密钥：
# - AWS 访问密钥（AKIA...）
# - 数据库连接字符串
# - API 密钥（Google、Stripe、Twilio、SendGrid）
# - 私有 SSH 密钥
# - JWT 签名密钥
# - OAuth 客户端密钥
# - SMTP 凭据

# 搜索 Docker 镜像中的密钥
# docker save target-image:latest | tar x -C /tmp/docker-layers
# 搜索每个层中的凭据

步骤 6：测试数据脱敏和屏蔽

验证应用程序中的敏感数据是否已正确脱敏。

# 检查信用卡号是否被完全显示
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/payment-methods" | jq .
# 应显示：**** **** **** 4242，而非完整卡号

# 检查 SSN/国民 ID 是否已脱敏
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users/me" | jq '.ssn'
# 应显示：***-**-6789，而非完整 SSN

# 检查 API 响应是否包含密码哈希
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users" | jq '.[].password // empty'
# 应无返回；密码哈希不应出现在 API 响应中

# 检查导出/下载功能是否包含未脱敏数据
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/users/export?format=csv" | head -5
# CSV 导出通常包含未脱敏的 PII

# 检查日志端点是否包含敏感数据
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.example.com/api/admin/logs" | \
  grep -iE "(password|token|secret|credit_card|ssn)" | head -10
# 日志不应以明文形式包含敏感数据

# 测试错误消息中的敏感数据
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"duplicate@test.com"}' \
  "https://target.example.com/api/register"
# 不应显示："User with email duplicate@test.com already exists"
# 应显示："Registration failed"（通用提示）

核心概念

工具与系统

常见场景

场景 1：JavaScript 包中的 API 密钥

应用程序的 JavaScript 包中包含硬编码的 Google Maps API 密钥和 Stripe 可公开密钥。Stripe 密钥权限过于宽泛，允许攻击者创建扣款。

场景 2：用户 API 返回密码哈希

/api/users 端点返回了包含 bcrypt 密码哈希的完整用户对象。攻击者可提取哈希并尝试离线破解。

场景 3：缓存 API 响应中的 PII

用户资料 API 端点返回了未脱敏的完整 SSN 和信用卡号。该端点未设置 Cache-Control: no-store，导致响应被缓存在浏览器和代理缓存中。

场景 4：含有数据库凭据的 Git 仓库

生产服务器上的 .git 目录可公开访问。攻击者使用 git-dumper 下载仓库历史，发现了在早期提交中提交、后来被"删除"但仍存在于 git 历史中的数据库凭据。

输出格式

## 敏感数据暴露评估报告

**目标**：target.example.com
**评估日期**：2024-01-15
**OWASP 类别**：A02:2021 - 加密失败

### 发现汇总
| 发现 | 严重性 | 数据类型 |
|---------|----------|-----------|
| JavaScript 源码中的 API 密钥 | High | 凭据 |
| API 响应中的密码哈希 | Critical | 认证信息 |
| 用户资料中未脱敏的 SSN | Critical | PII |
| 导出文件中的信用卡号 | High | 金融数据 |
| .git 目录暴露 | Critical | 源码 + 密钥 |
| API 端点缺少 TLS | High | 所有传输中数据 |
| 错误消息中的敏感数据 | Medium | 技术信息 |

### 严重：暴露的密钥
| 密钥类型 | 位置 | 风险 |
|-------------|----------|------|
| AWS 访问密钥（AKIA...） | /static/app.js 第 342 行 | AWS 资源访问 |
| Stripe 密钥（sk_live_...） | .env（通过 .git 暴露） | 支付处理 |
| 含凭据的数据库 URL | .git 历史提交 abc123 | 数据库访问 |
| JWT 签名密钥 | config.json（通过 .git） | Token 伪造 |

### API 数据过度暴露
| 端点 | 不必要返回的字段 |
|----------|-----------------------------|
| GET /api/users | password_hash, internal_id, created_ip |
| GET /api/users/{id} | ssn, credit_card_full, date_of_birth |
| GET /api/orders | customer_phone, customer_address |

### 建议
1. 从客户端代码中移除所有硬编码密钥；使用后端代理
2. 立即轮换所有已暴露的凭据
3. 从生产 Web 根目录中移除 .git 目录
4. 实施响应字段过滤；仅返回必要字段
5. 在所有 API 响应中脱敏敏感数据（SSN、信用卡）
6. 为所有敏感端点添加 Cache-Control: no-store
7. 在所有端点启用 TLS 1.2+；将 HTTP 重定向到 HTTPS
8. 在 CI/CD 流水线中实施密钥扫描（trufflehog/gitleaks）