security-pen-testing

セキュリティ侵入テスト

攻撃者に先を越される前に脆弱性を見つけるための、実践的な攻撃セキュリティテストスキルです。これはコンプライアンスチェック（senior-secops を参照）でも、セキュリティポリシーの作成（senior-security を参照）でもありません。許可を得たテストを通じて、体系的に脆弱性を発見するためのものです。

---

目次

• 概要
• OWASP Top 10 の体系的な監査
• 静的解析
• 依存関係の脆弱性スキャン
• シークレットスキャン
• API セキュリティテスト
• Web 脆弱性テスト
• インフラストラクチャのセキュリティ
• 侵入テストレポートの作成
• 責任ある脆弱性開示のワークフロー
• ワークフロー
• アンチパターン
• 相互参照

---

概要

このスキルでできること

このスキルでは、攻撃セキュリティテストの手法、チェックリスト、自動化を提供します。システムを積極的に調査して、悪用可能な脆弱性を発見します。Web アプリケーション、API、インフラストラクチャ、サプライチェーンのセキュリティを対象とします。

他のセキュリティスキルとの違い

スキル	焦点	アプローチ
security-pen-testing（このスキル）	脆弱性の発見	攻撃的 — 攻撃者の手法をシミュレート
senior-secops	セキュリティ運用	防御的 — 監視、インシデント対応、SIEM
senior-security	セキュリティポリシー	ガバナンス — ポリシー、フレームワーク、リスク登録簿
skill-security-auditor	CI/CD ゲート	自動化 — マージ前のセキュリティチェック

前提条件

ここで説明するテストはすべて、システム所有者からの書面による許可を前提としています。許可のないテストは、CFAA および世界各地の同等の法律により違法です。開始前に、必ず署名済みの作業範囲またはルール・オブ・エンゲージメントの文書を取得してください。

---

OWASP Top 10 の体系的な監査

脆弱性スキャナーツールを使って、チェックリストを自動生成してください。

# Generate OWASP checklist for a web application
python scripts/vulnerability_scanner.py --target web --scope full

# Quick API-focused scan
python scripts/vulnerability_scanner.py --target api --scope quick --json

クイックリファレンス

#	カテゴリ	主なテスト
A01	アクセス制御の不備	IDOR、垂直権限昇格、CORS、JWT クレームの改ざん、強制ブラウジング
A02	暗号化の失敗	TLS バージョン、パスワードハッシュ、ハードコードされたキー、脆弱な PRNG
A03	インジェクション	SQLi、NoSQLi、コマンドインジェクション、テンプレートインジェクション、XSS
A04	安全でない設計	レート制限、ビジネスロジックの悪用、複数ステップのフローのバイパス
A05	セキュリティ設定のミス	デフォルト認証情報、デバッグモード、セキュリティヘッダー、ディレクトリリスティング
A06	脆弱なコンポーネント	依存関係の監査（npm/pip/go）、EOL チェック、既知の CVE
A07	認証の失敗	ブルートフォース、セッション Cookie のフラグ、セッションの無効化、MFA のバイパス
A08	完全性の失敗	安全でないデシリアライゼーション、SRI チェック、CI/CD パイプラインの完全性
A09	ログ記録の失敗	認証イベントのログ記録、ログ内の機密データ、アラートのしきい値
A10	SSRF	内部 IP へのアクセス、クラウドメタデータエンドポイント、DNS リバインディング

# Audit dependencies
python scripts/dependency_auditor.py --file package.json --severity high
python scripts/dependency_auditor.py --file requirements.txt --json

各カテゴリの詳しいテスト手順、検出すべきコードパターン、修正手順、CVSS スコアリングのガイダンスについては、owasp_top_10_checklist.md を参照してください。

---

静的解析

推奨ツール： CodeQL（プロジェクト固有のパターン向けのカスタムクエリ）、Semgrep（自動修正に対応したルールベースのスキャン）、ESLint セキュリティプラグイン（eslint-plugin-security、eslint-plugin-no-unsanitized）。

検出すべき主なパターン：文字列連結による SQL インジェクション、ハードコードされた JWT シークレット、安全でない YAML/pickle のデシリアライゼーション、セキュリティミドルウェアの欠落（例：Helmet を使用していない Express）。

インジェクションの種類ごとのコードパターンと検出用ペイロードについては、attack_patterns.md を参照してください。

---

依存関係の脆弱性スキャン

エコシステムのコマンド： npm audit、pip audit、govulncheck ./...、bundle audit check

CVE トリアージのワークフロー：

1. 収集 — エコシステムの監査ツールを実行し、検出結果を集約します
2. 重複排除 — 直接依存関係と間接依存関係にまたがって、CVE ID ごとにグループ化します
3. 優先順位付け — 重大度が高く、悪用可能で、到達可能な脆弱性は直ちに修正します
4. 修復 — アップグレード、パッチ適用、または補完的な制御による緩和を行います
5. 検証 — 監査を再実行して修正を確認し、ロックファイルを更新します

