supabase-pentest

Supabase セキュリティ監査オーケストレーター

🔵 推奨：複雑な監査にはプランモードを使用してください

お使いの環境で プランモード がサポートされている場合は、監査を開始する前に有効にすることを強く推奨します。

• オーケストレーションの開始時に EnterPlanMode ツールを使用します
• プランモードにより、複数フェーズにわたる監査をより適切に整理できます
• 実行前にユーザーがアプローチを検証できます
• プランモードを利用できない場合は、そのまま実行に進んでください

プランモードを使用すると、監査プロセスの追跡可能性とユーザーによる制御性が向上します。

🔴 重大：ファイルの段階的な更新が必須です

コンテキストファイルには、最後にまとめてではなく、作業を進めながら書き込む必要があります。

• 発見事項ごとに、直ちに .sb-pentest-context.json に書き込みます
• 各アクションの前後に .sb-pentest-audit.log に記録します
• フェーズやスキルが完了するまでファイルの更新を待ってはいけません
• 監査がクラッシュまたは中断しても、それまでのすべての発見事項が保存済みでなければなりません

これは任意ではありません。段階的な書き込みを怠ることは重大なエラーです。

このスキルは、Supabase ベースのアプリケーションの完全なセキュリティ監査をオーケストレーションし、各フェーズを検証チェックポイントに沿って進めます。

⚠️ 必須：コンテキストファイルの段階的な管理

監査を開始する前に、必ず次の操作を行ってください。

1. .sb-pentest-context.json が存在しない場合は作成します
2. .sb-pentest-audit.log が存在しない場合は作成します
3. .sb-pentest-evidence/ ディレクトリ構造を作成します
4. 対象 URL とタイムスタンプを使ってコンテキストを初期化します

実行中は、作業を進めながら書き込みます。

1. 各アクションの前 → .sb-pentest-audit.log に記録します
2. 発見事項ごとに → 直ちに .sb-pentest-context.json を更新します
3. 各テストの後 → .sb-pentest-evidence/ に証拠を保存します
4. 書き込みをまとめて行わないでください → 各発見事項は、発見した時点で保存する必要があります
5. 各スキルの後に検証します → 次に進む前に、すべてのファイルが更新されていることを確認します

📋 系統的な文書化の要件

すべての追跡ファイルは、監査全体を通じて系統的に管理する必要があります。

必須ファイル（必須）

ファイル	目的	更新頻度
.sb-pentest-context.json	一元化された状態と発見事項	発見事項のたび
.sb-pentest-audit.log	アクションの時系列ログ	各アクションの前後
.sb-pentest-evidence/timeline.md	タイムスタンプ付きの発見事項の記録	重要な発見事項のたび
.sb-pentest-evidence/curl-commands.sh	再現可能なテストコマンド	curl/HTTP リクエストのたび

検証チェックリスト（各フェーズの移行前）

次のフェーズに進む前に、オーケストレーターは以下を必ず検証してください。

• .sb-pentest-context.json に現在のフェーズでのすべての発見事項が含まれている
• .sb-pentest-audit.log に実行したすべてのアクションが記録されている
• .sb-pentest-evidence/XX-phase-name/ に証拠ファイルが存在する
• P0/P1/P2 の発見事項があれば、timeline.md に反映されている
• curl-commands.sh に実行したすべての HTTP リクエストが含まれている

ファイルが不足している、または不完全な場合は、次のフェーズに進んではいけません。

段階的な書き込みパターン

各スキルは必ず次のパターンに従ってください。

1. [LOG] Write START entry to audit.log
2. [CONTEXT] Update context.json with "phase_in_progress"
3. [ACTION] Perform the test/scan
4. [EVIDENCE] Save evidence file IMMEDIATELY
5. [CURL] Append curl command to curl-commands.sh
6. [TIMELINE] Update timeline.md if significant finding
7. [CONTEXT] Update context.json with results
8. [LOG] Write COMPLETE entry to audit.log

失敗からの復旧

スキルまたはフェーズが失敗した場合：

