关于 testing-for-sensitive-data-exposure
用于评估应用、API、客户端代码、存储和代码仓库中敏感数据意外暴露的安全测试技能。提供授权测试流程,涵盖秘密信息、数据过度暴露、传输安全及脱敏检查。
主要功能
- 01扫描客户端代码中的秘密信息
- 02检查 API 响应是否返回过量数据
- 03评估 TLS 与数据传输安全
- 04检查浏览器存储和 Cookie
- 05搜索仓库中提交的秘密信息
- 06验证数据脱敏与删减
适用场景
- 01测试处理个人或财务数据的 API
- 02查找应用代码中暴露的凭据
- 03检查浏览器缓存中的敏感信息
- 04评估数据保护合规控制
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ mukul975/ anthropic-cybersecurity-skills --skill testing-for-sensitive-data-exposure安装后在 Claude Code 中输入/testing-for-sensitive-data-exposure确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
LICENSEreferences/api-reference.mdscripts/agent.py详细介绍
敏感数据泄露测试
适用场景
- 在经授权的渗透测试中评估数据保护控制措施时
- 评估应用是否符合 GDPR、PCI DSS、HIPAA 或其他数据保护合规要求时
- 识别应用响应中泄露的 API 密钥、凭据、令牌和机密时
- 测试敏感数据在传输中和静态存储时是否得到妥善加密
- 对处理 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 源代码和其他客户端资源,查找暴露的机密。
# Download and search JavaScript files for secrets
curl -s "https://target.example.com/" | \
grep -oP 'src="[^"]*\.js[^"]*"' | \
grep -oP '"[^"]*"' | tr -d '"' | while read js; do
echo "=== Scanning: $js ==="
# Handle relative URLs
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
# Search for common secret patterns
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,})"
# Check source maps for exposed source code
curl -s "https://target.example.com/static/app.js.map" | head -c 500
# Source maps may contain original source code with embedded secrets
# Search HTML source for exposed data
curl -s "https://target.example.com/" | grep -inE \
"(api_key|secret|password|token|private_key|database_url|smtp_password)" | head -20
# Check for exposed .env or configuration files
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 "FOUND: $file ($status)"
fi
done
步骤 2:分析 API 响应是否过度暴露数据
检查 API 端点返回的数据是否超出必要范围。
# Fetch user profile and examine response fields
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users/me" | jq .
# Look for sensitive fields that should not be exposed:
# - 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
# Check list endpoints for excessive data
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users" | jq '.[0] | keys'
# Compare public vs authenticated responses
echo "=== Public ==="
curl -s "https://target.example.com/api/users/1" | jq 'keys'
echo "=== Authenticated ==="
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users/1" | jq 'keys'
# Check error responses for information leakage
curl -s -X POST \
-H "Content-Type: application/json" \
-d '{"invalid": "data"}' \
"https://target.example.com/api/users" | jq .
# Look for: stack traces, database queries, internal paths, version info
# Test for PII in search/autocomplete responses
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/search?q=john" | jq .
# May return full user records instead of just names
步骤 3:测试数据传输安全性
验证敏感数据在传输过程中是否经过加密。
# Check TLS configuration
# Using testssl.sh
./testssl.sh "https://target.example.com"
# Quick TLS checks with curl
curl -s -v "https://target.example.com/" 2>&1 | grep -E "(SSL|TLS|cipher|subject)"
# Check for HTTP (non-HTTPS) endpoints
curl -s -I "http://target.example.com/" | head -5
# Should redirect to HTTPS
# Check for mixed content (HTTP resources on HTTPS pages)
curl -s "https://target.example.com/" | grep -oP "http://[^\"'> ]+" | head -20
# Check if sensitive forms submit over HTTPS
curl -s "https://target.example.com/login" | grep -oP 'action="[^"]*"'
# Form action should use HTTPS
# Check for sensitive data in URL parameters (query string)
# URLs are logged in browser history, server logs, proxy logs, Referer headers
# Look for: /login?username=admin&password=secret
# /api/data?ssn=123-45-6789
# /search?credit_card=4111111111111111
# Check WebSocket encryption
curl -s "https://target.example.com/" | grep -oP "(ws|wss)://[^\"'> ]+"
# ws:// is unencrypted; should only use wss://
步骤 4:检查浏览器存储中的敏感数据
检查本地存储、会话存储、Cookie 和缓存的响应。
# Check what cookies are set and their security attributes
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# In browser DevTools (Application tab):
# 1. Local Storage: Check for stored tokens, PII, credentials
# 2. Session Storage: Check for temporary sensitive data
# 3. IndexedDB: Check for cached application data
# 4. Cache Storage: Check for cached API responses containing PII
# 5. Cookies: Check for sensitive data in cookie values
# Common insecure storage patterns:
# localStorage.setItem('access_token', 'eyJ...'); // XSS can steal
# localStorage.setItem('user', JSON.stringify({email: '...', ssn: '...'}));
# sessionStorage.setItem('credit_card', '4111...');
# Check for autocomplete on sensitive forms
curl -s "https://target.example.com/login" | \
grep -oP '<input[^>]*(password|credit|ssn|card)[^>]*>' | \
grep -v 'autocomplete="off"'
# Password and credit card fields should have autocomplete="off"
# Check Cache-Control headers on sensitive pages
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
# Sensitive pages should have: Cache-Control: no-store
步骤 5:扫描 Git 仓库和源代码中的机密
搜索版本控制中意外提交的机密。
# Check for exposed .git directory
curl -s "https://target.example.com/.git/config"
curl -s "https://target.example.com/.git/HEAD"
# If .git is exposed, use git-dumper to download
# pip install git-dumper
git-dumper https://target.example.com/.git /tmp/target-repo
# Scan downloaded repository with trufflehog
trufflehog filesystem /tmp/target-repo
# Scan with gitleaks
gitleaks detect --source /tmp/target-repo -v
# If GitHub/GitLab repository is available (authorized scope)
trufflehog github --org target-organization --token $GITHUB_TOKEN
gitleaks detect --source https://github.com/org/repo -v
# Common secrets found in repositories:
# - AWS access keys (AKIA...)
# - Database connection strings
# - API keys (Google, Stripe, Twilio, SendGrid)
# - Private SSH keys
# - JWT signing secrets
# - OAuth client secrets
# - SMTP credentials
# Search for secrets in Docker images
# docker save target-image:latest | tar x -C /tmp/docker-layers
# Search each layer for credentials
步骤 6:测试数据掩码和脱敏
验证应用是否正确掩码敏感数据。
# Check if credit card numbers are fully displayed
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/payment-methods" | jq .
# Should show: **** **** **** 4242, not full number
# Check if SSN/national ID is masked
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users/me" | jq '.ssn'
# Should show: ***-**-6789, not full SSN
# Check API responses for password hashes
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users" | jq '.[].password // empty'
# Should return nothing; password hashes should never be in API responses
# Check export/download features for unmasked data
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/users/export?format=csv" | head -5
# CSV exports often contain unmasked PII
# Check logging endpoints for sensitive data
curl -s -H "Authorization: Bearer $TOKEN" \
"https://target.example.com/api/admin/logs" | \
grep -iE "(password|token|secret|credit_card|ssn)" | head -10
# Logs should not contain sensitive data in plaintext
# Test for sensitive data in error messages
curl -s -X POST \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]"}' \
"https://target.example.com/api/register"
# Should not reveal: "User with email [email protected] already exists"
# Should show: "Registration failed" (generic)
核心概念
| 概念 | 描述 |
|---|---|
| 敏感数据泄露 | 意外披露 PII、凭据、财务数据或健康记录 |
| 数据过度暴露 | API 返回的字段超出客户端所需 |
| 机密泄露 | API 密钥、令牌或凭据暴露在客户端代码或日志中 |
| 静态数据 | 存储在数据库、文件或备份中且未加密的敏感数据 |
| 传输中数据 | 在网络上传输且未经 TLS 加密的敏感数据 |
| 数据掩码 | 将敏感数据替换为脱敏值(例如,仅显示信用卡号的后 4 位) |
| PII | 个人身份信息——可用于识别个人的数据 |
| 信息泄露 | 响应中包含过多的错误消息、堆栈跟踪或调试信息 |
工具与系统
| 工具 | 用途 |
|---|---|
| Burp Suite Professional | 分析响应并基于正则表达式扫描敏感数据 |
| trufflehog | 在 Git 仓库、文件系统和云存储中检测机密 |
| gitleaks | 扫描 Git 仓库中的硬编码机密 |
| testssl.sh | 评估 TLS/SSL 配置 |
| git-dumper | 从 Web 服务下载暴露的 .git 目录 |
| SecretFinder | 分析 JavaScript 文件中的暴露 API 密钥和令牌 |
| Retire.js | 检测存在已知漏洞的 JavaScript 库 |
常见场景
场景 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 历史记录中。
输出格式
## Sensitive Data Exposure Assessment Report
**Target**: target.example.com
**Assessment Date**: 2024-01-15
**OWASP Category**: A02:2021 - Cryptographic Failures
### Findings Summary
| Finding | Severity | Data Type |
|---------|----------|-----------|
| API keys in JavaScript source | High | Credentials |
| Password hashes in API response | Critical | Authentication |
| Unmasked SSN in user profile | Critical | PII |
| Credit card number in export | High | Financial |
| .git directory exposed | Critical | Source code + secrets |
| Missing TLS on API endpoint | High | All data in transit |
| Sensitive data in error messages | Medium | Technical info |
### Critical: Exposed Secrets
| Secret Type | Location | Risk |
|-------------|----------|------|
| AWS Access Key (AKIA...) | /static/app.js line 342 | AWS resource access |
| Stripe Secret Key (sk_live_...) | .env (via .git exposure) | Payment processing |
| Database URL with credentials | .git history commit abc123 | Database access |
| JWT Signing Secret | config.json (via .git) | Token forgery |
### Data Over-Exposure in APIs
| Endpoint | Unnecessary Fields Returned |
|----------|-----------------------------|
| 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 |
### Recommendation
1. Remove all hardcoded secrets from client-side code; use backend proxies
2. Rotate all exposed credentials immediately
3. Remove .git directory from production web root
4. Implement response field filtering; return only required fields
5. Mask sensitive data (SSN, credit card) in all API responses
6. Add Cache-Control: no-store to all sensitive endpoints
7. Enable TLS 1.2+ on all endpoints; redirect HTTP to HTTPS
8. Implement secret scanning in CI/CD pipeline (trufflehog/gitleaks)
评论
支持 Markdown