---
title: "Web Pentest — 許可を得た Web ペンテスト: 偵察、証拠ベースの攻撃、レポート"
description: "許可を得た Web ペンテスト: 偵察、証拠ベースの攻撃、レポート"
upstream_path: user-guide/skills/optional/security/security-web-pentest.md
upstream_blob: 64ea3c35f5beaf7bc9d50d3c92d55e63ea5b9f6d
sources:
  - https://hermes-agent.nousresearch.com/docs/user-guide/skills/optional/security/security-web-pentest
---

# Web Pentest {#web-pentest}

許可を得た Web ペンテスト: 偵察、証拠ベースの攻撃、レポート。

## skill の情報 {#skill-metadata}

| | |
|---|---|
| 提供元 | オプション — `hermes skills install official/security/web-pentest` で導入します |
| パス | `optional-skills/security/web-pentest` |
| バージョン | `1.0.0` |
| 作者 | Teknium (teknium1), Hermes Agent |
| ライセンス | MIT |
| 対応プラットフォーム | linux, macos |
| タグ | `Security`, `Pentest`, `Web`, `Recon` |

## 参考: SKILL.md 全文 {#reference-full-skillmd}

:::info
以下は、この skill が呼び出されたときに Hermes が読み込む skill 定義の全文です。skill が有効なあいだ、エージェントはこれを指示として受け取ります。
:::

# Web アプリケーションのペネトレーションテスト {#web-application-penetration-testing}

稼働中の Web アプリケーションに対する、フェーズ分けされたペンテストのワークフローです。
Shannon のパイプライン（Keygraph、AGPL — 概念のみで、コードは借用していません）を
参考にしています。3 つのルールを軸に組み立てられています。

1. 攻撃なくしてレポートなし — すべての発見には、再現可能な証拠が必要です。
2. 範囲を限定する — すべての能動的リクエストは、オペレーターが事前に宣言した対象に対して
   行います。範囲外のホストは拒否します。
3. 偽陽性と切り捨てる前にバイパスを尽くす — 「ブロックされた」ペイロードは、バイパスの
   セットを試すまで、無害の証明にはなりません。

---

## ⚠️ ハードガードレール — すべての実施の前に読むこと {#hard-guardrails-read-before-every-engagement}

これらのいずれかに違反すると実施は無効になり、違法となる場合があります。

1. **認可のゲート。** セッションで最初の能動スキャンを行う前に、対象を所有しているか、
   テストする書面の許可があることを、ユーザーと書面で確認**しなければなりません**。承認を
   `engagement/authorization.md` に記録します（テンプレートを参照）。承認がなければ、能動
   スキャンはしません。`curl` で公開ページを読むのは可ですが、ペイロードを送るのは不可です。

2. **範囲の許可リスト。** `engagement/scope.txt` を維持します — 1 行に 1 つのホスト名または
   CIDR です。すべての `nmap`、`curl`、`whatweb`、ブラウザナビゲーション、ペイロードを伴う
   リクエストは、範囲内のエントリに対して行わ**なければなりません**。対象が範囲外へリダイレクト
   したら（別ホストへの 3xx、HTML 内のリンク）、そこで止めて、たどる前にユーザーに確認します。

3. **書面なしに本番システムはなし。** ユーザーが「はい、本番は範囲内で、書面の承認があります」と
   言っていなければ、範囲外と仮定します。既定の対象はステージング、ローカル docker、専用の
   テストインスタンスです。

4. **クラウドのメタデータは既定でオフ。** 実施が SSRF からメタデータへの到達を目標として明示的に
   含み、かつ対象が自分の管理下にあるのでない限り、`169.254.169.254`、`metadata.google.internal`、
   `100.100.100.200`、`[fd00:ec2::254]`、あるいは同等のものをプローブしてはいけません。エージェントの
   ブラウザツールは、自分のインフラの内側からこれらに到達できてしまいます — してはいけません。

5. **破壊的なペイロードには承認が必要。** DROP／DELETE する SQLi ペイロード、ファイル書き込みの
   SSTI、`rm`／`shutdown`／`mkfs` を伴うコマンドインジェクション、単一のテスト行を超えて変更する
   もの → まず尋ねます。`approval.py` のしくみは一部を捕まえますが、それだけに頼ってはいけません。