• 失敗時点までに更新されたすべてのファイルは保持されます
• 最後に成功したチェックポイントから監査を再開できます
• コンテキストファイルに、監査が停止した場所が正確に示されます

⚠️ 重要な理由：

• 監査が中断、クラッシュ、またはタイムアウトしても、その時点までの発見事項は保持されます
• 長時間実行されるスキルは、最後にまとめてではなく、進行に応じて段階的に進捗を保存する必要があります
• ユーザーはログファイルを確認することで、リアルタイムに進捗を監視できます

コンテキストファイルを段階的に更新しないことは許容されません。

各スキルは、完了時だけでなく、作業の進行中にこれらのファイルを更新する責任があります。スキルがコンテキストを段階的に更新しない場合、オーケストレーターは各発見事項の直後に更新する必要があります。

このスキルを使用する場面

• Supabase アプリケーションの包括的なセキュリティ評価を実施するとき
• 本番環境へのデプロイ前に、内部セキュリティの自己評価を実施するとき
• セキュリティ上の懸念が提起された後に、アプリケーションを監査するとき
• 定期的なセキュリティレビューを実施するとき

前提条件

• 監査対象アプリケーションの公開 URL
• 対象アプリケーションをテストする権限（所有者であるか、明示的な許可を得ている必要があります）
• 対象 URL にアクセスできるインターネット接続

重要なセキュリティに関する注意事項

⚠️  AUTHORIZATION REQUIRED

Before proceeding, you must confirm:

1. I own this application, OR
2. I have explicit written authorization to perform security testing

Unauthorized security testing may violate laws and terms of service.
Type "I confirm I am authorized to test this application" to proceed.

監査フェーズ

オーケストレーターは、各フェーズの間に確認を挟みながら、以下のフェーズを順番に実行します。

📁 リマインダー：各フェーズの後、必ず以下を確認してください。

• .sb-pentest-context.json がフェーズの結果で更新されている
• .sb-pentest-audit.log に START と COMPLETE のエントリーがある
• エビデンスファイルが .sb-pentest-evidence/XX-phase/ に保存されている
• 重要な調査結果があれば timeline.md に反映されている
• 実行したすべての HTTP リクエストが curl-commands.sh に記録されている

フェーズ 0：初期化

監査環境とエビデンス収集を準備します。

フェーズ開始前のアクション（対応している場合）：

• 環境が対応している場合は、EnterPlanMode を使用します
• これにより、実行前にユーザーが監査方針を確認できます
• Plan Mode が利用できない場合は、そのまま進めます

アクション：

• .sb-pentest-context.json を作成する
• .sb-pentest-audit.log を作成する
• .sb-pentest-evidence/ のディレクトリ構成を作成する
• curl-commands.sh にヘッダーを追加して初期化する
• 監査開始の記録を追加して timeline.md を初期化する
• 初期化を .sb-pentest-audit.log に記録する

呼び出すスキル：

• supabase-evidence（初期化）

次に進む前の確認：

• 追跡用ファイルが 4 つすべて存在する
• エビデンスのディレクトリ構成が完成している
• ユーザーの許可を確認済み

出力： 完全なディレクトリ構成が整い、エビデンスを収集できる状態

フェーズ 1：検出

対象が Supabase を使用しているかを判断し、基本情報を抽出します。

呼び出すスキル：

• supabase-detect

出力： Supabase の使用確認、プロジェクト URL の特定

エビデンスの保存先： .sb-pentest-evidence/01-detection/

フェーズ 2：キーの抽出

クライアント側のコードをスキャンし、公開されている認証情報を検出します。

呼び出すスキル：

• supabase-extract-url
• supabase-extract-anon-key
• supabase-extract-service-key
• supabase-extract-jwt
• supabase-extract-db-string

出力： 検出されたすべての認証情報の一覧と重大度の評価

エビデンスの保存先： .sb-pentest-evidence/02-extraction/

フェーズ 3：API 監査

PostgREST API の公開状況と RLS ポリシーをテストします。

呼び出すスキル：