python scripts/dependency_auditor.py --file package.json --severity critical --json

---

シークレットスキャン

ツール： TruffleHog（Git 履歴とファイルシステム）、Gitleaks（カスタムルールに対応した正規表現ベース）。

# Scan git history for verified secrets
trufflehog git file://. --only-verified --json

# Scan filesystem
trufflehog filesystem . --json

統合ポイント： コミット前フック（gitleaks、trufflehog）、CI/CD ゲート（trufflesecurity/trufflehog@main を使用する GitHub Actions）。.gitleaks.toml を設定して、カスタムルール（AWS キー、API キー、秘密鍵ヘッダー）とテスト用フィクスチャの許可リストを定義します。

---

API セキュリティテスト

認証のバイパス

• JWT の改ざん： alg を none に変更する、RS256 と HS256 の混同を利用する、クレームを変更する（role: "admin"、exp: 9999999999）
• セッション固定化： 認証後にセッション ID が変更されるか確認します

認可の不備

• IDOR/BOLA： すべてのエンドポイントでリソース ID を変更し、ユーザー間で読み取り、更新、削除をテストします
• BFLA： 一般ユーザーが管理者用エンドポイントを試します（403 が返ることを想定）
• マスアサインメント： 更新リクエストに特権フィールド（role、is_admin）を追加します

レート制限と GraphQL

• レート制限： 認証エンドポイントに連続してリクエストを送り、しきい値を超えた後に 429 が返ることを想定します
• GraphQL： イントロスペクションのテスト（本番環境では無効化されているべきです）、クエリ深度攻撃、レート制限を回避するバッチミューテーション

JWT 改ざん用のペイロード、IDOR のテスト手法、BFLA エンドポイント一覧、GraphQL のイントロスペクション／深度／バッチ攻撃パターン、レート制限の回避手法については、attack_patterns.md を参照してください。

---

Web 脆弱性テスト

脆弱性	主なテスト
XSS	リフレクティッド型（script/img/svg ペイロード）、ストアド型（永続化されるフィールド）、DOM ベース型（innerHTML + location.hash）
CSRF	トークンなしで再送（403 が返ることを想定）、セッションをまたいだトークンの再送、SameSite Cookie 属性の確認
SQL インジェクション	エラーベース（' OR 1=1--）、ユニオンベースの列挙、時間ベースのブラインド（SLEEP(5)）、ブールベースのブラインド
SSRF	内部 IP、クラウドメタデータエンドポイント（AWS/GCP/Azure）、IPv6／16 進数／10 進数エンコーディングによる回避
パストラバーサル	../../../etc/passwd、URL エンコーディング、二重エンコーディングによる回避

XSS フィルターの回避、コンテキスト固有の XSS、データベースエンジンごとの SQL インジェクション、SSRF の回避手法、DOM ベース XSS のソース／シンクの組み合わせなど、テスト用ペイロードの全一覧については、attack_patterns.md を参照してください。

---

インフラストラクチャのセキュリティ

主なチェック項目：

• クラウドストレージ： S3 バケットのパブリックアクセス（aws s3 ls s3://bucket --no-sign-request）、バケットポリシー、ACL
• HTTP セキュリティヘッダー： HSTS、CSP（unsafe-inline／unsafe-eval を含まないこと）、X-Content-Type-Options、X-Frame-Options、Referrer-Policy
• TLS 設定： nmap --script ssl-enum-ciphers -p 443 target.com または testssl.sh — TLS 1.0/1.1、RC4、3DES、輸出グレードの暗号スイートを拒否します
• ポートスキャン： nmap -sV target.com — 危険な開放ポート（FTP/21、Telnet/23、Redis/6379、MongoDB/27017）にフラグを立てます

---

ペンテストレポートの生成

構造化された検出結果から、プロフェッショナルなレポートを生成します：

# Generate markdown report from findings JSON
python scripts/pentest_report_generator.py --findings findings.json --format md --output report.md

# Generate JSON report
python scripts/pentest_report_generator.py --findings findings.json --format json --output report.json

検出結果の JSON 形式

[
  {
    "title": "SQL Injection in Login Endpoint",
    "severity": "critical",
    "cvss_score": 9.8,
    "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
    "category": "A03:2021 - Injection",
    "description": "The /api/login endpoint is vulnerable to SQL injection via the email parameter.",
    "evidence": "Request: POST /api/login {\"email\": \"' OR 1=1--\", \"password\": \"x\"}\nResponse: 200 OK with admin session token",
    "impact": "Full database access, authentication bypass, potential remote code execution",
    "remediation": "Use parameterized queries. Replace string concatenation with prepared statements.",
    "references": ["https://cwe.mitre.org/data/definitions/89.html"]
  }
]

レポートの構成