6. **補助クライアントの漏えいリスク（Hermes 固有）。** この skill は、SQLi／XSS／RCE のペイロード、
   取得した認証情報、JWT トークンでいっぱいのセッションを生み出します。Hermes の圧縮とタイトル生成の
   経路は、履歴を補助クライアント（多くは主モデル）を通して再生します。会話に書き込んだ機微なものは
   すべて、次の圧縮でこの箱の外に出ていく可能性があります。緩和策:
   - 取得したトークン／認証情報は、メッセージに記録する前に**末尾 6 文字**まで伏せます。完全な値は
     `engagement/evidence/` のファイルに置き、会話履歴には決して入れません。
   - 実施が機微なら、そのセッション用に `~/.hermes/config.yaml` で
     `auxiliary.title_generation.enabled: false` を設定します。

7. **自らレート制限する。** 既定では、単一ホストへの能動リクエストの間隔は 200ms です。
   recon-scan.sh スクリプトがこれを強制します。オペレーターの承認なしにこれを回避しないでください。

8. **レポートの位置づけ。** この skill が生み出すのはセキュリティ評価であって、「PASS」では
   ありません。クリーンな実行でも、「範囲 X で時間 T の中、手法 Y を使って、悪用可能な問題は
   見つからなかった」であって、「アプリケーションは安全だ」ではありません。レポートでもその言い回しを
   守ります。

---

## フェーズ 0: 実施のセットアップ {#phase-0-engagement-setup}

スキャンを始める前に、実施ディレクトリと認可の承認を作成します。

```bash
ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"
```

1. **ユーザーに尋ねます（そのままの文言で）:**
   > 「確認します。(a) 対象 URL は [X] であること、(b) このアプリケーションを所有しているか、
   > テストする書面の許可があること、(c) 実施は今から最大 [N] 時間まで行ってよいこと。
   > 進めるなら『authorized』と返信してください。」

2. **明示的な `authorized` の返答を待ちます。** それ以外の答えは、止めることを意味します。

3. `templates/authorization.md` のテンプレートを使って、**認可を** `engagement/authorization.md` に
   **記録します**。次を含めます。
   - 対象の URL と IP
   - 認可の根拠（所有 / $name からの書面による認可）
   - 実施の期間
   - 範囲外の項目（本番、第三者サービスなど）
   - オペレーター名（このセッションを操作するユーザー）

4. **scope.txt を作ります:**
   ```
   localhost
   127.0.0.1
   staging.example.com
   192.168.1.0/24    # internal lab only, with operator OK
   ```

5. 最初の能動リクエストを出す前に `references/scope-enforcement.md` を**読みます** — その文書には、
   出ていくすべてのコマンド／URL に適用するホスト抽出のルールがあります。

---

## フェーズ 1: 事前偵察（コード解析、任意） {#phase-1-pre-recon-code-analysis-optional}

ソースにアクセスできない場合（ブラックボックスの実施）は飛ばします。

アプリケーションのソースへの読み取りアクセスがある場合:

1. **アーキテクチャを把握する** — フレームワーク、ルーティング、ミドルウェアのスタック
2. **シンクを棚卸しする** — すべての `execute(`、`os.system(`、`eval(`、テンプレートの
   レンダリング、ファイルの読み書き、リダイレクト先
3. **認証を把握する** — セッションクッキー vs JWT、OAuth のフロー、パスワードリセット、
   特権エンドポイント
4. **信頼境界を特定する** — 何が認証済みで、何が未認証か、何が `request.*` から来るか
5. 各シンクからリクエストのソースへ**後方テイント**します。適切なサニタイズ（パラメータ化
   クエリ、許可リスト、`shlex.quote`、よく知られたエスケーパー）が見つかったら早期に打ち切ります。

出力: `evidence/pre-recon.md` — アーキテクチャマップ、シンクの棚卸し、疑わしい脆弱なコード経路。

これはオフラインの作業です。対象へのトラフィックはありません。

---

## フェーズ 2: 偵察（ライブ、読み取り専用） {#phase-2-recon-live-read-only}

攻撃面を把握します。すべてのリクエストは公開ページの GET で、まだペイロードはありません。
それでも範囲は限定されます。