• supabase-audit-tables-list
• supabase-audit-tables-read
• supabase-audit-rls
• supabase-audit-rpc

出力： アクセス可能なテーブル、データ公開状況の評価、RLS の不備

エビデンスの保存先： .sb-pentest-evidence/03-api-audit/

フェーズ 4：ストレージ監査

ストレージバケットの設定とアクセス状況を確認します。

呼び出すスキル：

• supabase-audit-buckets-list
• supabase-audit-buckets-read
• supabase-audit-buckets-public

出力： バケットの一覧、公開状況、アクセス可能なファイル

エビデンスの保存先： .sb-pentest-evidence/04-storage-audit/

フェーズ 5：認証監査

認証設定と潜在的な弱点を分析します。

呼び出すスキル：

• supabase-audit-auth-config
• supabase-audit-auth-signup
• supabase-audit-auth-users
• supabase-audit-authenticated ← 新機能：IDOR を検出するためのテストユーザーを作成（同意が必要）

出力： 認証プロバイダーの分析、サインアップ制限、ユーザー列挙のリスク、認証済みと匿名の状態の比較

エビデンスの保存先： .sb-pentest-evidence/05-auth-audit/

⚠️ 注意： supabase-audit-authenticated は、テストユーザーを作成する前に明示的な同意を求めます。これは任意ですが、IDOR やユーザー間アクセスの脆弱性を検出するため、強く推奨します。

フェーズ 6：リアルタイム機能と関数の監査

WebSocket チャネルと Edge Functions をテストします。

呼び出すスキル：

• supabase-audit-realtime
• supabase-audit-functions

出力： 公開されているチャネル、関数のエンドポイント、アクセス制御の問題

証拠の保存先： .sb-pentest-evidence/06-realtime-audit/ および .sb-pentest-evidence/07-functions-audit/

フェーズ 7：レポートの生成

すべての調査結果を包括的なレポートにまとめます。

呼び出すスキル：

• supabase-report

出力： エグゼクティブサマリー、調査結果、修正方法を含む完全な Markdown レポート

Plan Mode でのワークフロー

Plan Mode がサポートされている場合、推奨されるワークフローは次のとおりです。

1. User requests audit → Agent uses EnterPlanMode
2. Agent explores target superficially (detect Supabase, extract URL)
3. Agent writes plan to plan file with:
   - Target URL
   - Detected Supabase configuration
   - Proposed phases to execute
   - Estimated scope
4. Agent uses ExitPlanMode → User reviews and approves
5. Agent executes phases with systematic file updates
6. After each phase → Agent confirms files are updated
7. Final report generation

Plan Mode のメリット：

• 実行開始前にユーザーが範囲を調整できます
• テスト対象をより明確に把握できます
• 計画から実行までの監査証跡がより明確になります

使用方法

基本的な全体監査（Plan Mode を使用）

Run a Supabase security audit on https://myapp.example.com

エージェントは次の手順を実行してください。

1. 利用可能な場合は EnterPlanMode を使用する
2. 承認を得るために監査計画を提示する
3. ファイルを体系的に更新しながら実行する

基本的な全体監査（Plan Mode を使用しない）

Run a Supabase security audit on https://myapp.example.com --no-plan

フェーズから再開する

Continue Supabase audit from Phase 3 (API Audit)

特定のフェーズをスキップする

Run Supabase audit on https://myapp.example.com, skip auth audit

コンテキストファイルと証拠（必須）

⚠️ 重要：追跡ファイルの更新と証拠の収集は必須です。

オーケストレーターは次のファイルを作成し、管理します。

ファイル／ディレクトリ	目的
.sb-pentest-context.json	フェーズ間で抽出したデータを保存します
.sb-pentest-audit.log	すべての操作をタイムスタンプ付きで記録します
.sb-pentest-evidence/	専門的な監査のための証拠ディレクトリ

証拠の収集

オーケストレーターは、すべての監査の開始時に証拠ディレクトリを初期化します。