1. エグゼクティブサマリー：ビジネスへの影響、全体的なリスクレベル、上位 3 件の検出結果
2. スコープ：テスト対象、除外対象、テスト日
3. 方法論：使用したツール、テスト手法（ブラックボックス／グレーボックス／ホワイトボックス）
4. 検出結果の表：CVSS スコアを付け、重大度順に並べます
5. 詳細な検出結果：各項目に説明、証拠、影響、修復方法を記載します
6. 修復優先度マトリクス：各修正の工数と影響
7. 付録：ツールの生出力、ペイロードの全一覧

---

責任ある脆弱性開示のワークフロー

許可を得たテスト中に発見した脆弱性については、責任ある開示が必須です。標準的なタイムラインは、1日目に報告、7日目にフォローアップ、30日目に状況を更新、90日目に公開です。

主な原則： 概念実証の範囲を超えて悪用しないこと、すべての通信を暗号化すること、実際のユーザーデータにアクセスしないこと、タイムスタンプを付けてすべてを記録すること。

完全な開示タイムライン（標準の90日、短縮の30日、延長の120日）、コミュニケーション用テンプレート、法的な考慮事項、バグ報奨金プログラムとの連携、CVE の申請プロセスについては、responsible_disclosure.md を参照してください。

---

ワークフロー

ワークフロー 1：セキュリティの簡易チェック（15 分）

マージ前のレビューや簡易的な健全性チェックに使用します。

# 1. Generate OWASP checklist
python scripts/vulnerability_scanner.py --target web --scope quick

# 2. Scan dependencies
python scripts/dependency_auditor.py --file package.json --severity high

# 3. Check for secrets in recent commits
# (Use gitleaks or trufflehog as described in Secret Scanning section)

# 4. Review HTTP security headers
curl -sI https://target.com | grep -iE "(strict-transport|content-security|x-frame|x-content-type)"

判断基準：重大または高リスクの指摘事項がある場合は、マージをブロックします。

ワークフロー 2：完全な侵入テスト（複数日にわたる評価）

1日目 — 偵察：

1. 攻撃対象領域を把握します：エンドポイント、認証フロー、サードパーティとの連携
2. 自動化された OWASP チェックリストを実行します（全範囲）
3. すべてのマニフェストを対象に依存関係の監査を実行します
4. Git の全履歴を対象にシークレットスキャンを実行します

2日目 — 手動テスト：

1. 認証と認可をテストします（IDOR、BOLA、BFLA）
2. インジェクションの攻撃箇所をテストします（SQLi、XSS、SSRF、コマンドインジェクション）
3. ビジネスロジックの欠陥をテストします
4. API 固有の脆弱性をテストします（GraphQL、レート制限、マスアサインメント）

3日目 — インフラストラクチャと報告：

1. クラウドストレージの権限を確認します
2. TLS の設定とセキュリティヘッダーを検証します
3. 不要なサービスがないかポートスキャンを実行します
4. 指摘事項を構造化された JSON にまとめます
5. 侵入テストレポートを作成します

# Generate final report
python scripts/pentest_report_generator.py --findings findings.json --format md --output pentest-report.md

ワークフロー 3：CI/CD セキュリティゲート

すべての PR でセキュリティチェックを自動実行します。シークレットスキャン（TruffleHog）、依存関係の監査（npm audit、pip audit）、SAST（p/security-audit、p/owasp-top-ten を使用した Semgrep）、ステージング環境でのセキュリティヘッダーのチェックを行います。

ゲートポリシー：重大または高リスクの指摘事項がある場合はマージをブロックします。中リスクの場合は警告します。低リスク／情報提供レベルの場合は記録します。

---

アンチパターン

1. 許可なく本番環境でテストする — 必ず書面で許可を得て、可能な場合はステージング／テスト環境を使用します
2. 低リスクの指摘事項を無視する — 低リスクの指摘事項は積み重なり、連鎖することで重大な悪用経路になる可能性があります
3. 責任ある開示を省略する — 発見した脆弱性はすべて、適切な窓口を通じて報告する必要があります
4. 自動化ツールだけに頼る — ツールではビジネスロジックの欠陥、連鎖したエクスプロイト、新たな攻撃ベクトルを見逃す可能性があります
5. 範囲を定めずにテストする — 範囲の拡大は法的責任につながる可能性があります。対象範囲に含まれるものと含まれないものを記録してください
6. 修正方法を示さずに報告する — すべての指摘事項に、実行可能な修正手順を含める必要があります
7. 証拠を安全でない方法で保管する — 侵入テストの証拠（スクリーンショット、ペイロード、トークン）は機密情報です。暗号化し、アクセスを制限してください
8. 一度だけテストする — セキュリティテストは継続的に行う必要があります。CI/CD に組み込み、定期的な評価を予定してください

---

関連項目

スキル	関連性
senior-secops	防御的なセキュリティ運用 — 監視、インシデント対応、SIEM の設定
senior-security	セキュリティポリシーとガバナンス — フレームワーク、リスク台帳、コンプライアンス
dependency-auditor	サプライチェーンセキュリティの詳細 — SBOM、ライセンスコンプライアンス、推移的なリスク
code-reviewer	コードレビューの実践 — セキュリティレビューチェックリストを含む