1. **範囲を確認する。** すべての対象ホスト名 → IP を解決します。IP が範囲内であることを確認します
   （「DNS が予期しない先を指す」罠を避けます）。

2. **ネットワーク面**（範囲がポートスキャンを許すときのみ）:
   ```bash
   nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET
   ```
   `-T4/-T5` ではなく `-T3`（既定）を使います。よりステルスで、共有環境で IDS/IPS を
   引っかけずに済みます。

3. **技術の指紋採取:**
   ```bash
   whatweb -v $TARGET_URL > evidence/whatweb.txt
   curl -sIk $TARGET_URL > evidence/headers.txt
   ```

4. **エンドポイントの発見:**
   - ブラウザツール（`browser_navigate`、`browser_get_images`、リンクをたどる）でアプリを
     クロールします。
   - `robots.txt`、`sitemap.xml`、`.well-known/*` を調べます。
   - ブラウザツールで開発者ツールのネットワークパネルを使い、XHR/fetch の呼び出しを取得します。

5. **認証面:** ログイン、登録、パスワードリセット、セッションクッキー名、トークンの形式を
   特定します。まだ認証情報は送りません — 観察するだけです。

6. **事前偵察と突き合わせる**（ソースがある場合）。`evidence/pre-recon.md` の各発見について、
   ライブの面で到達可能だと確認できるか印を付けます。

出力: `evidence/recon.md` — エンドポイント、技術、認証モデル、入力ベクトル。

---

## フェーズ 3: 脆弱性の解析 {#phase-3-vulnerability-analysis}

脆弱性クラスごとに 1 つの delegate_task を使います。各エージェントは `evidence/recon.md`
（あれば `evidence/pre-recon.md` も）を読み、`templates/exploitation-queue.json` を使って
`findings/<class>-queue.json` を生成します。

これらの焦点を絞ったサブエージェントを `delegate_task` で使います（可能なところは並列で）。

| クラス | 目標 | 参照 |
|-------|------|------|
| `injection` | SQLi、コマンド、パストラバーサル、SSTI、LFI/RFI、デシリアライズ | `references/vuln-taxonomy.md`（スロットタイプ） |
| `xss` | 反射型、格納型、DOM ベース | `references/vuln-taxonomy.md`（レンダーコンテキスト） |
| `auth` | ログインバイパス、JWT の混同、セッション固定、OAuth の欠陥 | `references/exploitation-techniques.md` |
| `authz` | IDOR、垂直／水平の権限昇格、ビジネスロジック | `references/exploitation-techniques.md` |
| `ssrf` | 内部到達性、メタデータ、プロトコルスマグリング | 明示的に認可されない限りメタデータは飛ばす |
| `infra` | 設定ミス、情報漏えい、既定の認証情報、露出した管理画面 | `references/exploitation-techniques.md` |

各キューエントリは次を持ちます。id、脆弱性クラス、ソース（わかれば file:line）、
エンドポイント、パラメータ、スロットタイプ、疑われる防御、判定
（`identified` / `partial` / `confirmed` / `critical`）、ウィットネスペイロード、
確信度（0-1）、メモ。

解析フェーズはまだ悪意あるペイロードを送りません — それらを準備するだけです。
攻撃フェーズが実際にそれらを撃ちます。

---

## フェーズ 4: 攻撃（証拠ベース、条件付き） {#phase-4-exploitation-proof-based-conditional}

解析キューに実行可能なエントリ（`identified` または `partial`）があるクラスについてのみ、
そのクラスごとにサブエージェントを走らせます。

各候補について:

1. **送信前チェック** — ホストは範囲内か。認証ゲートは満たしたか。破壊的なら
   ペイロードは承認済みか。
2. **ウィットネスペイロードを送る** — 最小限の証明。SQLi: `' AND 1=1--` の次に
   `' AND 1=2--`。XSS: `<svg/onload=console.log("HERMES-PENTEST-XSS")>` のような無害な
   マーカー。格納型 XSS では決して `alert(1)` を使いません — 共有環境で他のユーザーに
   対して発火してしまいます。
3. **ウィットネスが発火することを確認する** — ブラインドインジェクションでは、スリープ
   プローブ（`SLEEP(5)`）を使ってレスポンス時間を計ります。SSRF では、自分が所有する
   テスター管理のコールバックホストを使います（機微な実施では webhook.site のような公開
   サービスは NG — 漏えい経路になります）。