.sb-pentest-evidence/
├── README.md                    # Evidence index
├── curl-commands.sh             # All reproducible curl commands
├── timeline.md                  # Chronological findings
├── 01-detection/                # Detection evidence
├── 02-extraction/               # Key extraction evidence
├── 03-api-audit/                # API audit evidence
│   ├── tables/
│   ├── data-samples/
│   ├── rls-tests/
│   └── rpc-tests/
├── 04-storage-audit/            # Storage audit evidence
│   ├── buckets/
│   └── public-url-tests/
├── 05-auth-audit/               # Auth audit evidence
│   ├── signup-tests/
│   └── enumeration-tests/
├── 06-realtime-audit/           # Realtime audit evidence
├── 07-functions-audit/          # Functions audit evidence
└── screenshots/                 # Optional screenshots

各スキルは、作業中にそれぞれのディレクトリへ証拠を保存する必要があります。

必須の更新ルール

1. 各スキルの実行後、結果を .sb-pentest-context.json に更新する必要があります
2. すべての操作を .sb-pentest-audit.log にタイムスタンプ付きで記録する必要があります
3. ファイルが存在しない場合、監査の開始時に作成する必要があります
4. コンテキストファイルを更新せずにスキルを完了してはなりません

必須のログ形式

.sb-pentest-audit.log の各エントリは、次の形式に従う必要があります。

[YYYY-MM-DD HH:MM:SS] [SKILL_NAME] [STATUS] Message

例：

[2025-01-31 14:00:00] [supabase-detect] [START] Starting Supabase detection
[2025-01-31 14:00:05] [supabase-detect] [SUCCESS] Supabase detected
[2025-01-31 14:00:05] [supabase-detect] [CONTEXT_UPDATED] .sb-pentest-context.json updated

コンテキストファイルの構造

{
  "target_url": "https://myapp.example.com",
  "started_at": "2025-01-31T10:00:00Z",
  "authorization_confirmed": true,
  "supabase": {
    "detected": true,
    "project_url": "https://abc123.supabase.co",
    "anon_key": "eyJ...",
    "service_key_exposed": false
  },
  "phases_completed": ["detection", "extraction"],
  "findings": []
}

レート制限

オーケストレーターは、適応型のレート制限を実装しています。

1. 通常のリクエスト速度で開始します
2. HTTP 429（リクエストが多すぎます）が検出された場合、指数関数的に待機時間を延ばします
3. Supabase のレート制限ヘッダーに従います

出力形式

各フェーズの後に、次の形式で出力します。

═══════════════════════════════════════════════════════════
 PHASE 2 COMPLETE: Key Extraction
═══════════════════════════════════════════════════════════

 Findings:
 ├── ✅ Anon key found (expected)
 ├── ❌ P0: Service role key EXPOSED in main.js:1247
 └── ⚠️  P1: JWT secret pattern detected

 Proceed to Phase 3 (API Audit)? [Y/n]
═══════════════════════════════════════════════════════════

ベストプラクティス

• 影響を最小限に抑えるため、本番環境の稼働時間外に監査を実行します
• 監査証跡のためにコンテキストファイルを保存します
• 修正に着手する前に、セキュリティチームと調査結果を確認します
• 修正を実装した後、再度監査を実行して検証します

よくある問題

❌ 問題： 「Supabase not detected」と表示され、フェーズ 1 で監査が停止する ✅ 解決策： アプリでカスタムドメインを使用している可能性があります。Supabase URL を手動で指定してください。

Run audit with Supabase URL https://myproject.supabase.co

❌ 問題： 監査中にレート制限がかかる ✅ 解決策： オーケストレーターが自動的に調整します。解消しない場合は、5 分待ってから再開してください。

❌ 問題： コンテキストファイルが破損している ✅ 解決策： .sb-pentest-context.json を削除し、監査を再開してください。

関連スキル

• supabase-help — すべてのスキルのクイックリファレンス
• supabase-evidence — 証拠収集の管理
• supabase-report — 既存のコンテキストからレポートを生成
• supabase-report-compare — 前回の監査と比較