mcpField
T
testing-for-sensitive-data-exposure

testing-for-sensitive-data-exposure

github.com/mukul975安全35.2k361 次安装8 周前更新
代码仓库

关于 testing-for-sensitive-data-exposure

用于评估应用、API、客户端代码、存储和代码仓库中敏感数据意外暴露的安全测试技能。提供授权测试流程,涵盖秘密信息、数据过度暴露、传输安全及脱敏检查。

主要功能

  1. 01扫描客户端代码中的秘密信息
  2. 02检查 API 响应是否返回过量数据
  3. 03评估 TLS 与数据传输安全
  4. 04检查浏览器存储和 Cookie
  5. 05搜索仓库中提交的秘密信息
  6. 06验证数据脱敏与删减

适用场景

  1. 01测试处理个人或财务数据的 API
  2. 02查找应用代码中暴露的凭据
  3. 03检查浏览器缓存中的敏感信息
  4. 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 外,安装时一起下载的参考资料和脚本。

LICENSE
references/
api-reference.md
scripts/
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