4. **レベルを昇格する:**
   - **L1 特定** — パターンが一致、挙動の変化なし
   - **L2 部分** — シンクに到達したが、防御が働いている
   - **L3 確認** — ペイロードがアプリの挙動を観察可能な形で変えた
   - **L4 重大** — データが抽出された、コードが実行された、アクセスが昇格した
5. **偽陽性と分類する前にバイパスを尽くす。** ブロックする各候補について、そのクラスの
   `references/bypass-techniques.md` にあるバイパスセットを少なくとも試します。セットを
   尽くしたあとにだけ `verdict: false_positive` と書けます。
6. すべての L3/L4 について**証拠を記録する**:
   - 完全なリクエスト（メソッド、URL、ヘッダー、ボディ）
   - レスポンス（ステータス、ヘッダー、該当するボディの抜粋）
   - 再現コマンド（curl のワンライナー）
   - 影響の記述

出力: `findings/exploitation-evidence.md`

**証拠ファイルでは伏せる:**
- 取得した認証情報／トークン → 会話では末尾 6 文字のみ。完全な値は
  `findings/secrets-vault.md`（gitignore 対象）へ。
- 他のユーザーの PII → 伏せます。
- 自分のテスト用認証情報 → そのままで可。

---

## フェーズ 5: レポート {#phase-5-reporting}

`templates/pentest-report.md` を使って最終レポートを生成します。セクション:

1. エグゼクティブサマリー
2. 実施の範囲（`engagement/scope.txt` から）
3. 認可（`engagement/authorization.md` から）
4. 発見（L3/L4 のみ — 証拠必須）。発見ごとに:
   - タイトル、深刻度（CVSS 3.1）、CWE
   - 影響を受けるエンドポイント
   - 証拠（リクエスト＋レスポンスの抜粋）
   - 再現手順
   - 影響
   - 是正策
5. 悪用されなかった候補（L1/L2 と、何がブロックしたかのメモ）
6. 範囲外の観察
7. 手法／使用ツール
8. 制約と、テストしなかったもの

**深刻度の方針:** CVSS は L3/L4 のみ。L1/L2 は「確認待ちの候補」です — 未確認の発見に
CVSS を割り当てません。

---

## いつ止めるか {#when-to-stop}

- ユーザーが認可を取り消したとき。
- 候補の発見が明らかに本番データに影響し、破壊的テストの承認がないとき — 止めて尋ねます。
- 対象が 503/429 の嵐を返し始めたとき — 手を引き、オペレーターと立て直します。
- 契約された範囲の*外*で何かを見つけたとき（例: 無関係なエンドポイントをテスト中に露出した
  顧客データベースを見つけた）。止めて、記録し、オペレーターに報告します。明示的な承認なしに
  そこへ踏み込まないでください — その踏み込みこそが、ペンテストを違法にするものです。

---

## この skill が扱わないこと {#what-this-skill-does-not-cover}

- ポートスキャンを超えたネットワーク層のペンテスト（Metasploit、Cobalt Strike、AD 攻撃、
  ネットワークプロトコルのファジングはなし）。
- リバースエンジニアリング／バイナリ解析（issue #383 を参照）。
- ソースのみの静的解析（issue #382 を参照）。
- 能動的なソーシャルエンジニアリング／フィッシング。
- オペレーターが事前認可していないシステムに対する一切のもの。

実施にこれらのいずれかが必要なら、専門のペンテスターにエスカレーションします。この skill は
専門のペンテストを補完するもので、置き換えるものではありません。

---

## さらに読む {#further-reading}

- `references/scope-enforcement.md` — すべての能動リクエストの範囲を限定する方法
- `references/vuln-taxonomy.md` — スロットタイプ、レンダーコンテキスト、OWASP マップ
- `references/exploitation-techniques.md` — クラスごとのペイロードパターン
- `references/bypass-techniques.md` — よくある WAF／フィルターのバイパス
- `templates/authorization.md` — 実施の認可テンプレート
- `templates/pentest-report.md` — 最終レポートのテンプレート
- `templates/exploitation-queue.json` — クラスごとの発見キューのスキーマ
- `scripts/recon-scan.sh` — レート制限付きの nmap+whatweb+headers ラッパー