Part 0：はじめに

title: “本書の概要と読み方” part: “Part 0” chapter: “0-1”

本書の概要

本書『実務で使えるペネトレーションテスト大全：Web・API・モバイル・クラウドの統合セキュリティ実践』は、ペネトレーションテスト（以下、Pentest）を体系的に学び、実務で再現可能なレベルのスキル獲得を目的とした技術書である。

単なるツール解説や個別の脆弱性カタログではなく、攻撃モデル・リスク評価・Web / API / モバイル / クラウド / インフラといった複数レイヤを一貫したストーリーで解説し、演習とテンプレートを通じて「明日から使える」形に落とし込むことを重視する。

本書は、ITDO 内部研修や顧客向けトレーニングとしての利用を前提としつつ、個人の自己学習にも耐えうる構成とする。

本書のゴール

本書を通じて、読者は次の状態に到達することを目標とする。

• Web / API / モバイル / クラウドを対象とした Pentest の全体像を説明できる
• 代表的な攻撃手法と脆弱性カテゴリ（OWASP ASVS、OWASP Top 10、API Top 10 など）の位置づけを理解している
• Burp Suite、MobSF、Frida、Prowler など代表的なツールを用いて、基本的な診断・検証が実施できる
• Juice Shop、DVWA、crAPI などの演習環境を用いて、PoC 作成からレポート作成までを一連の流れとして体験できる
• 付属のチェックリスト・テンプレートを活用し、実務で再利用可能なアウトプットを作成できる

想定読者

本書は、以下のような読者を想定している。

• Web エンジニア／フルスタックエンジニアで、攻撃側の視点を体系的に学びたい方
• インフラ／クラウドエンジニアで、自身の設計・運用の弱点を理解したい方
• セキュリティ担当者として、診断ベンダとのコミュニケーションや内製診断の品質を高めたい方
• Pentest スキルを習得し、実務で通用するレベルを目指す初中級エンジニア
• 社内研修を設計・実施する教育担当者

前提知識

本書は入門書ではなく、「基礎を一通り学んだ技術者が、実務レベルの Pentest スキルに到達するための導線」を意図している。そのため、以下の前提知識を推奨する。

• Linux の基本操作（シェル操作、パッケージ管理、サービス起動とログ確認など）
• HTTP および Web アプリケーションの基本構造
• ネットワークの基礎（TCP/IP、DNS、TLS の概要レベル）
• 何らかのプログラミング言語による開発経験（言語は問わない）

ただし、必要な部分については各 Part で適宜復習を兼ねた解説を行うため、事前に深い専門知識を要求するものではない。

12 週間カリキュラムとの関係

本書は、ITDO 内部で設計した「12 週間 Pentest カリキュラム」をベースとしている。カリキュラムでは以下のような流れで学習を行う。

• 1〜2 週目：攻撃モデルとリスク評価、OWASP ASVS / Top 10 などの基礎理論
• 3〜5 週目：Web / API を対象とした脆弱性理解と Burp Suite を用いた実践
• 6〜8 週目：OAuth2 / OIDC、モバイルアプリ、クライアントサイドの攻撃手法
• 9〜10 週目：クラウド（主に AWS）および Linux / コンテナを含むインフラ
• 11〜12 週目：総合演習（スコーピングからレポート作成まで）

本書の Part 構成は、この 12 週間カリキュラムを書籍形式に再構成したものであり、研修と書籍を併用することも、書籍のみで独学することもできるよう設計している。

各 Part の位置づけ

本書は、次の Part から構成される。

• Part 0：はじめに
  本書の目的、想定読者、前提知識、学習上の注意点、環境構築方針を示す。
• Part 1：基礎理論
  攻撃モデル、リスク評価、OWASP ASVS / OWASP Web Security Testing Guide（WSTG）、OWASP Top 10 / API Top 10 など、後続の Part を支える理論的基盤を整理する。
• Part 2：Web セキュリティ基盤
  HTTP、Cookie、CORS、セッション管理、JWT、OAuth2 / OIDC など、Web アプリケーションを安全に設計・診断するための技術基盤を扱う。
• Part 3：Web Pentest 実践
  Burp Suite を中心とした Web Pentest の実践手順と、典型的な脆弱性検証の流れを示す。
• Part 4：API Pentest と認証／権限管理
  BOLA や Mass Assignment、Rate Limit など API 特有のリスク、および OAuth2 / OIDC や RBAC / ABAC を含む認可の検証を扱う。
• Part 5：モバイル Pentest
  MobSF、Frida、objection を用いたモバイルアプリの静的／動的解析と、データ保護・認証・暗号化に関する検証を扱う。
• Part 6：クラウド・インフラ Pentest
  AWS を中心としたクラウド構成の評価、SSRF から IMDS への攻撃パス、Linux 権限昇格、コンテナ環境のセキュリティを扱う。
• Part 7：総合演習
  スコーピングから情報収集、脆弱性発見、悪用、権限昇格、レポート作成までを 1 週間程度のカリキュラムとして統合する。

読者は、Part 0 から順に読み進めることを推奨するが、特定の分野（例：API やクラウド）に関心がある場合は、該当 Part から読み始めてもよい。その場合でも、必要に応じて Part 1〜2 の該当節を参照し、理論的背景を補いながら進めると理解が深まる。

学習の進め方

本書を最大限活用するために、以下の読み方を推奨する。

• 章ごとに「理論 → 演習 → まとめ」のサイクルで学習する
• 付属のチェックリストと照らし合わせながら、自身の理解の抜け漏れを確認する
• 可能な限り、自身で検証環境を構築し、書籍の手順をトレースする
• 演習で得られた結果を、付属のレポートテンプレートに記録しておく

単に読んで理解したつもりになるのではなく、「実際に手を動かして再現できるか」「第三者に説明できるか」を意識することで、実務に耐えうるスキルセットを獲得できる。

本章のポイント

• 本書は脆弱性カタログではなく、攻撃モデルから各レイヤの実践までを一貫したストーリーで学ぶことを目的とする。
• 学習の中心は「再現可能なアウトプット」であり、演習とテンプレートを通じて PoC とレポート作成まで到達する。
• 12 週間カリキュラムをベースにしつつ、読者は関心のある Part から着手してもよい（必要に応じて Part 1〜2 を参照する）。

Pentest と脆弱性診断の違い

title: “Pentest と脆弱性診断の違い” part: “Part 0” chapter: “0-2”

Pentest と脆弱性診断の違い

本書の中心テーマであるペネトレーションテスト（Pentest）と、一般的な「脆弱性診断」は、しばしば混同されるが、目的・スコープ・成果物のいずれも異なる。ここでは、本書全体の前提として両者の違いを整理する。

本章のゴール

• 前提：セキュリティ評価（脆弱性診断や Pentest）の用語を一度は聞いたことがある。
• 到達目標：脆弱性診断と Pentest の違いを「目的／スコープ／成果物」の観点で説明し、本書の狙い（攻撃チェーンと実務成果物に接続すること）を理解できる。
• 対応演習：自身の想定ケース（演習または業務）について、目的・対象範囲・成果物を 1 枚に整理し、どちらの評価が適切かを言語化する。

目的の違い

• 脆弱性診断
  主な目的は、対象システムに存在する脆弱性を網羅的に洗い出し、そのリスクと対策を提示することである。網羅性と再現性を重視し、チェックリストや標準ガイドライン（例：OWASP ASVS、OWASP Web Security Testing Guide（WSTG））に基づいた評価を行う。

• ペネトレーションテスト（Pentest）
  主な目的は、実際の攻撃者視点で攻撃シナリオを構築し、「どこまで侵害できるか」「どの経路で重要資産に到達しうるか」を検証することである。個々の脆弱性の有無だけでなく、複数の脆弱性や設定ミスを組み合わせた攻撃チェーンを重視する。

スコープの違い

• 脆弱性診断
  一般に、Web アプリケーションや API といった特定コンポーネント単位でスコープが定義される。入力値検証、認証／認可、セッション管理、エラーハンドリングなど、各カテゴリごとにテストケースが整理される。

• Pentest
  ネットワーク境界、クラウド構成、認証基盤、エンドポイント、開発・運用プロセスなど、より広範なスコープを対象としうる。内部／外部、ブラックボックス／ホワイトボックスなど、前提に応じてテスト設計が変化する。

成果物の違い

• 脆弱性診断レポート
  個々の脆弱性ごとに、概要・影響度・再現手順・対策案を記載する形式が一般的である。経営層向けサマリと技術担当者向け詳細が併記されることが多い。

• Pentest レポート
  攻撃シナリオ全体を重視し、「どのような前提条件で侵入が成立しうるか」「どの経路で重要情報にアクセス可能であったか」をストーリーとして記述する。個別の脆弱性の説明に加え、Kill Chain や MITRE ATT&CK などのフレームワークに基づき、攻撃ライフサイクルの観点から評価する。

本書における立ち位置

本書は、いわゆる「脆弱性診断」の手法も網羅しつつ、最終的には Pentest の視点でシステム全体を評価できるようになることを目標とする。そのために以下を重視する。

• OWASP ASVS / WSTG に基づく体系的な診断観点の整理
• Kill Chain、MITRE ATT&CK、STRIDE などによる攻撃モデルの理解
• 個々の脆弱性を起点とした、攻撃チェーンの構築方法
• 実務で利用可能なレポートテンプレートとサンプル

以降の Part では、診断と Pentest の両方の観点を意識しながら、具体的な技術・ツール・演習を解説していく。

本章のポイント

• 脆弱性診断は「脆弱性の網羅的な洗い出しと対策提示」を主目的とし、Pentest は「攻撃シナリオ（攻撃チェーン）でどこまで侵害できるか」を検証する。
• 両者は目的だけでなく、スコープ（対象範囲の広さ）と成果物（一覧中心か、シナリオ中心か）も異なる。
• 本書は診断観点の体系性（ASVS 等）を土台にしつつ、最終的に Pentest の成果物へ接続する構成を取る。

法的注意点と倫理

title: “法的注意点と倫理” part: “Part 0” chapter: “0-3”

法的注意点と倫理

Pentest は、本質的に「攻撃と同質の行為」を伴う。そのため、法的・倫理的な前提を理解し、許可された範囲内でのみ実施することが必須である。本章では、日本国内を主な前提としつつ、一般的な注意事項を整理する。

本章のゴール

• 前提：Pentest が攻撃と同等の手法を扱うことを理解している。
• 到達目標：許可の要否、安全な演習環境、スコープ合意、情報管理といった統制事項を説明し、違法・不適切な実施を回避できる。
• 対応演習：演習に入る前に、対象範囲・禁止事項・連絡経路・データ取り扱いをチェックリスト化し、演習は exercises/ 配下の環境に限定する。

許可なき攻撃は犯罪である

情報セキュリティに関連する主な法令として、次のようなものが挙げられる。

• 不正アクセス行為の禁止等に関する法律（いわゆる不正アクセス禁止法）
• 刑法（電子計算機使用詐欺、業務妨害など）
• 個人情報保護法　など

これらの法令に照らすと、以下の行為は明確に違法となる。

• システム管理者や所有者から明示的な許可を得ずに、第三者のシステムに対して攻撃行為（スキャン／侵入／情報窃取など）を行うこと
• 公開 Web サイトやクラウド環境に対して、脆弱性有無を確認する目的であっても、無断で負荷を与えたり設定変更を試みること

本書の内容は、あくまで「正当に許可された範囲内で、セキュリティ向上を目的とした評価を実施する」ことを前提とする。

安全な演習環境の利用

学習目的であっても、インターネット上の第三者システムを対象に攻撃行為を行うべきではない。安全のため、次の原則を徹底する。

• 演習は、ローカル PC 上または組織内で許可されたネットワーク内の環境のみで行う
• AWS などのクラウド環境を利用する場合は、自身が契約し管理するアカウント内の検証用リソースに限定する
• 本番環境や顧客環境に対するテストは、必ず書面または同等の正式な手続きによる許可を得る

本書に登場する Juice Shop、DVWA、crAPI などの演習用アプリケーションは、攻撃練習を目的として意図的に脆弱な設計となっている。これらを利用し、第三者に迷惑のかからない範囲で学習を進める。

スコーピングと合意

実務として Pentest を実施する場合、以下の事項について事前に合意し、文書化しておくことが望ましい。

• テスト対象のシステム範囲（ドメイン、IP レンジ、クラウドアカウントなど）
• 実施してよい攻撃手法（例：DoS 相当の負荷試験を含めるか否か）
• 実施期間、実施時間帯
• インシデントが発生した場合の連絡経路
• 取得した情報の扱いと保存期間

これらの前提が曖昧なままテストを開始すると、業務への影響や法的リスクを招きかねない。本書の総合演習 Part では、スコーピングのサンプルと、合意事項のテンプレートを提示する。

倫理的な責任

Pentest のスキルは、攻撃にも防御にも利用しうる。実務に携わる技術者として、次の点を倫理的責任として認識しておく必要がある。

• 発見した脆弱性を、適切なルートで報告し、是正に導くこと
• 自身の知識やツールを、第三者の利益を不当に害する目的で使用しないこと
• 組織としてのルール（情報管理、守秘義務、ログ取得など）を遵守すること

本書は、読者が「攻撃者と同等の視点」を持ちつつも、その知識を防御や改善のために活用するプロフェッショナルとして振る舞うことを前提とする。

本章のポイント

• 許可なき攻撃は犯罪であり、学習目的であっても第三者システムを対象にしてはならない。
• 演習は「許可された環境」に限定し、クラウドを使う場合も検証用アカウント・検証用リソースに限定する。
• 実務の Pentest では、スコープ・禁止事項・期間・連絡経路・データ取り扱いを事前合意し、文書化することが重要である。

学習用環境構築ガイド

title: “学習用環境構築ガイド” part: “Part 0” chapter: “0-4”

学習用環境構築ガイド

本章では、本書の演習を安全かつ効率的に実施するために必要となる環境構成の方針を示す。詳細な手順や設定ファイルは exercises/ および scripts/ 配下にまとめ、ここでは「何を用意し、どのような前提で使うか」を整理する。

本章のゴール

• 前提：Docker（または Podman）によるコンテナ実行の概念を理解している。
• 到達目標：本書の演習が要求する環境要件、exercises/ と scripts/ の役割、ネットワーク分離方針を説明し、安全に演習を開始できる。
• 対応演習：付録「演習環境クイックスタート」 を参照し、まず 1 つの演習環境を起動して疎通確認を行い、演習用ネットワーク分離の前提を満たしていることを確認する（詳細は exercises/ 配下の README.md を参照）。

想定プラットフォーム

本書の演習は、主に次のプラットフォームを前提とする。

• デスクトップ OS
  • Linux（推奨）
  • macOS
  • Windows（WSL2 利用を推奨）
• 必要なリソースの目安
  • メモリ：16GB 以上を推奨（複数コンテナ・エミュレータ併用を想定）
  • ディスク：50GB 以上の空き容量（Docker イメージ、モバイル向けツール等を含む）

上記以外の環境でも動作しうるが、Docker や仮想化周りの制約により追加調整が必要となる場合がある。

共通で利用するツール

全 Part に共通して、次のツールを利用する。

• Git
  • 本リポジトリの取得・更新、演習用コードのバージョン管理に利用する。
• Docker / Docker Compose または Podman / podman-compose
  • 脆弱な Web アプリケーションや API、DB などの演習環境をコンテナとして起動する。
• Burp Suite
  • Web / API Pentest の中心となるプロキシツール。Community Edition でも学習可能な範囲に絞る。

これらは本書執筆時点（2024 年〜2025 年前後）の安定版を前提とするが、マイナーバージョン差異による影響は最小となるよう配慮する。

Part ごとの追加要件（概要）

各 Part の演習に必要な追加要件の概要は次のとおりである。

• Part 2〜4（Web / Burp / API）
  • Web ブラウザ（Firefox または Chromium 系）
  • Burp Suite のブラウザプロキシ設定と CA 証明書インポート
• Part 5（モバイル）
  • Android エミュレータまたは実機（開発者モード有効）
  • MobSF、Frida、objection（演習では Docker 化や専用スクリプトを利用予定）
  • モバイル端末の HTTP(S) プロキシ設定と証明書インポート
• Part 6（クラウド・インフラ）
  • ローカルの疑似クラウド／インフラ環境（Docker Compose による複数コンテナ構成）
  • Prowler / ScoutSuite 等の評価ツール（必要に応じてコンテナ化）
• Part 7（総合演習）
  • 上記すべての環境を統合し、1 週間カリキュラムとして利用する。

本書では、可能な限り Docker コンテナとしてツール群を提供し、ホスト環境へのインストール依存を減らす方針を取る。

exercises ディレクトリの役割

exercises/ 配下には、演習環境向けの構成ファイルと補足ドキュメントを配置する。

• exercises/juice-shop/
  • OWASP Juice Shop 等を用いた Web 脆弱性演習用環境。
• exercises/dvwa/
  • 基礎的な Web 脆弱性（XSS、SQL インジェクション等）を確認するための DVWA 環境。
• exercises/crapi/
  • API セキュリティ演習用の crAPI を用いた環境。

執筆時点で exercises/ に用意している演習環境は上記 3 つ（Juice Shop / DVWA / crAPI）である。
Part 5〜7 向けの演習は、今後 exercises/ 配下に追加する前提とし、提供状況は exercises/README.md を参照する。

各ディレクトリには、少なくとも次のファイルを用意する。

• docker-compose.yml または同等のコンテナ起動定義
• README.md（起動方法、想定シナリオ、注意事項）

本書の本文では具体的な Docker コマンドの詳細までは踏み込まず、exercises/ の README を参照する形で記述する。

scripts ディレクトリの役割

scripts/ 配下には、演習環境の起動・停止や初期セットアップを補助するスクリプトを配置する。

• 例：scripts/setup_exercises.sh
  • 必要な Docker イメージの取得、環境変数のサンプル生成、簡易チェックなど。
• 例：scripts/cleanup_exercises.sh
  • 演習終了後のコンテナ停止や不要なボリューム削除など。

実運用にあたっては、組織のポリシー（プロキシ設定、社内レジストリ利用など）に合わせてスクリプトを調整することを前提とする。

安全な演習のためのネットワーク方針

演習環境は、誤ってインターネット上の第三者システムに影響を与えないよう、次の方針に従う。

• 脆弱なアプリケーションは、原則としてローカルネットワークまたは VPN 内の検証用セグメントでのみ公開する。
• クラウド関連の演習は、原則としてローカルの疑似環境のみ を対象とし、実際の商用クラウドアカウントに対する攻撃的操作は行わない。
• モバイル端末は、演習用 Wi-Fi セグメントに接続し、業務ネットワークと分離する。

これらの方針は Part 0「法的注意点と倫理」で示した原則と一貫しており、本書に付属する演習用スクリプト類もこの前提に基づいて設計する。

本章のポイント

• 本章は詳細手順ではなく「演習に必要な要件と前提」を整理し、具体作業は exercises/ と scripts/ のドキュメントへ委譲する。
• 演習環境は複数 Part で共用するため、まず共通ツール（Git / Docker / Burp Suite）とリソース目安を満たす。
• 安全性のため、演習はネットワーク分離を前提とし、クラウド関連は原則としてローカル疑似環境で扱う。

Part 1：基礎理論

title: “基礎理論 Part の狙い” part: “Part 1” chapter: “1-0”

Part 1：基礎理論の位置づけ

Part 1 では、後続の Web / API / モバイル / クラウド Pentest を支える「共通言語」として、攻撃モデル・リスク評価・標準ガイドラインを整理する。

ツールや個別のテクニックだけを学んでも、「どの脆弱性から優先して対処すべきか」「経営層にどのように説明するか」が分からなければ、実務での価値は限定的になる。

本 Part の目的は、以降の Part で扱う個別技術を、「どのような攻撃ライフサイクルの中で、どのリスクを低減するために使うのか」という文脈に結びつけることである。

本 Part で扱う主なトピックは次のとおりである。

• 攻撃モデル：
  • Cyber Kill Chain
  • MITRE ATT&CK
  • STRIDE
• リスク評価：
  • DREAD を中心とした定性的評価
• 標準ガイドライン：
  • OWASP ASVS / OWASP Web Security Testing Guide（WSTG）
  • OWASP Top 10（Web）
  • OWASP API Security Top 10

これらは、診断設計・報告・改善計画のすべてのフェーズで繰り返し利用する概念であるため、ここで一度まとめて把握しておく。

ただし、本書の射程は「代表的なモデルと標準の概要と役割」を押さえることにあり、各モデル・標準の全項目や詳細仕様を網羅的に解説することは目的としない。

すべてを一度に暗記する必要はなく、「どのようなモデルや標準が存在するか」をざっくり掴み、必要に応じて公式ドキュメントや原文を参照できる状態を目指す。

本 Part を読む前提

以下のような前提知識を想定する。

• HTTP や Web アプリケーションのごく基本的な構造を知っている
• 何らかのプログラミング言語で簡単な Web アプリを触ったことがある

上記が完全でなくても、用語の意味は本文中で補足するため、読み進めながら補完していけばよい。

本 Part を読み終えるとできること

Part 1 を読み終えた読者は、少なくとも次のような状態に到達することを目標とする。

• Kill Chain / ATT&CK / STRIDE といった代表的な攻撃モデルの役割と違いを説明できる
• DREAD や OWASP Top 10 などの概念を「リスクを整理するための道具」として認識できる
• 後続の Part で登場する用語（ASVS、API Top 10 など）を見ても、大まかな位置づけを思い出せる

本 Part で学ぶ内容は、詳細を暗記するよりも、「こうした枠組みがあり、後で振り返る拠り所になる」と理解しておくことが重要である。

関連資料

• 用語集

本章のポイント

• Part 1 は、後続の各 Part に共通する「攻撃モデル」「リスク評価」「標準ガイドライン」を整理する。
• 本 Part の狙いは暗記ではなく、診断設計・実施・報告の各フェーズで枠組みを適切に使い分けられる状態を作ることである。
• 詳細は必要に応じて公式ドキュメントを参照し、本書では役割と位置づけの理解を重視する。

攻撃モデル：Kill Chain / MITRE ATT&CK / STRIDE

title: “攻撃モデル：Kill Chain / MITRE ATT&CK / STRIDE” part: “Part 1” chapter: “1-1”

攻撃モデルの基礎

Pentest は本質的に、「攻撃者の視点でシステムを評価する活動」である。そのため、攻撃者がどのようなライフサイクルで行動し、どのポイントで検知・阻止しうるかを理解する必要がある。本章では代表的な攻撃モデルとして、Cyber Kill Chain、MITRE ATT&CK、STRIDE を取り上げる。

本章のゴール

• 前提：Part 0 で Pentest の目的とスコープの考え方を把握している。
• 到達目標：Cyber Kill Chain / MITRE ATT&CK / STRIDE の役割と違いを説明し、「設計→実施→報告」の各フェーズでどのモデルを使うか判断できる。
• 対応演習：任意のシステム（演習環境でもよい）を対象に、攻撃チェーンを Kill Chain で分解し、該当する ATT&CK 戦術・技術と STRIDE の脅威カテゴリを対応付けて整理する。

Cyber Kill Chain

Cyber Kill Chain は Lockheed Martin によって提唱された攻撃ライフサイクルモデルであり、典型的には次の 7 段階に分解される。

1. 偵察（Reconnaissance）
   対象組織やシステムに関する情報収集。ドメイン名、公開サービス、メールアドレス、OS 情報などを収集する。
2. 武器化（Weaponization）
   取得した情報を元に、マルウェアやエクスプロイトコード、フィッシングメールなどの攻撃手段を準備する。
3. 配送（Delivery）
   メール、Web サイト、USB メディアなどを経由して、攻撃手段を標的に届ける。
4. 悪用（Exploitation）
   ソフトウェアの脆弱性や設定ミスを突き、ペイロードを実行する。
5. インストール（Installation）
   バックドアやエージェントを設置し、継続的なアクセスを確立する。
6. コマンド & コントロール（Command and Control）
   攻撃者が外部から侵入した端末を遠隔操作できるようにする。
7. 目的達成（Actions on Objectives）
   情報窃取、ランサムウェアの展開、破壊活動など、本来の攻撃目的を達成する。

Kill Chain の利点は、「どのフェーズで検知・遮断できたか」を可視化し、防御施策をマッピングしやすい点にある。Pentest 報告書においても、「本評価で再現した攻撃が Kill Chain のどの段階に相当するか」を示すことで、セキュリティ担当者が対策を検討しやすくなる。

MITRE ATT&CK

MITRE ATT&CK は、実際の攻撃事例に基づいて整理された「戦術（Tactic）と技術（Technique）のナレッジベース」である。バージョンにより更新されるが、エンタープライズ向けマトリクスには、初期アクセス、実行、持続化、権限昇格、認証情報アクセス、横展開など、多数の戦術が定義されている。

Kill Chain が攻撃の大まかなライフサイクルを示すのに対し、ATT&CK は「各フェーズで具体的にどのような手法が用いられるか」を詳細に分類している点が特徴である。たとえば次のようなマッピングが行える。

• 戦術：Initial Access
  • 技術：Phishing、Valid Accounts、Exploit Public-Facing Application など
• 戦術：Privilege Escalation
  • 技術：Exploitation for Privilege Escalation、Sudo and Sudo Caching など

Pentest の観点では、次のような用途で活用できる。

• テストシナリオ設計時に、「どの戦術・技術を再現対象とするか」を明確にする
• 評価報告時に、「本評価で再現した手法は ATT&CK の Txxxx に相当する」と示し、チーム間で共通言語化する
• 検知チーム（SOC/CSIRT）と連携し、「どの戦術・技術について検知ルールが存在するか」を確認する

STRIDE

STRIDE は Microsoft が提唱した、脅威モデリングのための分類フレームワークであり、主に設計段階でのリスク洗い出しに利用される。各文字は次の脅威カテゴリを表す。

• S：Spoofing（なりすまし）
• T：Tampering（改ざん）
• R：Repudiation（否認）
• I：Information Disclosure（情報漏えい）
• D：Denial of Service（サービス妨害）
• E：Elevation of Privilege（権限昇格）

STRIDE の有用性は、「どのコンポーネントに対して、どの種類の脅威を検討したか」を体系的に記録できる点にある。たとえば Web アプリケーションのログイン機能を例に取ると、図1-1 のような簡易 DFD を前提に、次のような観点が得られる。

図1-1 は、ユーザ入力、ブラウザ↔Web アプリケーション間の HTTP(S)、Web アプリケーション↔データベース間のクエリ／更新、外部 API / IdP 連携といった主要なデータフローだけに絞って示したものである。STRIDE では、この各コンポーネントとデータフローを起点に、想定すべき脅威カテゴリを系統立てて洗い出す。

図1-1: 典型的な Web アプリケーションの簡易 DFD

flowchart LR
    U[ユーザ] --> B[ブラウザ]
    B --> W[Web アプリケーション]
    W --> DB[(データベース)]
    W --> API[外部 API / IdP]

    U ---|"入力・操作"| B
    B ---|"HTTP(S) リクエスト"| W
    W ---|"クエリ・更新"| DB
    W ---|"API コール / 認証連携"| API

• Spoofing：他者になりすましてログイン可能か（認証バイパス、パスワードリスト攻撃など）
• Tampering：パラメータを改ざんして不正な操作が可能か
• Repudiation：不正操作を実施したユーザを、後から特定できるか（ログの完全性）
• Information Disclosure：認証エラー時に過度な情報を開示していないか
• Denial of Service：ログイン試行によりサービスが停止しうるか
• Elevation of Privilege：一般ユーザから管理者権限へ昇格可能か

Pentest の前段として STRIDE による脅威モデリングを行うことで、「テスト観点の抜け漏れ」を減らし、診断結果と設計上の想定を結びつけやすくなる。

3 つのモデルの使い分け

本書では、おおむね次のような使い分けを行う。

• 設計段階・スコーピング：STRIDE により脅威を洗い出し、テスト対象の優先度を決める
• テスト設計・実施：MITRE ATT&CK を参照しつつ、実際に再現する戦術・技術を選定する
• 結果整理・報告：Cyber Kill Chain ベースで攻撃チェーンを可視化し、防御施策や検知ポイントを整理する

これらのモデルを単独で使うのではなく、「設計 → 実施 → 報告」というライフサイクル全体で組み合わせることが、実務での有効な活用方法である。

本章のポイント

• Cyber Kill Chain は攻撃ライフサイクルを段階で整理し、防御施策や報告のマッピングに利用できる。
• MITRE ATT&CK は戦術（Tactic）と技術（Technique）の分類により、テストシナリオ設計と共通言語化に有用である。
• STRIDE は設計・スコーピングにおける脅威洗い出しに適し、本書ではこれらをフェーズに応じて組み合わせて扱う。

リスク評価：DREAD を中心に

title: “リスク評価：DREAD を中心に” part: “Part 1” chapter: “1-2”

リスク評価の考え方

Pentest の成果物は単なる「脆弱性の一覧」ではなく、「どのリスクをどの順序で対処すべきか」を示したものでなければならない。そのためには、発見した脆弱性の重大度を一貫した基準で評価する必要がある。本章では、代表的なモデルである DREAD を軸に、リスク評価の考え方を整理する。

本章のゴール

• 前提：脆弱性の影響が技術要因だけで決まらない（ビジネス要因も含む）ことを理解している。
• 到達目標：DREAD の各観点と限界を説明し、技術的重大度・ビジネスインパクト・発生可能性を分けて優先度を決定する考え方を整理できる。
• 対応演習：任意の発見事項を 1 件選び、DREAD での評価と、組織の重要度区分（存在する場合）へのマッピング方針を記録する。

DREAD モデルの概要

DREAD は、かつて Microsoft で利用されていたリスク評価モデルであり、次の 5 つの観点からスコアリングを行う。

• D：Damage Potential（被害規模）
  脆弱性が悪用された場合、どの程度の被害が発生しうるか。
• R：Reproducibility（再現性）
  攻撃の再現がどの程度容易か。特別な前提や環境を必要としないか。
• E：Exploitability（攻撃容易性）
  実際に悪用するための技術的難易度や必要なツールの特殊性。
• A：Affected Users（影響を受けるユーザ数）
  影響範囲が限定的か、サービス全体に及ぶか。
• D：Discoverability（発見可能性）
  攻撃者が脆弱性に気付く可能性。自動スキャンで容易に発見されるか、詳細なリバースエンジニアリングを要するか。

各項目を 1〜5 点などのスコアで評価し、合計点や平均点をもとに重要度をランク付けする。評価基準は組織ごとに調整することが多い。

DREAD の活用例

Web アプリケーションの SQL インジェクションを例に、簡易的なスコアリングを行うと次のようになる。

• Damage Potential：5（データベース全体の窃取・改ざんが可能）
• Reproducibility：4（特定のパラメータに対して再現容易）
• Exploitability：4（一般的なツールで容易に悪用可能）
• Affected Users：5（全ユーザのデータが影響を受ける可能性）
• Discoverability：3（自動スキャンで発見される可能性が高い）

合計 21 点／最大 25 点といった形で評価し、「Critical」とランク付けする、といった運用が想定される。

DREAD の限界と補完

DREAD は分かりやすい一方で、次のような課題も指摘されている。

• 評価者によるブレが大きくなりやすい（特に Discoverability など）
• 同じスコアでも、実際のビジネスインパクトが大きく異なる可能性がある
• 現行の多くの組織では CVSS など別のスキームが利用されている

そのため本書では、DREAD を「リスク思考を整理するための教育的モデル」として扱い、実務では組織の標準（例：CVSS v3.1、独自の重要度区分）と組み合わせることを推奨する。具体的には、DREAD によって脆弱性ごとの特徴や直感的な危険度を整理した上で、最終的な重要度ランクや修正期限の決定は、既存の社内基準や CVSS スコアリングといった枠組みにマッピングすることを想定している。

実務でのリスク評価プロセス

実務的には、次のようなプロセスでリスク評価を行うと整理しやすい。

1. 技術的な重大度の評価
   DREAD や CVSS に基づき、「技術的にどれだけ危険か」を定量・定性評価する。
2. ビジネスインパクトの評価
   対象システムが扱う情報の重要度、法令・契約上の義務、ブランド影響などを踏まえ、ビジネス側の影響度を評価する。
3. 発生可能性の評価
   公開範囲、利用ユーザ、攻撃者のモチベーションなどから、「実際に悪用される蓋然性」を検討する。
4. 優先度の決定
   上記を踏まえて、修正優先度（例：Critical/High/Medium/Low）と修正期限の目安を決定する。

Pentest レポートでは、「技術的な重大度」と「ビジネスインパクト」を分けて記載すると、関係者間の合意形成がしやすくなる。

本章のポイント

• DREAD は 5 つの観点（Damage/Reproducibility/Exploitability/Affected Users/Discoverability）で、脆弱性の重要度を整理するモデルである。
• DREAD は評価者によるブレが出やすいため、教育的なモデルとして位置づけ、実務では CVSS 等の組織標準と組み合わせて運用する。
• 実務の優先度決定では、技術的な重大度に加え、ビジネスインパクトと発生可能性を分けて評価することが有効である。

OWASP ASVS と Web Security Testing Guide（WSTG）

title: “OWASP ASVS と Web Security Testing Guide（WSTG）” part: “Part 1” chapter: “1-3”

OWASP ASVS / WSTG の活用

OWASP（Open Worldwide Application Security Project）は、Web アプリケーションセキュリティに関する多数のガイドラインやツールを公開している。その中でも、Pentest 実務で特に重要なのが OWASP ASVS（Application Security Verification Standard）と OWASP Web Security Testing Guide（WSTG）である。

本章では、これらをどのようにテスト設計・実施・報告に活用するかを整理する。記載内容は 2024 年時点の公開情報を前提とする。

本章のゴール

• 前提：Web アプリケーションに対して「何を確認するか」と「どう検証するか」を分けて考える必要性を理解している。
• 到達目標：ASVS（要求仕様）と WSTG（テスト手順書）の役割分担を説明し、スコーピング・テスト設計・報告における利用方法を整理できる。
• 対応演習：任意の機能（例：ログイン、パスワードリセット等）を 1 つ選び、ASVS の該当観点と WSTG の手順を参照して、テスト観点の骨子を作成する。

OWASP ASVS の概要

OWASP ASVS は、Web アプリケーションのセキュリティ要件を体系化した標準であり、以下のような特徴を持つ。

• 認証、セッション管理、アクセス制御、入力検証、暗号化など、複数のカテゴリに分割された詳細な要件一覧
• セキュリティレベル（例：Level 1〜3）ごとに要求強度が定義されている
• 開発・設計・テスト・レビューの各フェーズで利用可能なチェックリスト

Pentest の観点では、ASVS を次のように利用できる。

• スコーピング時に、「どのカテゴリの要件をどのレベルまで評価するか」を合意するベースラインとして用いる
• テスト設計時に、ASVS の項目をテストケースにマッピングし、抜け漏れを防ぐ
• 報告時に、「ASVS のどの項目に対して不適合が見つかったか」を明示する

OWASP Web Security Testing Guide（WSTG）

WSTG は、Web アプリケーションに対するテスト技法を体系的にまとめたガイドラインであり、次のような構成を持つ。

• 情報収集（Information Gathering）
• 認証テスト（Authentication Testing）
• セッション管理テスト（Session Management Testing）
• アクセス制御テスト（Authorization Testing）
• 入力検証テスト（Input Validation Testing）
• エラーハンドリング、暗号化、ビジネスロジックなど

各テスト項目について、目的、テスト手順、確認ポイントの例が記載されており、Pentest 実務者にとっては「標準的なテストのやり方」の参考となる。

ASVS と WSTG の役割分担

ASVS と WSTG は、次のように捉えると理解しやすい。

• ASVS：
  「何を満たしているべきか」を定義した 要求仕様・チェックリスト
• WSTG：
  「どのように検証するか」を示した テスト手順書

たとえば「パスワードリセット機能」の場合、ASVS では次のような要件が定義されているとする。

• リセットトークンは十分な長さのランダム値であること
• トークンは一度のみ使用可能であること
• 有効期限が短時間に設定されていること

一方 WSTG では、「実際にリセットフローをたどり、トークンの推測可能性や再利用可否を確認するためのテスト手順」が記載される。

Pentest 実務では、ASVS を基準として「何を確認すべきか」を洗い出し、具体的な実施時には WSTG の手順を参考にしながらテストケースを作成するとよい。

本書での扱い

本書では、ASVS および WSTG の全項目を逐一解説するのではなく、次の観点に重点を置く。

• 代表的なカテゴリ（認証、セッション管理、アクセス制御、入力検証など）の要点整理
• ASVS の項目を、Web / API / モバイル / クラウドそれぞれの文脈にマッピングする方法
• 実際のテスト計画書やチェックリストに、ASVS をどう組み込むかの具体例

詳細な原文については、OWASP 公式サイトから最新版を参照することを推奨する。

標準ガイドラインを使う意義

ASVS や WSTG に代表される標準ガイドラインを活用することで、次のメリットが得られる。

• 個人の経験や属人的な観点に依存せず、網羅的なテストが実施しやすくなる
• ベンダやチーム間で「どのレベルまで検証したのか」を定量的に比較しやすくなる
• コンプライアンスや監査の観点から、客観的な根拠を提示しやすくなる

本書に付属するチェックリストやテンプレートも、できる限り ASVS / WSTG との対応関係を意識して設計する。

本章のポイント

• ASVS は「何を満たしているべきか」を定義する要求仕様（チェックリスト）であり、スコーピング・テスト設計・報告の基準にできる。
• WSTG は「どのように検証するか」を示すテスト手順書であり、具体的な検証手順の参照として有用である。
• 実務では Top 10 を入口にしつつ、ASVS と WSTG を組み合わせてテストの抜け漏れと説明可能性を高める。

OWASP Top 10 と API Security Top 10

title: “OWASP Top 10 と API Security Top 10” part: “Part 1” chapter: “1-4”

OWASP Top 10（Web / API）の位置づけ

OWASP Top 10 は、Web アプリケーションや API における代表的なリスクを整理したドキュメントであり、セキュリティ教育やリスクコミュニケーションの事実上の標準として広く利用されている。本章では、2021 年版 Web Top 10 および 2023 年版 API Security Top 10 を前提に、その役割と実務での活用方法を整理する。

本章のゴール

• 前提：代表的な脆弱性カテゴリ（アクセス制御不備、インジェクション等）の概要を理解している。
• 到達目標：Top 10 を「分類軸・コミュニケーションの入口」として使う位置づけを説明し、ASVS / WSTG と組み合わせたテスト設計の考え方を整理できる。
• 対応演習：任意の発見事項（または想定リスク）を Top 10 のカテゴリに分類し、どの標準（ASVS / WSTG 等）で詳細化・検証するかをメモとして残す。

OWASP Top 10 2021（Web）

Top 10 2021 では、以前のバージョンからカテゴリの統廃合や名称変更が行われているが、ここでは代表的なリスクの例を挙げる。

• A01:2021 - Broken Access Control（アクセス制御の不備）
• A02:2021 - Cryptographic Failures（暗号の失敗）
• A03:2021 - Injection（インジェクション）
• A04:2021 - Insecure Design（不適切な設計）
• A05:2021 - Security Misconfiguration（セキュリティ設定不備）
• A07:2021 - Identification and Authentication Failures（認証・識別の不備） など

重要なのは、各項目が「技術的な脆弱性」に留まらず、設計上の問題や運用ミスも含む広い概念として整理されている点である。Pentest の観点では、Top 10 をそのままチェックリストとして使うというより、「どのカテゴリに属する問題をどの程度検証したか」を報告書で示すための分類軸として利用するのが有効である。

OWASP API Security Top 10 2023

API に特化したリスクとして、OWASP API Security Top 10 が公開されている。2023 年版では、次のようなカテゴリが含まれる。

• API1:2023 - Broken Object Level Authorization（オブジェクトレベルのアクセス制御不備、BOLA）
• API2:2023 - Broken Authentication（認証の不備）
• API3:2023 - Broken Object Property Level Authorization（プロパティレベルのアクセス制御不備）
• API4:2023 - Unrestricted Resource Consumption（リソース消費の制限不備）
• API5:2023 - Broken Function Level Authorization（機能レベルのアクセス制御不備）
• API6:2023 - Unrestricted Access to Sensitive Business Flows（センシティブなビジネスフローへの制限不備）
• API7:2023 - Server Side Request Forgery（SSRF）
• API8:2023 - Security Misconfiguration
• API9:2023 - Improper Inventory Management
• API10:2023 - Unsafe Consumption of APIs

Web 向け Top 10 と比較すると、オブジェクトレベル／プロパティレベル／機能レベルといった「権限管理の粒度」に強くフォーカスしている点が特徴である。特に BOLA（旧 Broken Object Level Authorization）は、ID 連番や予測可能なリソース識別子を通じて他者データにアクセス可能となる典型的な API リスクとして、実務でも頻出である。

Top 10 の使い方

Top 10 は「完全なチェックリスト」ではなく、「代表的なリスクカテゴリの優先順位付きリスト」として理解すべきである。実務では次のような用途が考えられる。

• 非技術者（経営層、ビジネス側担当者）に対して、どのようなリスクを主に対象としているかを説明する
• Pentest レポートのサマリ部分で、「本評価では Top 10 のうち A01/A03/API1/API4 等を重点的に評価した」といった形でカバレッジを示す
• 教育コンテンツやトレーニング計画を立てる際に、「まずは Top 10 を一通り理解する」ロードマップとして利用する

一方で、Top 10 に記載されていないリスク（例：特定クラウドサービス固有の設定ミス、組織固有のビジネスロジック欠陥など）も多数存在するため、Top 10 だけをもって「十分な診断が行われた」と判断することは適切ではない。

ASVS / WSTG との関係

Part 1 で前述した ASVS / WSTG と Top 10 は、次のような関係にある。

• Top 10：
  リスクカテゴリを概観する「サマリ／教育用リスト」
• ASVS：
  各カテゴリをより詳細な要件レベルに分解した「要求仕様」
• WSTG：
  各要件を実際に検証するための「テスト手順」

Pentest 実務では、Top 10 を入り口として大まかなリスクイメージを共有しつつ、具体的なテスト設計や改善施策の検討には ASVS / WSTG といった詳細な標準を参照する、という組み合わせが現実的である。

本章のポイント

• OWASP Top 10 は「代表的なリスクカテゴリの優先順位付きリスト」であり、完全なチェックリストではない。
• Web Top 10 と API Top 10 は焦点が異なり、API 側は特に認可（オブジェクト/プロパティ/機能レベル）やインベントリ管理に重きを置く。
• Top 10 を分類軸・コミュニケーションの入口として用い、詳細なテスト設計は ASVS / WSTG と組み合わせるのが現実的である。

Part 2：Web セキュリティ基盤

title: “Web セキュリティ基盤 Part の狙い” part: “Part 2” chapter: “2-0”

Part 2：Web セキュリティ基盤の位置づけ

Part 2 では、Web / API Pentest の土台となる技術要素を整理する。HTTP、Cookie、CORS、SameSite、セッション管理、CSRF、JWT、OAuth2 / OIDC といったテーマは、後続の Part 3（Web Pentest 実践）および Part 4（API Pentest）で繰り返し登場するため、本 Part で一度体系的に押さえておく。

本 Part の目的は、個別の脆弱性名称を暗記することではなく、「なぜその脆弱性が成立するのか」をプロトコルレベルで理解することである。これにより、教科書に載っていない実装パターンに対しても、自ら攻撃面を推定し、テスト設計を行えるようになる。

本 Part で扱う主なトピックは、以下のとおりである。

• HTTP / Cookie / CORS / SameSite
• セッション管理と CSRF
• JWT / OAuth2 / OIDC
• Web アプリケーションの典型的な脆弱性

本 Part のゴール

Part 2 を読み終えた時点で、読者は次の状態に到達することを目標とする。

• HTTP リクエスト／レスポンス、ヘッダ、ステートレス性の意味を説明できる
• Cookie の仕組み（Domain/Path/Secure/HttpOnly/SameSite など）と、CORS の基本動作を理解している
• セッション管理と CSRF の関係、および代表的な対策パターンを説明できる
• JWT の構造、署名検証の意味、典型的な誤実装パターンを理解している
• OAuth2 / OIDC の基本ロールと代表的フロー（特に Authorization Code + PKCE）を概説できる
• XSS、SQL インジェクション、CSRF、認可不備など、典型的な Web 脆弱性について「なぜ成立するか」をプロトコル視点で説明できる

以降の Part では、ここで整理した基盤を前提として具体的なテスト手順やツール操作に踏み込む。

本 Part を読む前提と対応演習

前提知識としては、以下を想定する。

• HTTP のごく基本的な仕組み（リクエストとレスポンス、ステータスコードなど）
• クッキーやセッションといった Web の基本用語を一度は聞いたことがある

これらが曖昧な場合でも、本 Part の中で図や例とともに改めて整理するため、読み進めながら理解を深めていけばよい。

演習としては、exercises/juice-shop/ や exercises/dvwa/ 配下に用意する Web アプリケーションを用い、Burp Suite を通じて HTTP トラフィックを観察しながら、本 Part で整理した概念を確認することを想定する。

関連資料

• 付録「演習環境クイックスタート」
• Web Pentest チェックリスト（原案）
• OAuth2 / OIDC テスト項目表（原案）
• 用語集

本章のポイント

• Part 2 は、Web / API Pentest の土台となるプロトコル・認証要素（HTTP、Cookie、セッション、JWT、OAuth2 / OIDC 等）を整理する。
• 本 Part の狙いは脆弱性名の暗記ではなく、「なぜ成立するか」をプロトコルレベルで説明できる状態を作ることである。
• 後続の Part では Burp Suite 等で実リクエストを観察するため、本 Part で基礎概念を一度体系化しておく。

HTTP / Cookie / CORS / SameSite

title: “HTTP / Cookie / CORS / SameSite” part: “Part 2” chapter: “2-1”

HTTP / Cookie / CORS / SameSite

本章では、Web セキュリティの前提となる HTTP プロトコルと、状態管理・同一生成元制御に関わる要素（Cookie、CORS、SameSite）を整理する。特にブラウザベースの攻撃（XSS、CSRF など）を理解するためには、ブラウザがどのタイミングでどの情報を送出するかを正確に把握しておく必要がある。

本章のゴール

• 前提：HTTP リクエスト／レスポンス、ステータスコードの概念を理解している（Part 2 の前提範囲）。
• 到達目標：Cookie の主要属性（Domain / Path / Secure / HttpOnly / SameSite）と、CORS の基本動作・典型的な誤設定を説明できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ を Burp Suite 経由で操作し、Set-Cookie と CORS 関連ヘッダの挙動を観察する（起動手順は 付録「演習環境クイックスタート」 を参照）。

HTTP の基本

HTTP は原則としてステートレスなプロトコルであり、各リクエストは独立して処理される。代表的な要素は次のとおりである。

• メソッド：GET、POST、PUT、DELETE など
• ステータスコード：200 台（成功）、300 台（リダイレクト）、400 台（クライアントエラー）、500 台（サーバエラー）など
• ヘッダ：Host、User-Agent、Cookie、Authorization、Content-Type など

図2-1 は、1 回の HTTP の往復（リクエスト／レスポンス）と、Cookie によるセッション維持の最小構成を示す。Cookie 属性や CORS ヘッダも、まずは「リクエストに含まれるもの」「レスポンスで設定されるもの」を分けて整理すると理解しやすい。

図2-1: HTTP リクエスト／レスポンス概要図

sequenceDiagram
    participant B as Browser
    participant S as Web Server

    B->>S: GET /example HTTP/1.1\nHost: example.com\nCookie: session=...
    S-->>B: 200 OK\nSet-Cookie: session=...

    note over B,S: ステートレスなリクエスト／レスポンスのやり取り<br/>Cookie によりセッション状態を維持

Pentest では、HTTP トラフィックを正確に読み解くことが、脆弱性の有無を判断する基礎となる。Burp Suite 等のプロキシツールを用いて、「どのヘッダがどのように変更されると挙動が変わるか」を意識的に観察することが重要である。

Cookie と属性

HTTP がステートレスであるため、Web アプリケーションはログイン状態などの「セッション情報」を Cookie などの仕組みで維持する。Cookie はレスポンスヘッダ Set-Cookie でクライアントに送信され、以降のリクエストで Cookie ヘッダとして自動送信される。

主な属性は以下のとおりである。

• Domain：Cookie が送信されるドメイン範囲（例：example.com、.example.com）
• Path：Cookie が送信されるパス範囲（例：/app/）
• Secure：HTTPS 通信時にのみ Cookie を送信する
• HttpOnly：JavaScript（document.cookie）から参照できないようにする
• SameSite：クロスサイト環境での Cookie 送信を制御する（後述）

セッション ID を格納する Cookie については、少なくとも Secure と HttpOnly の付与が推奨される。これらが適切に設定されていない場合、平文通信や XSS を通じて Cookie が窃取されるリスクが高まる。

CORS（Cross-Origin Resource Sharing）

ブラウザは、同一生成元ポリシー（Same-Origin Policy, SOP）により、異なるオリジン間のリソースアクセスを制限している。ここでのオリジンは、「スキーム（http/https）」「ホスト」「ポート」の組み合わせで定義される。

CORS は、この制限を緩和するための仕組みであり、サーバ側が適切なレスポンスヘッダを返すことで、特定のオリジンからのクロスオリジンアクセスを許可できる。

代表的なヘッダは以下のとおりである。

• Access-Control-Allow-Origin
  許可するオリジン。* を安易に指定すると、意図せぬ情報共有が発生する恐れがある。
• Access-Control-Allow-Credentials
  Cookie を含む認証情報付きリクエストを許可するかどうか。
• Access-Control-Allow-Methods / Access-Control-Allow-Headers
  プリフライトリクエストに対する許可メソッドやヘッダの指定。

CORS 誤設定は、単体で致命的な脆弱性になる場合もあれば、他の脆弱性（XSS 等）と組み合わせて情報漏えいを引き起こす「増幅要因」となる場合もある。Pentest では、以下の点を重点的に確認する。

• 認証が必要な API に対して、Access-Control-Allow-Origin: * が設定されていないか
• 任意のオリジンを反射して許可していないか（例：Origin ヘッダをそのまま返す実装）
• Access-Control-Allow-Credentials: true と * の組み合わせなど、仕様上禁止されている設定を行っていないか

SameSite 属性

SameSite 属性は、ブラウザがクロスサイト環境で Cookie を送信するかどうかを制御する仕組みであり、主に CSRF リスクの低減に用いられる。代表的な値は次の 3 つである（ブラウザ実装により挙動の差異あり）。

• Strict
  完全な同一サイトナビゲーション以外では Cookie を送信しない。UX への影響が大きいため、限定的な用途で用いられる。
• Lax
  トップレベルナビゲーションの GET など、一部のケースに限り Cookie を送信する。近年、多くのブラウザでデフォルト相当の挙動となっている。
• None
  クロスサイト環境でも Cookie を送信する。この場合は Secure 属性の付与が必須となる。

CSRF は「ユーザが意図しないリクエストに対して、ブラウザが Cookie を自動送信する」ことを悪用する攻撃であるため、SameSite を適切に設定することでリスクを一定程度低減できる。ただし、ブラウザ間での実装差異や、サブドメイン間の挙動など考慮すべき点も多く、SameSite の設定だけで完全な対策とはならない点に留意が必要である。

SameSite の詳細な挙動と CSRF との関係については、次節の「セッション管理と CSRF」で改めて整理する。

本章のポイント

• HTTP はステートレスであり、リクエスト／レスポンス、メソッド、ステータスコード、ヘッダを正確に読み解くことが Pentest の基礎である。
• Cookie はセッション維持の要であり、Secure / HttpOnly / SameSite などの属性設定が脆弱性の成立条件に直結する。
• CORS と SameSite はいずれもブラウザの制約と密接に関係し、誤設定は情報漏えい・CSRF などのリスクを増幅しうる。

セッション管理と CSRF

title: “セッション管理と CSRF” part: “Part 2” chapter: “2-2”

セッション管理と CSRF

本章では、Web アプリケーションの認証状態を維持する仕組みとしての「セッション管理」と、その前提を悪用する攻撃である CSRF（Cross-Site Request Forgery）について整理する。

本章のゴール

• 前提：Cookie ベースの認証とセッションの概念、および SameSite の概要（前章）を把握している。
• 到達目標：セッション管理の確認観点（再発行、無効化、タイムアウト等）と、CSRF の成立条件・代表的対策を説明できる。
• 対応演習：exercises/dvwa/ などで、ログイン前後の Cookie 変化や、CSRF 対策（トークン、SameSite 等）の有無を確認する（起動手順は 付録「演習環境クイックスタート」 を参照）。

セッション管理の基本

多くの Web アプリケーションでは、ユーザ認証後に「セッション ID」を発行し、それを Cookie などを通じてクライアントと共有することでログイン状態を維持する。

代表的な設計パターンは以下のとおりである。

• サーバサイドセッション
  セッション ID はランダムなトークンとしてのみ意味を持ち、実際のユーザ情報や状態はサーバ側ストア（メモリ、RDB、KVS など）に保持する。
• トークンベースセッション
  JWT 等のトークンにユーザ情報や権限情報を埋め込み、サーバ側は署名検証のみによって状態を確認する（詳細は次節）。

Pentest の観点では、セッション管理において次の点を確認する。

• セッション ID の推測困難性（十分な長さとエントロピーがあるか）
• ログイン直後や権限昇格時にセッション ID の再発行（Session Fixation 対策）が行われているか
• ログアウト時やパスワード変更時に、古いセッションが無効化されるか
• タイムアウト（アイドルタイムアウト／絶対タイムアウト）が適切に設定されているか

セッションハイジャックと Session Fixation

セッション管理に関連する代表的な攻撃として、次のようなものがある。

• セッションハイジャック
  XSS やネットワーク盗聴などにより、正当なユーザのセッション ID を窃取し、そのままなりすます攻撃。
• Session Fixation
  攻撃者が事前に発行させたセッション ID を被害者に利用させ、ログイン後も同じ ID が継続使用されることで、攻撃者がそのセッションを引き継ぐ攻撃。

Session Fixation 対策としては、「ログイン成功時に必ず新しいセッション ID を発行する」ことが基本となる。Pentest では、ログイン前後で Cookie の値が適切に変化するかを確認する。

CSRF の成立条件

CSRF は、認証済みユーザに成り代わって、攻撃者が意図するリクエストをターゲットサイトに送信させる攻撃である。典型的な成立条件は次のとおりである。

• ユーザがターゲットサイトにログインし、ブラウザが有効なセッション Cookie を保持している
• ターゲットサイトが、状態変更を伴うリクエスト（例：振込、メールアドレス変更）を Cookie ベースの認証のみに依存している
• 攻撃者が用意したページ（悪意のあるフォームや JavaScript）を被害者が閲覧し、その結果としてターゲットサイトに対してリクエストが送信される

ブラウザは、送信先が同じドメインである限り自動的に Cookie を付与するため、被害者の意思と無関係に「正当なセッションを伴うリクエスト」が実行されることになる。

代表的な CSRF 対策

実務で利用される代表的な CSRF 対策は次のとおりである。

• 同一サイトトークン（Synchronizer Token Pattern）
  HTML フォームや JavaScript から送信されるリクエストに、サーバ側で生成した CSRF トークンを付与し、サーバ側で検証する。トークンはユーザセッションと紐づけ、推測不能とする。
• ダブルサブミット Cookie
  CSRF トークンを Cookie とリクエストボディ（またはヘッダ）の両方に送信し、両者の一致を確認する。
• SameSite Cookie
  先述のとおり、SameSite=Lax / Strict を利用してクロスサイトからの Cookie 送信を抑制する。ただし、ブラウザ依存性や UX への影響を考慮する必要がある。
• Referer / Origin ヘッダ検証
  リクエストの送信元オリジンが期待するドメインであるかを検証する。ただし、プライバシー設定やプロキシ環境によりヘッダが送信されないケースもあるため、単独対策としては不十分な場合が多い。

多くの場合、これらの対策を組み合わせて実装することが望ましい。Pentest では、実装されている対策の有無だけでなく、「対象エンドポイントごとに対策が適用されているか」「トークンが適切に検証されているか」を確認する。

CSRF と CORS / SameSite の関係

CSRF は、同一生成元ポリシーを前提としたブラウザの挙動を悪用する攻撃であり、CORS や SameSite の設定と密接に関係する。

• CORS
  CORS は主に「レスポンスの JavaScript からの読み取り」を制御する仕組みであり、CSRF そのものを防ぐものではない。ただし、誤設定により第三者オリジンから認証付き API レスポンスが読み取れる場合、CSRF や XSS と組み合わせて情報漏えいの影響が増大する。
• SameSite
  SameSite は「どのリクエストで Cookie を送信するか」を制御するため、CSRF リスクの低減には直接的に寄与する。ただし、ブラウザ実装差異やバックワードコンパチビリティの観点から、完全な防御とは言えない。

Pentest の報告では、「CSRF トークンが実装されていない」「SameSite 設定が不適切」といった個別指摘に留まらず、「どのビジネス操作が CSRF により悪用され得るか」をシナリオとして示すことが重要である。

本章のポイント

• セッション管理では、セッション ID の推測困難性、ログイン時の再発行（Session Fixation 対策）、無効化とタイムアウトが確認ポイントとなる。
• CSRF は「ブラウザが Cookie を自動送信する」挙動を悪用するため、状態変更系リクエストの保護が重要である。
• 対策は CSRF トークンや SameSite などの組み合わせが基本であり、エンドポイント単位で適用状況と検証の厳密さを確認する。

JWT / OAuth2 / OIDC の基礎

title: “JWT / OAuth2 / OIDC の基礎” part: “Part 2” chapter: “2-3”

JWT / OAuth2 / OIDC の基礎

本章では、API および認証・認可の文脈で頻出する JWT（JSON Web Token）、OAuth2、OpenID Connect（OIDC）の基礎を整理する。詳細な攻撃手法やテスト観点は Part 4 で扱うため、ここでは構造と役割に焦点を当てる。

本章のゴール

• 前提：HTTP ヘッダと Cookie の基礎、およびセッション管理の概要（前章）を把握している。
• 到達目標：JWT の構造と検証観点、OAuth2 のロールと Authorization Code + PKCE の流れ、OIDC の ID トークンと主要クレームを説明できる。
• 対応演習：Burp Suite で Authorization ヘッダ等のトークンを観察し、JWT のヘッダ／ペイロードを読み解く。

JWT の構造

JWT は、JSON 形式のクレームセットに署名（または暗号化）を施し、コンパクトなトークンとして表現する仕組みである。典型的な形式は次のとおり。

header.payload.signature

• Header
  アルゴリズム（alg）やトークン種別（typ）など、メタ情報を含む。
• Payload
  sub（主体）、iss（発行者）、exp（有効期限）などのクレームを含む。アプリケーション固有のクレームを含めることも多い。
• Signature
  Header と Payload を結合し、秘密鍵や共有鍵を用いて署名した値。

Pentest の観点では、次の点が典型的な確認ポイントとなる。

• 署名アルゴリズムが適切か（none アルゴリズムの許容有無など）
• 秘密鍵・共有鍵の管理が適切か（推測可能な値を用いていないか）
• 有効期限（exp）や発行時刻（iat）が適切に設定・検証されているか
• クレームの整合性（iss、aud など）が検証されているか

これらの詳細な攻撃パターンは、Part 4 にて API 特有の文脈と合わせて解説する。

OAuth2 のロールとフロー

OAuth2 は「認可」のフレームワークであり、一般的に以下のロールが登場する。

• リソースオーナー（Resource Owner）
  データの所有者（多くの場合、エンドユーザ）。
• クライアント（Client）
  リソースオーナーに代わって API にアクセスするアプリケーション。
• 認可サーバ（Authorization Server）
  エンドユーザの認証と、アクセストークンの発行を担当する。
• リソースサーバ（Resource Server）
  保護されたリソースを提供する API。

これらのロールの関係を、簡単に言い換えると次のようになる。

• ユーザは、クライアント（アプリケーション）に対して「自分のデータへのアクセス」を許可する。
• クライアントは、認可サーバに対して「ユーザの代わりに動いてよいか」を問い合わせる。
• 認可サーバは、ユーザを認証した上でトークンを発行し、そのトークンを用いてクライアントがリソースサーバにアクセスできるようにする。

代表的なフローとしては、Authorization Code フロー（特に PKCE 付き）が広く利用されている。本書では、主にこのフローを前提として説明を行い、Implicit Flow など古いパターンの詳細な解説は扱わない。図2-2 に Authorization Code フローの概要を示す。

図2-2: OAuth2 Authorization Code フロー（概要）

sequenceDiagram
    participant U as User
    participant C as Client (App)
    participant AS as Authorization Server
    participant RS as Resource Server

    U->>C: 保護リソースへのアクセス要求
    C->>AS: 認可リクエスト（ブラウザリダイレクト）
    U->>AS: 認証・同意
    AS-->>C: 認可コード (via redirect_uri)
    C->>AS: 認可コード + クライアント認証
    AS-->>C: アクセストークン (+ ID トークン)
    C->>RS: API リクエスト (Authorization: Bearer ...)
    RS-->>C: 保護リソース

図2-2 を読む際は、ブラウザリダイレクトでやり取りされる要素と、クライアント（バックエンド）から認可サーバへ直接送られる要素を区別すると整理しやすい。

1. クライアントがブラウザを通じて認可サーバにリダイレクトし、ユーザ認証・同意を取得する。
2. 認可サーバはクライアントに認可コードを返却する。
3. クライアントはバックエンドから認可コードとクライアントシークレット（または PKCE のコードベリファイア）を用いてトークンエンドポイントにアクセスし、アクセストークンを取得する。
4. クライアントはアクセストークンを用いてリソースサーバに API リクエストを送信する。

Pentest では、次のような観点が重要となる。

• クライアントシークレットやリダイレクト URI の管理が適切か
• 認可コードの再利用や盗聴が攻撃に繋がらない設計となっているか
• スコープが適切に制限されているか（過剰な権限の付与がないか）

OpenID Connect（OIDC）

OIDC は OAuth2 をベースとした認証レイヤであり、ユーザの「ID」を表現する ID トークン（通常は JWT）を定義する。これにより、クライアントは「誰であるか」を標準化された形式で取得できる。

OIDC では、ID トークンが持つクレーム（sub、iss、aud、nonce など）が重要であり、特に次の点がセキュリティ上の焦点となる。

• aud（オーディエンス）が想定するクライアント ID と一致しているか
• nonce を利用してリプレイ攻撃を防いでいるか
• iss が信頼する IdP（Identity Provider）であることを検証しているか

認証と認可の混同

実務では、「OAuth2 によるログイン」や「API トークンによる認証」という表現がしばしば混在し、認証と認可の境界が不明瞭になることがある。Pentest の観点では、次の点を明確に切り分けて評価する。

• 誰であるかを証明する仕組み（認証）
• 何をしてよいかを制御する仕組み（認可）

たとえば、「アクセストークンを持っていれば、組織内すべてのリソースにアクセスできる」設計は、認可の粒度が粗すぎる状態であり、API Security Top 10 における典型的なリスク（BOLA や過剰権限）と直結する。

本書の Part 4 では、これらの理論を前提として、実際のトークン検証や認可不備のテスト手法を詳細に扱う。

本章のポイント

• JWT は header.payload.signature の形式で表現され、署名アルゴリズムやクレーム検証の妥当性が Pentest の主要な確認点となる。
• OAuth2 は認可のフレームワークであり、ロール、Authorization Code（PKCE 付き）フロー、リダイレクト URI・スコープ等の設計がリスクに直結する。
• OIDC は OAuth2 をベースとした認証レイヤであり、ID トークンのクレーム（iss / aud / nonce 等）と、認証・認可の切り分けが重要である。

典型的な Web 脆弱性の整理

title: “典型的な Web 脆弱性の整理” part: “Part 2” chapter: “2-4”

典型的な Web 脆弱性の整理

本章では、後続の Part 3 以降で詳細に扱う代表的な Web 脆弱性を、プロトコルレベルの観点から概観する。ここでは「名前と概要」「成立の前提」「大まかな検証イメージ」に留め、具体的な手順やツール操作は後続の Part に委ねる。

本章のゴール

• 前提：HTTP / Cookie / セッション / トークンの基礎（本 Part 前半）を把握している。
• 到達目標：代表的な脆弱性（XSS、インジェクション、認可不備、SSRF 等）について、成立の前提をプロトコル視点で説明できる。
• 対応演習：exercises/juice-shop/ や exercises/dvwa/ で、各脆弱性が成立する入口と「どのリクエストが変わると挙動が変わるか」を観察する（起動手順は 付録「演習環境クイックスタート」 を参照。具体手順は Part 3 以降で扱う）。

クロスサイトスクリプティング（XSS）

XSS は、攻撃者が用意したスクリプトが被害者のブラウザ上で実行される脆弱性であり、主なパターンは以下のとおりである。

• 反射型（Reflected XSS）
  リクエストパラメータがそのままレスポンスに反映されるケース。
• 蓄積型（Stored XSS）
  掲示板やコメント欄などに保存されたデータが、閲覧時にスクリプトとして実行されるケース。
• DOM ベース XSS
  クライアントサイド JavaScript のみで DOM 操作が行われる結果、XSS が成立するケース。

成立要件としては、入力値の不足したエスケープ／サニタイズ、およびコンテキスト不一致（HTML/属性/JavaScript コンテキストの混在）などが挙げられる。影響としては、Cookie やローカルストレージの窃取、CSRF トークンの窃取、任意操作の実行などが考えられる。

インジェクション（SQL インジェクション等）

インジェクション系脆弱性は、ユーザ入力が適切に検証・エスケープされないまま、コマンドやクエリとして評価されることで発生する。

• SQL インジェクション
  入力値を通じて SQL クエリの構造が変更され、データベースの情報漏えいや改ざんが発生する。
• コマンドインジェクション
  OS コマンドの引数にユーザ入力が埋め込まれ、任意コマンド実行が可能となる。
• LDAP / NoSQL インジェクションなど
  特定のクエリエンジン固有の構文を悪用するパターン。

代表的な対策は、プレースホルダ（バインド変数）によるパラメータ化、ホワイトリストベースの入力検証、および最小権限の付与である。Pentest では、典型的なペイロードによる挙動変化の確認に加え、「誤ったエラー応答」「タイミングの変化」など副次的なシグナルにも注意を払う。

パス・ディレクトリトラバーサル

ユーザ入力がファイルパスに利用される場合、../ などを用いて想定外のディレクトリにアクセスできる場合がある。これにより、アプリケーションの設定ファイルや OS の機密ファイルが漏えいするリスクがある。

対策としては、パスの正規化とホワイトリストによる制限（特定ディレクトリ配下に限定する）、拡張子の固定、OS 依存のショートカット（C:\、//?/ など）への考慮などが挙げられる。

不適切なアクセス制御（認可不備）

OWASP Top 10 2021 の A01（Broken Access Control）に代表されるように、認可不備は近年の Web / API における最重要カテゴリの一つである。

典型的なパターンには次のようなものがある。

• URL 変更や ID 変更により、他者のリソースにアクセス可能（IDOR / BOLA）
• クライアント側の UI から隠されているだけで、バックエンドではアクセス制御されていない機能
• ロールや権限による制御が、クライアント側のフラグに依存している

Pentest では、単一リクエストの挙動だけでなく、「異なるユーザ・ロール間で同一リクエストを再現した場合の違い」に着目してテストを行う。

SSRF（Server-Side Request Forgery）

SSRF は、サーバ側が外部に対して HTTP リクエストを行う機能（URL 取得、Webhook、API プロキシなど）を悪用し、本来アクセスできない内部ネットワークやメタデータサービス（例：AWS の IMDS）にアクセスさせる攻撃である。

クラウド環境では、SSRF を起点として IMDSv1 から認証情報を取得し、クラウドリソースへの不正アクセスに繋がるケースがある。Part 6 では、この攻撃パスをより詳細に扱う。

オープンリダイレクト

アプリケーションがリダイレクト先 URL をユーザ入力に依存して決定している場合、任意の外部サイトへのリダイレクトが可能となることがある。これ自体は単独で致命的な脆弱性とならないケースも多いが、フィッシングや OAuth2 フローの悪用（認可コードの奪取など）と組み合わせると影響が大きくなる。

本 Part 以降との関係

本章で挙げた脆弱性は、いずれも HTTP / Cookie / CORS / SameSite、セッション管理、JWT / OAuth2 / OIDC といった基盤要素と密接に関係する。Part 3 以降では、これらを前提として次のような観点を詳細に扱う。

• 実際のリクエスト／レスポンスをどのように観察し、攻撃面を特定するか
• Burp Suite や各種ツールを用いて、どのように PoC を構築するか
• 発見した脆弱性を、どのようなリスクシナリオとして整理し、報告するか

Part 2 を通じて、これらの脆弱性が「なぜ成立するか」を整理しておくことで、後続の実践 Part での理解が大きく向上する。

本章のポイント

• 代表的な Web 脆弱性（XSS、インジェクション、トラバーサル、認可不備、SSRF 等）は、入力・出力・権限・通信経路の前提が崩れることで成立する。
• 重要なのは手法の暗記ではなく、HTTP / Cookie / セッション / トークン等の基盤要素と結びつけて「成立条件」を説明できることである。
• Part 3 以降では、Burp Suite 等を用いて実リクエストを観察しながら、PoC 作成と報告への落とし込みを具体化する。

Part 3：Web Pentest 実践

title: “Web Pentest 実践 Part の狙い” part: “Part 3” chapter: “3-0”

Part 3：Web Pentest 実践の位置づけ

Part 3 では、Burp Suite を中心とした Web Pentest の実践手順を扱う。Part 1〜2 で整理した攻撃モデル・HTTP / Cookie / セッション管理などの基礎を前提とし、「実際にどのような手順で対象を調査し、脆弱性を確認し、PoC とレポートに落とし込むか」を具体化する。

本 Part は、2024 年時点で一般的に利用されている Burp Suite Community / Professional Edition（2023.x〜2024.x 系）を前提とするが、ツールバージョンに依存しない概念とワークフローを重視して記述する。

本 Part で扱う主なテーマは以下のとおりである。

• Burp Suite の基本操作（Proxy / Repeater / Intruder / Decoder など）
• 情報収集、アタックサーフェスの把握、セッション管理の確認
• 典型的な Web 脆弱性に対するテスト手順と PoC 作成
• PortSwigger Web Security Academy を利用したハンズオン演習

以降の章は、実際の診断現場で利用できる「手順書」のイメージで構成する。

本 Part を読む前提と対応演習

前提として、少なくとも次の状態を想定する。

• Part 2 で HTTP / Cookie / セッション管理などの基礎を一度読んでいる
• Web ブラウザを使って簡単な Web アプリケーションを操作できる

演習環境としては、exercises/juice-shop/ および exercises/dvwa/ を想定し、Burp Suite をプロキシとして挟みながら、実際にリクエスト／レスポンスを観察・改変する流れを体験する。

関連資料

• 付録「演習環境クイックスタート」
• Web Pentest チェックリスト（原案）
• Pentest レポートテンプレート
• 用語集

本章のポイント

• Part 3 は Burp Suite を用いた Web Pentest の実践手順を、ワークフローとして具体化する。
• ツールの UI はバージョン差分があるため、操作手順よりも「何を観察し、何を確認するか」を重視する。
• 演習は exercises/juice-shop/ と exercises/dvwa/ を用い、観察・改変・PoC 整理・報告の流れを体験する。

Burp Suite 入門

title: “Burp Suite 入門” part: “Part 3” chapter: “3-1”

Burp Suite 入門

本章では、Burp Suite の役割と主要コンポーネント、基本的なセットアップ手順について整理する。詳細なテクニックは次章以降で扱う。

本章のゴール

• 前提：Part 2 で HTTP / Cookie / セッション管理の基礎を把握している。
• 到達目標：Burp Suite の主要コンポーネント（Proxy / Target / Repeater / Intruder 等）と、基本セットアップ（プロキシ、CA 証明書、スコープ設定）の要点を説明できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ を Burp Suite 経由で操作し、HTTPS 復号とサイトマップ取得、重要リクエストの Repeater 保存を試す（起動手順は 付録「演習環境クイックスタート」 を参照）。

Burp Suite の位置づけ

Burp Suite は、Web アプリケーションおよび API を対象としたプロキシ型のテストプラットフォームであり、次のような用途に利用される。

• ブラウザとサーバ間の HTTP(S) トラフィックの可視化・改変
• リクエストの再送・パラメータの体系的なテスト
• スキャンや自動化機能（Professional 版）
• 拡張（BApp Store、カスタム拡張）による機能拡張

Pentest においては、Burp Suite を中心とした「プロキシベースのワークフロー」を確立することが、効率と再現性の観点から重要となる。

オープンソースの代替として OWASP ZAP なども広く利用されているが、本書では実務での利用頻度と周辺エコシステム（拡張機能や PortSwigger Web Security Academy など）を考慮し、Burp Suite を中心に説明する。ZAP 等の他ツールを用いる場合でも、「ブラウザ → プロキシ → 対象アプリケーション」というプロキシベースのワークフロー自体は概ね共通である。

基本コンポーネント

本書で主に利用するコンポーネントは次のとおりである。

• Proxy
  ブラウザからのトラフィックを中継・記録する。Intercept 機能により、リクエストを送信前に編集できる。
• Target
  観測したホスト／パスの一覧とサイトマップを表示する。スコープ設定やツリービューを通じてアタックサーフェスを把握する。
• Repeater
  個別のリクエストを保存し、パラメータを変えながら繰り返し送信する。手動での検証や PoC 構築に適する。
• Intruder
  指定箇所に対して複数のペイロードを自動挿入し、テストを自動化する。認証試行、パラメータ汚染、IDOR 調査などに利用できる。
• Decoder / Comparer
  エンコード／デコードやレスポンス差分の比較に使用する。

図3-1: Burp Suite の主要コンポーネント

flowchart LR
    Browser[ブラウザ] --> Proxy[Proxy]
    Proxy --> Target[Target]
    Proxy --> Repeater[Repeater]
    Proxy --> Intruder[Intruder]

    subgraph Burp Suite
        Proxy
        Target
        Repeater
        Intruder
    end

    note right of Proxy: HTTP(S) トラフィックの中継・記録

図3-1 のように、Proxy（観測）を起点として Target（整理） / Repeater（再現） / Intruder（自動化）にリクエストを送るイメージを持つと、ワークフローが整理しやすい。

Professional 版では、Scanner や、拡張された自動化機能も利用可能だが、本書では Community 版でも再現可能なワークフローを基盤とする。

セットアップの基本

Burp Suite を利用する際の典型的なセットアップ手順は次のとおりである。

1. Burp Suite を起動し、Temporary Project またはプロジェクトファイルを選択する。
2. Proxy のリスニングポート（通常 127.0.0.1:8080）を確認する。
3. ブラウザ側で HTTP/HTTPS プロキシとして Burp を設定する（Firefox、専用ブラウザ、またはブラウザ拡張など）。
4. Burp の CA 証明書をブラウザにインポートし、HTTPS 通信を復号可能にする。
5. Target のスコープ設定で、テスト対象のホスト／ドメインのみを含める。

環境によっては、組織のプロキシや証明書ポリシーが存在するため、実務環境に合わせた設定が必要となる。演習環境では、ローカルの Docker Compose などでホストされた脆弱なアプリケーションを利用することを前提とする。

スコープ設定とログ管理

実務上、スコープ設定とログ管理を適切に行うことは非常に重要である。

• スコープ外のホストには意図せず負荷をかけないよう、明示的に対象範囲を限定する
• 重要なリクエスト（ログイン、権限変更、支払い操作など）は Repeater に保存し、再現性を確保する
• バージョン管理されたプロジェクトファイルやセッションログを活用し、後日の調査やレビューに備える

次章では、これらのコンポーネントを用いた Web Pentest の基本ワークフローを整理する。

本章のポイント

• Burp Suite はプロキシ型のテストプラットフォームであり、Web / API Pentest のワークフローを支える中心ツールである。
• セットアップでは、プロキシ設定、CA 証明書のインポート、スコープ設定を行い、意図しない範囲への通信を避ける。
• 再現性の確保のため、重要なリクエストは Repeater に保存し、ログ管理を前提に運用する。

Web Pentest のワークフロー

title: “Web Pentest のワークフロー” part: “Part 3” chapter: “3-2”

Web Pentest のワークフロー

本章では、Burp Suite を用いた典型的な Web Pentest のワークフローを、「情報収集 → アタックサーフェスの把握 → 脆弱性仮説の立案 → 検証・PoC 作成」という流れで整理する。

本章のゴール

• 前提：Burp Suite の基本操作とセットアップ（前章）を完了している。
• 到達目標：情報収集、アタックサーフェス整理、仮説立案、検証、結果整理を一連のワークフローとして説明し、再現性を意識して運用できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ を対象に、Target でサイトマップを整理し、重要操作を Repeater に保存した上で、仮説ベースでパラメータを変更して挙動差分を記録する（起動手順は 付録「演習環境クイックスタート」 を参照）。

1. 情報収集（Reconnaissance）

最初のステップは、対象アプリケーションの構造と機能を把握することである。Burp Proxy を有効にした状態で、通常のユーザとしてアプリケーションを一通り操作し、次の点に着目する。

• ホスト、パス、パラメータの一覧
• 認証機能（ログイン、ログアウト、パスワードリセットなど）
• 権限レベル（一般ユーザ、管理者、API クライアントなど）
• 入力フォーム（検索、登録、更新、削除など）

Burp の Target タブでは、観測したパスがツリービューで表示されるため、「どの URL がどの機能に対応しているか」を整理しやすい。対象範囲外のドメインはスコープから除外しておく。

2. セッション管理と認証の確認

次に、セッション管理と認証周りの挙動を確認する。

• ログイン前後で Cookie（セッション ID）がどのように変化するか
• Secure / HttpOnly / SameSite 属性の有無
• 多要素認証や IP 制限など追加のセキュリティ層の存在

ログインリクエストおよび重要な操作（権限変更、パスワード変更など）は、必ず Repeater に送っておき、後続の検証で再利用できるようにする。

3. アタックサーフェスの特定

情報収集の結果をもとに、どこに攻撃面が存在しうるかを整理する。

• 外部入力を受け取るポイント（パラメータ、ヘッダ、ボディ、JSON、GraphQL など）
• 状態変更を伴う POST/PUT/DELETE リクエスト
• ファイルアップロード、リダイレクト、外部 URL 参照機能

Burp の「Issue definitions」や OWASP WSTG の分類を参考にしつつ、「このエンドポイントでは XSS が成立しうるか」「この API では BOLA があり得るか」といった仮説を立てる。

4. 仮説に基づく検証（Repeater / Intruder）

アタックサーフェスが整理できたら、個別の仮説に基づいて検証を行う。

• Repeater を用いた手動テスト
  パラメータやヘッダを少しずつ変更し、レスポンスの変化を観察する。XSS、SQL インジェクション、アクセス制御不備など、主に論理的な検証に向く。
• Intruder を用いた半自動テスト
  認証試行（ブルートフォース／クレデンシャルスタッフィング）、IDOR / BOLA 調査（連番 ID の列挙）、入力長や文字種の境界テストなど、一定パターンを持つ繰り返しテストに適する。

検証結果は、後述の PoC 作成とレポーティングに利用できるよう、パラメータ値・レスポンスコード・レスポンス本文などを記録しておく。

5. 発見事項の整理とリスク評価

発見した挙動が「仕様上の想定」であるのか、「脆弱性」と言えるのかを判断するため、Part 1 で扱ったリスク評価の観点（DREAD やビジネスインパクト）を適用する。

• 認証を要する機能に対して、認証なしでアクセス可能か
• 他者のデータを閲覧／変更できるか（IDOR / BOLA）
• セキュリティ上のベストプラクティス（ASVS 等）から明らかに逸脱しているか

ここでの整理が、そのままレポートの章立てや優先度に直結する。

6. 再現性の確保

Pentest の結果は、「一度だけ再現できた」だけでは不十分である。将来の検証や修正確認のため、次の点を意識して再現性を確保する。

• Repeater のタブに、脆弱性の再現に必要な最小限のリクエストを保存する
• オプションとして、Burp のプロジェクトファイルに一連のテスト状態を保存する
• 後のレポートで利用できるよう、画面キャプチャや重要なレスポンスを整理しておく

次章では、これらのワークフローからどのように具体的な PoC とレポートを作成するかを扱う。

本章のポイント

• Web Pentest は「情報収集 → アタックサーフェス整理 → 仮説立案 → 検証 → 結果整理」の順で進めると再現性を確保しやすい。
• Burp Suite の Target / Repeater / Intruder を使い分け、重要リクエストを保存して検証の土台にする。
• 発見事項は DREAD や ASVS 等の観点で評価し、報告に直結する形で記録しておく。

PoC 作成とレポーティング

title: “PoC 作成とレポーティング” part: “Part 3” chapter: “3-3”

PoC 作成とレポーティング

本章では、発見した脆弱性を PoC（Proof of Concept）として整理し、Pentest レポートに落とし込む際のポイントを扱う。技術的な検証とビジネス側への説明の橋渡しが主眼である。

本章のゴール

• 前提：対象機能の挙動差分が取れており、再現可能なリクエストを Repeater 等に保存している。
• 到達目標：PoC を「最小限・再現可能・本番影響を最小化」の原則で整理し、レポートではリスクシナリオと影響（ビジネスインパクト）まで含めて説明できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ で発見した挙動を 1 件選び、再現手順・証拠（リクエスト／レスポンス）・推奨対策を PoC としてまとめる（起動手順は 付録「演習環境クイックスタート」 を参照）。

PoC の基本方針

PoC は、「脆弱性が実際に悪用可能であること」を示す最小限の手順と証拠から構成される。実務では次の点を重視する。

• 再現手順が簡潔であること（手順の数、依存条件が最小限）
• 本番環境への影響を最小化していること（データ改ざんやサービス停止を伴わない範囲で実施）
• 攻撃者視点と防御者視点の両方から意味が読み取れること

Burp Suite 上での PoC は、通常以下の要素を含む。

• 対象 URL と HTTP メソッド
• 必要な前提条件（ログイン状態、ロール、特定のパラメータ値など）
• 実際に送信したリクエスト（ヘッダ／ボディを含む）
• 特徴的なレスポンス（ステータスコード、本文の一部）

Burp を用いた PoC の整理

実務では、Burp の Repeater やプロジェクトファイルを PoC の土台として活用する。

• Repeater タブを「脆弱性ごと」に整理し、名称を付けておく
• スクリーンショットやテキストエクスポートをレポート用資料として保存する
• 必要に応じて、簡易的なスクリプト（例：curl コマンド、Python スクリプト）に変換し、自動再現可能な PoC として提供する

PoC 自体が攻撃ツールとして悪用されないよう、提供範囲や管理方法については組織のポリシーに従う。

レポート構成の基本

本書の Part 7 ではレポートテンプレートを詳細に扱うが、ここでは Web Pentest における典型的な構成を簡潔に示す。

• エグゼクティブサマリ
  評価対象、期間、主なリスク、全体的な所見。
• メソドロジー（手法）
  利用した標準（OWASP ASVS / WSTG 等）、テスト環境、ツール（Burp Suite など）。
• 発見事項（Findings）
  脆弱性ごとに、概要、影響度、再現手順、証拠（スクリーンショットやログ）、推奨対策を記載。
• 附属資料
  テスト対象の一覧、スコープ、使用したチェックリスト等。

Burp の結果をそのまま貼り付けるのではなく、「なぜそれがビジネス上重要か」「どのようなリスクシナリオが想定されるか」を文章として補うことが重要である。

リスクシナリオの記述

単に「XSS が存在する」と記載するだけでは、非技術者にとってリスクの理解が難しい。次のような観点からシナリオを記述する。

• 攻撃者の前提（認証の有無、ネットワーク位置など）
• 想定される攻撃手順の概要
• 被害内容（情報漏えい、なりすまし、不正取引など）
• 発生しうる頻度や検知の難易度

Part 1 で扱った攻撃モデル（Kill Chain / MITRE ATT&CK）を引用し、「本件は Initial Access と横展開の起点となりうる」といった表現を用いることで、防御側チームとの共通理解が得やすくなる。

本章のポイント

• PoC は「最小限」「再現可能」「本番影響を最小化」の原則で整理し、リクエスト／レスポンスを根拠として残す。
• Burp Suite の Repeater / プロジェクトファイルを PoC の土台にし、必要に応じて curl 等へ変換して再現性を高める。
• レポートは技術所見だけでなく、リスクシナリオとビジネス影響を文章で補い、関係者の合意形成に繋げる。

PortSwigger Academy を使ったハンズオン

title: “PortSwigger Academy を使ったハンズオン” part: “Part 3” chapter: “3-4”

PortSwigger Web Security Academy を使ったハンズオン

PortSwigger Web Security Academy（以下、Burp Academy）は、無料で利用できる Web セキュリティ学習プラットフォームであり、Burp Suite と連携した多数のハンズオンラボを提供している。本章では、Part 3 で解説したワークフローを実際に試すための学習パスを提案する。

本章のゴール

• 前提：Burp Suite を用いた基本ワークフロー（情報収集→検証→整理）を理解している。
• 到達目標：Burp Academy を利用して脆弱性カテゴリ別に学習を進め、Burp の操作・観察・記録を反復して定着させる方針を立てられる。
• 対応演習：Burp Academy のラボを利用し、SQLi／認証・セッション／XSS／アクセス制御などのカテゴリを順に試し、成功・失敗のログを残す。

Burp Academy の特徴

Burp Academy の主な特徴は次のとおりである。

• 実際に攻撃可能な脆弱なアプリケーションが、ラボごとに自動で起動される
• 各ラボに目的とヒントが用意されており、段階的に難易度が上がる
• Burp Suite を前提とした手順が多く、ツールの操作に自然と慣れる

本書では、2024 年時点で公開されているラボ群を前提としつつ、特定のラボ ID や UI 仕様には依存しないように記述する。

推奨学習パス（例）

Part 2〜3 の内容を踏まえた学習パスの一例を示す。

1. SQL injection（基本）
   • 目的：パラメータを通じて SQL クエリが変化する挙動を理解する
   • Burp の利用：Proxy でリクエストをキャプチャし、Repeater でペイロードを試行
2. Authentication / Session management
   • 目的：弱いパスワードポリシー、Session Fixation、セッションハイジャックの概念を理解する
   • Burp の利用：Intruder を用いたパスワード推測、Cookie の変化の観察
3. Cross-site scripting (XSS)
   • 目的：反射型／蓄積型 XSS の成立条件と、コンテキストごとのエスケープの重要性を理解する
   • Burp の利用：リクエストの送信・改変に加え、レスポンス HTML の構造確認
4. Access control / IDOR
   • 目的：IDOR / BOLA の典型的なパターンを体験する
   • Burp の利用：複数ユーザアカウントでのリクエスト差分の比較、Intruder による ID 列挙

各ラボで得られたリクエスト／レスポンスは、PoC とレポート作成の練習にも利用できる。

自前演習環境との組み合わせ

Burp Academy はクラウド上の演習環境を提供する一方で、本書では Juice Shop / DVWA / crAPI など自前の Docker ベース環境も併用する。

• Burp Academy
  • 教材設計済みのラボで特定の脆弱性にフォーカス
  • 短時間でポイントを押さえたい場合に有効
• 自前演習環境
  • アプリケーション全体の構造を把握しながら、複数の脆弱性を横断的に確認する
  • 本番に近いワークフロー（スコーピング → 情報収集 → 攻撃 → レポート）を模擬できる

読者には、まず Burp Academy で代表的な脆弱性カテゴリを一通り体験し、その後で自前環境を用いた総合的なテスト練習に進むことを推奨する。

学習ログの取り方

学習の定着を高めるため、次のようなログの取り方を推奨する。

• 取り組んだラボ名、脆弱性カテゴリ、難易度
• 使用した Burp のコンポーネント（Proxy / Repeater / Intruder など）
• 成功した／失敗したペイロードと、その理由
• 実務でどのようなシナリオに対応しうるか

本書の付属テンプレート（学習ログシートや演習記録フォーマット）と組み合わせることで、組織内研修での進捗管理にも活用できる。

本章のポイント

• Burp Academy は Burp Suite と連携したラボを提供し、脆弱性カテゴリごとの学習に適している。
• Part 2〜3 の内容に沿って、SQLi／認証・セッション／XSS／アクセス制御などの順に進めると理解が定着しやすい。
• Burp Academy と自前演習環境を併用し、学習ログを残すことで、実務の PoC・報告へ接続しやすくなる。

Part 4：API Pentest と認証／権限管理

title: “API Pentest Part の狙い” part: “Part 4” chapter: “4-0”

Part 4：API Pentest と認証／権限管理

Part 4 では、Web アプリケーションのバックエンドとして広く利用される API（REST / GraphQL 等）を対象としたペネトレーションテストと、認証・権限管理の検証を扱う。

前提として、Part 2 で整理した HTTP / JWT / OAuth2 / OIDC の基礎、および Part 3 の Burp ベースのワークフローを踏まえ、「API 特有の攻撃面」と「認可の誤実装」を中心に解説する。

本 Part で扱う主なトピックは次のとおりである。

• API の攻撃面整理（エンドポイント、スキーマ、環境の観点）
• BOLA / Mass Assignment / Rate Limit 不備など、API 特有の脆弱性
• Swagger / OpenAPI 仕様からの攻撃面抽出
• OAuth2 / OIDC / 外部 ID 連携（例：Google ID）のテスト観点
• RBAC / ABAC の誤実装パターンと検証方法

API Security Top 10 で定義されるような代表的リスクをベースにしつつ、実務で頻出する「アクセス制御の欠落」や「クライアント信頼」に焦点を当てる。

本 Part を読む前提と対応演習

前提として、以下の状態を想定する。

• Part 2 で HTTP / JWT / OAuth2 / OIDC の基礎に一度触れている
• Part 3 で Burp Suite を用いた Web Pentest の基本的なワークフローを経験している

演習環境としては、exercises/crapi/ に配置する API 演習環境を用い、OpenAPI 仕様と実際のトラフィックを付き合わせながら、BOLA や Mass Assignment などの API 特有の脆弱性を確認することを想定する。

関連資料

• 付録「演習環境クイックスタート」
• API Security チェックリスト（原案）
• OAuth2 / OIDC テスト項目表（原案）
• 用語集

本章のポイント

• API Pentest では、API 特有の攻撃面（エンドポイント／スキーマ／環境）と、認証・認可（アクセス制御）の誤実装を中心に検証する。
• Part 2（HTTP / JWT / OAuth2 / OIDC）と Part 3（Burp Suite を用いたワークフロー）を前提に、API Security Top 10 の代表的リスクを実務観点で整理する。
• OpenAPI 仕様と実トラフィックを突き合わせながら、BOLA / Mass Assignment / Rate Limit 不備などの成立条件を確認する。

API の基礎と攻撃面の整理

title: “API の基礎と攻撃面の整理” part: “Part 4” chapter: “4-1”

API の基礎と攻撃面の整理

本章では、REST 形式を中心とした API の構造と、Pentest における攻撃面（アタックサーフェス）の整理方法を扱う。

本章のゴール

• 前提：Part 2 の HTTP / JWT / OAuth2 / OIDC の基礎と、Part 3 の Burp Suite を用いたワークフローの概要を把握している。
• 到達目標：API の基本要素と攻撃面の 3 観点（エンドポイント／データモデル／環境・インフラ）を説明し、OpenAPI 仕様と実トラフィックを使ってテスト対象を整理できる。
• 対応演習：exercises/crapi/ を対象に Burp Suite で API トラフィックを取得し、OpenAPI 仕様（存在する場合）と照合してエンドポイント一覧とテスト観点を作成する（起動手順は 付録「演習環境クイックスタート」 を参照）。

API の基本要素

典型的な REST API は、次の要素で構成される。

• エンドポイント（URI）
  例：/api/v1/users/{userId}、/api/v1/orders
• HTTP メソッド
  GET（取得）、POST（作成）、PUT/PATCH（更新）、DELETE（削除）など
• リクエストボディ
  JSON や XML で送信されるデータ。ネストしたオブジェクトや配列を含むことが多い。
• 認証情報
  Authorization ヘッダの Bearer トークン（JWT 等）、API キー、クライアント証明書など。

図4-1 は、クライアント（Web/モバイル）からバックエンド API に到達する境界（Gateway / Load Balancer）と、API が参照する周辺コンポーネント（DB、IdP）をまとめた構成例である。以降は、この図を前提に「誰がどのエンドポイントにアクセスしうるか」を整理した上で、攻撃面を 3 観点に分解する。

図4-1: Web / モバイルと API バックエンドの構成例

flowchart LR
    subgraph Client
        W[Web ブラウザ]
        M[モバイルアプリ]
    end

    subgraph Backend
        GW[API Gateway / Load Balancer]
        API[REST / GraphQL API]
        DB[(Database)]
        IDP[IdP / OAuth2 Server]
    end

    W --> GW
    M --> GW
    GW --> API
    API --> DB
    API --> IDP

Web アプリケーションの裏側で利用される API もあれば、モバイルアプリや外部パートナー向けに公開される API もある。Pentest では、「誰がどのエンドポイントにアクセスしうるか」を前提条件として整理することが重要になる。

攻撃面の三つの観点

API の攻撃面は、おおむね次の 3 つの観点で整理できる。

• エンドポイントレベル
  • パス構造（ID やリソースの階層）
  • メソッドごとの機能（読み取り専用か、更新を伴うか）
  • 認証・認可の有無（公開 API / 認証必須 / 管理者専用 など）
• データモデルレベル
  • リクエストボディ／レスポンスボディのスキーマ（必須・任意のプロパティ）
  • サーバ側で自動バインディングされるオブジェクト（Mass Assignment の有無）
  • ID や外部キーの設計（予測可能性、連番かどうか）
• 環境・インフラレベル
  • レート制限やスロットリングの設定
  • ログや監査証跡
  • CORS 設定、ゲートウェイや API Management のルール

これらを整理することで、「BOLA の余地があるエンドポイント」「Mass Assignment が発生しうる更新系 API」「レート制限が不足している認証エンドポイント」などの候補を効率的に抽出できる。

OpenAPI / Swagger 仕様の活用

多くの API では、OpenAPI（旧 Swagger）仕様が存在し、次のような形式で公開されている。

• openapi.json / swagger.json などの JSON 形式
• 開発者ポータルに掲載された API ドキュメント
• Swagger UI や Redoc などのブラウザ UI

Pentest では、OpenAPI 仕様を次の用途で活用できる。

• すべてのエンドポイントとメソッドの一覧化
• リクエスト／レスポンススキーマから、潜在的な隠しパラメータや不要なフィールドの特定
• 認証スキーム（securitySchemes）の確認

Burp Suite や他のツール（例：openapi-parser、各種プラグイン）を用いて OpenAPI 仕様を取り込み、テストケースの自動生成やカバレッジ確認に利用することもできる。

クライアントからのトラフィック取得

ブラウザベースの Web アプリケーションだけでなく、モバイルアプリや SPA（Single Page Application）なども API を利用している。これらのトラフィックを取得する方法として、次のようなパターンがある。

• Burp Proxy を利用した HTTPS トラフィックの中継（証明書インポートが必要）
• モバイル端末／エミュレータのプロキシ設定と証明書インストール（詳細は Part 5）
• CLI ツール（curl、httpie など）や Postman からの再現リクエスト

クライアント側の挙動だけに依存せず、「API 仕様と実際のトラフィックを突き合わせること」で、未公開エンドポイントやデバッグ用パラメータなどを見つけられる場合も多い。

本章のポイント

• API の基本要素（エンドポイント、メソッド、ボディ、認証情報）を整理し、「誰がどのエンドポイントにアクセスしうるか」を前提条件として明確化する。
• 攻撃面は、エンドポイント／データモデル／環境・インフラの 3 観点で整理すると、BOLA や Mass Assignment、レート制限不備などの候補を抽出しやすい。
• OpenAPI / Swagger 仕様と実トラフィックの両方を活用し、網羅性（カバレッジ）と実装差分の観点からテストケースを組み立てる。

典型的な API 脆弱性

title: “典型的な API 脆弱性” part: “Part 4” chapter: “4-2”

典型的な API 脆弱性

本章では、OWASP API Security Top 10 で代表される API 特有の脆弱性のうち、本書で特に重視する BOLA、Mass Assignment、Rate Limit 不備などを中心に整理する。

本章のゴール

• 前提：API の攻撃面（前章）を整理でき、Burp Suite 等で API リクエストを再現できる。
• 到達目標：BOLA / Mass Assignment / Rate Limit 不備などの成立条件と検証方針を説明し、仕様と実装の差分からリスクを特定できる。
• 対応演習：exercises/crapi/ を対象に、ID パラメータの変更、想定外フィールドの追加、認証系エンドポイントのレート制限確認などを、合意された範囲で実施し、成立条件を記録する（起動手順は 付録「演習環境クイックスタート」 を参照）。

BOLA（Broken Object Level Authorization）

BOLA は、オブジェクト（リソース）レベルのアクセス制御不備により、他者のデータにアクセスできてしまう脆弱性である。典型的なパターンは次のとおり。

• URI パスに含まれる ID（例：/api/v1/users/123）を変更すると、他ユーザの情報が取得できる
• クエリパラメータや JSON ボディの ID を変更すると、他者の注文やチケットを取得／操作できる

Pentest では、次のような手順で検証する。

• 異なるユーザロール（一般ユーザ、管理者など）で同じ API を呼び出し、レスポンス差分を比較する
• ID を連番や推測可能な値に変えて Repeater / Intruder で連続リクエストを行う
• レスポンスコードや本文から、「存在しないリソース」と「権限不足」の扱いが適切かを確認する

根本的な対策は、「ID の形式を変えること」ではなく、「認証情報とリソース所有者をサーバ側で厳密にチェックすること」である。

Mass Assignment（過剰なプロパティバインディング）

Mass Assignment は、フレームワークのオブジェクトバインディング機能により、想定外のフィールドまでクライアント入力で上書き可能となる脆弱性である。

例として、ユーザ更新 API が次のような JSON を受け取る設計を想定する。

{
  "name": "Alice",
  "email": "alice@example.com"
}

しかし、サーバ側のモデルには role や isAdmin などのフィールドが存在し、かつバインディングの制限が行われていない場合、クライアントが次のような JSON を送信することで権限昇格が発生しうる。

{
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin"
}

Pentest では、OpenAPI 仕様やレスポンスボディ、開発者向けドキュメントからモデルの構造を推測し、「想定されていないフィールド」を追加したリクエストを送信して挙動を確認する。

Rate Limit 不備

レート制限（Rate Limiting）の不備は、単体では脆弱性と認識されにくいが、他の攻撃（認証試行、スクレイピング、リソース枯渇攻撃など）の実現を容易にする。

代表的なケースは次のとおり。

• 認証エンドポイントに対して無制限にパスワード試行が可能
• ワンタイムコードや SMS の再送要求に制限がなく、ブルートフォースが成立する
• 重い処理（レポート生成、画像変換など）を伴う API に対して、リクエスト数制限がない

Pentest では、テスト環境や同意された条件の範囲で、一定時間内に複数のリクエストを送信し、レスポンスやログから制限の有無を確認する。実務環境では、DoS に該当しないよう、事前に上限や監視方法について合意しておく必要がある。

過剰なデータ露出とフィルタリング不備

API においては、クライアント側で不要なフィールドを単に表示しないだけで、バックエンドからはすべて返却しているケースがある。これにより、次のようなリスクが生じる。

• UI では見えないが、レスポンス JSON には内部 ID や機密情報が含まれている
• クエリパラメータで fields や include を指定することで、非公開属性を取得できる

Pentest では、レスポンス JSON の全体を確認し、ビジネス的に不要な情報が含まれていないかをチェックする。必要であれば、クライアント側のフィルタリングを前提とせず、API レイヤでのデータ最小化を推奨する。

セキュリティ設定不備と API 固有のミスコンフィグ

API ゲートウェイや API Management 製品を利用する場合、設定ミスにより以下のような問題が発生することがある。

• 認証を要するエンドポイントが誤って「公開」扱いになっている
• ステージング用・デバッグ用のエンドポイントが本番環境に残っている
• 古いバージョンの API が意図せず公開されたままになっている

これらは API Security Top 10 の API8: Security Misconfiguration や API9: Improper Inventory Management に該当する。OpenAPI 仕様や DNS、ログを参考に、「存在しているが利用されていないエンドポイント」「ドキュメント外の API」がないかを確認する。

本章のポイント

• BOLA は「ID を隠す」問題ではなく「サーバ側の所有者・権限チェック」問題であり、複数ロールでの差分比較と ID 操作で成立条件を確認する。
• Mass Assignment はバインディング制御の不足で発生するため、仕様・レスポンスから推定したフィールドを追加して挙動を観察する。
• レート制限不備、過剰なデータ露出、設定不備／棚卸し不備は複合的にリスクを高めるため、合意された範囲で負荷に配慮しつつ確認する。

OAuth2 / OIDC / 外部 ID 連携のテスト

title: “OAuth2 / OIDC / 外部 ID 連携のテスト” part: “Part 4” chapter: “4-3”

OAuth2 / OIDC / 外部 ID 連携のテスト

本章では、Part 2 で整理した OAuth2 / OIDC の基礎を前提とし、Pentest におけるテスト観点を整理する。特に、Google などの外部 ID プロバイダと連携するケースを想定する。

本章のゴール

• 前提：OAuth2 / OIDC の基本ロールと Authorization Code + PKCE の流れ（Part 2）を説明できる。
• 到達目標：リダイレクト URI、スコープ、トークン検証、ログアウト／セッション連携などの観点で、実装のリスクを体系的に点検できる。
• 対応演習：OAuth2 / OIDC を利用している演習環境がある場合、認可フローのトラフィックを Burp Suite で観察し、redirect_uri／スコープ／トークンのクレーム検証に関する挙動を整理する。

テスト対象の整理

OAuth2 / OIDC 関連のテストでは、次の対象を明確にする。

• クライアントアプリケーション（Web / モバイル / SPA など）
• 認可サーバ（IdP / Authorization Server）
• リソースサーバ（保護された API）

また、次の情報を事前に確認しておく。

• 利用しているフロー（Authorization Code + PKCE、Client Credentials など）
• クライアント登録情報（クライアント ID、リダイレクト URI、スコープなど）
• トークンの形式（JWT かどうか、署名アルゴリズム）

代表的なテスト観点

OAuth2 / OIDC に関する代表的なテスト観点は以下のとおりである。

• リダイレクト URI の検証
  • プレ登録された URI 以外を許可していないか
  • オープンリダイレクトと組み合わせて認可コードやトークンが奪取されないか
• スコープの適切性
  • 不要に広いスコープ（例：メール・プロフィール以外の権限）が常に付与されていないか
  • クライアントごとに必要最小限のスコープに制限されているか
• トークン検証
  • ID トークン／アクセストークンの署名検証が正しく行われているか
  • iss / aud / exp / iat などのクレームが検証されているか
  • nonce を利用するフローで、リプレイ攻撃防止がなされているか
• ログアウトとセッション連携
  • ログアウト後もトークンが有効なまま残っていないか
  • ブラウザセッションとトークンのライフサイクルが整合しているか

外部 ID プロバイダ連携（例：Google ID）

Google などの外部 ID プロバイダと連携する場合、次のようなリスクが考えられる。

• クライアント側で ID トークンの署名検証を省略している
  • 任意の ID トークンを生成して送信できてしまう
• メールアドレスなどのクレームを安易に信頼している
  • ドメイン検証が不十分で、想定外のユーザが管理権限を取得しうる
• アカウント連携時の確認不足
  • 既存アカウントとの紐付け確認が弱く、別人のアカウントと誤って統合される

Pentest では、ブラウザプロキシや JWT デバッグツールを用いて、ID トークンの内容とサーバ側の検証挙動を観察する。可能であれば、テスト用の IdP 設定（テストクライアント、サンドボックス環境）を利用し、本番アカウントに依存しない形で検証する。

攻撃シナリオ例

OAuth2 / OIDC 関連の脆弱性を報告する際は、次のようなシナリオとして整理すると理解されやすい。

• 攻撃者が特定のリダイレクト URI を悪用し、被害者がログインした際に認可コードを奪取する
• 攻撃者が独自のクライアントから発行したトークンを、別のクライアント向け API に対して利用できてしまう
• 攻撃者がメールアドレスのクレームだけを利用してアカウント連携を行い、組織内の管理者アカウントに不正アクセスする

これらのシナリオに対する対策として、リダイレクト URI の厳格な検証、クライアントごとのスコープ分離、トークン検証ロジックの統一（共通ライブラリの利用など）を推奨する。

本章のポイント

• OAuth2 / OIDC のテストでは、クライアント／認可サーバ／リソースサーバの役割と、採用フロー・トークン形式を先に特定する。
• リダイレクト URI、スコープ、トークン検証（署名、iss / aud / exp / nonce など）、ログアウトとセッション連携を主要な検証観点として整理する。
• 外部 IdP 連携では「クレームの過信」「署名検証の省略」「アカウント連携の確認不足」が典型リスクであり、攻撃シナリオとして報告すると伝達性が高い。

RBAC / ABAC の誤実装パターン

title: “RBAC / ABAC の誤実装パターン” part: “Part 4” chapter: “4-4”

RBAC / ABAC の誤実装パターン

本章では、API における権限管理の代表的なモデルである RBAC（Role-Based Access Control）と ABAC（Attribute-Based Access Control）を前提に、典型的な誤実装パターンと Pentest の検証観点を整理する。

本章のゴール

• 前提：認証と認可の切り分け（Part 2）と、API の典型リスク（BOLA 等）を把握している。
• 到達目標：RBAC / ABAC の誤実装パターンを説明し、複数アカウントでの差分比較を中心にアクセス制御の欠落を検証できる。
• 対応演習：exercises/crapi/ 等で複数ロール／複数ユーザを用意し、同一 API のレスポンス差分を比較して、アクセス制御の成立条件（所有者・ロール・スコープ等）を整理する（起動手順は 付録「演習環境クイックスタート」 を参照）。

RBAC / ABAC の概要

• RBAC（ロールベースアクセス制御）
  ユーザにロール（役割）を付与し、ロールごとに許可される操作を定義するモデル。例：USER、ADMIN、READ_ONLY など。
• ABAC（属性ベースアクセス制御）
  ユーザ属性、リソース属性、環境属性（アクセス元 IP、時間帯など）を組み合わせたポリシーに基づき、アクセス可否を判断するモデル。例：department == "sales" AND resource.owner == user.id など。

実システムでは、RBAC をベースとしつつ、一部の重要操作に ABAC 的条件を追加するハイブリッドな設計も多い。

典型的な誤実装パターン

Pentest で頻出する誤実装パターンには、次のようなものがある。

• クライアント信頼型の権限管理
  • フロントエンドの UI でボタン表示を制御しているだけで、バックエンドでは権限チェックが行われていない
  • トークンやクッキーの中のロール情報を書き換えることで、権限昇格が可能
• 不完全なロールチェック
  • 一部のエンドポイントでは管理者専用のはずが、ロールチェックが実装されていない
  • 新しく追加された API に対し、既存の権限チェックが適用されていない
• コンテキストを考慮しない RBAC
  • ロールだけでアクセス可否を決定し、「自分自身のリソースにのみアクセスできる」という制約がない
  • 結果として、一般ユーザでも他人の情報を参照・更新できてしまう（BOLA と表裏一体）
• ポリシーの複雑化による抜け漏れ
  • 多数のロールや条件が増える中で、否定条件や例外ルールの組み合わせにより意図しない許可が発生する

テスト戦略

RBAC / ABAC を対象とした Pentest では、次の戦略を取ると効率的である。

• シナリオベースでロールと操作を整理する
  • 「一般ユーザが他人の注文を閲覧できない」「営業部だけが特定のレポートを閲覧できる」など、期待されるポリシーをテスト観点としてリスト化する
• 複数アカウントで同一リクエストを再現する
  • Burp のセッション処理や複数ブラウザを活用し、異なるユーザで同一 API を呼び出し、レスポンス差分を比較する
• トークンやクッキーのロール情報を操作する
  • JWT の role / scope クレーム、セッション内のフラグなどを変更し、サーバ側の検証有無を確認する（署名検証が前提）

API Security Top 10 の BOLA / BFLA（Broken Function Level Authorization）などと重ね合わせて評価すると、報告時の整理がしやすい。

改善提案の方向性

Pentest の結果として RBAC / ABAC の問題を報告する際は、単に「権限チェックが不足している」と指摘するだけでなく、次のような改善方向を示すと有用である。

• 権限チェックを共通ミドルウェアやポリシーエンジンに集約し、エンドポイントごとの書き忘れを防ぐ
• ロール表や権限マトリクスを維持し、API 仕様と一貫性を取る（Part 7 のテンプレートと連動）
• JWT 検証やロール評価ロジックをライブラリ化し、各サービスが独自実装しないようにする

これにより、単発の脆弱性修正ではなく、権限管理の仕組みそのものの強化に繋げやすくなる。

本章のポイント

• RBAC / ABAC を前提に、実システムではハイブリッド設計が多いことを踏まえて、権限管理の成立条件を整理する。
• 典型的な誤実装は「クライアント信頼」「エンドポイントごとのチェック漏れ」「所有者などコンテキスト欠落」「ポリシー複雑化による意図しない許可」である。
• テストはシナリオ（期待ポリシー）ベースで観点化し、複数アカウントの差分比較とトークン操作（署名検証が前提）で検証し、改善は権限チェックの集約と運用可能な権限マトリクス整備へ繋げる。

Part 5：モバイル Pentest

title: “モバイル Pentest Part の狙い” part: “Part 5” chapter: “5-0”

Part 5：モバイル Pentest の位置づけ

Part 5 では、Android / iOS アプリケーションを対象としたペネトレーションテストを扱う。

Web / API の基盤（Part 2〜4）を前提としつつ、「クライアントアプリ固有の攻撃面」および「モバイル環境特有のデータ保護・実装ミス」を中心に解説する。

本 Part で扱う主なトピックは次のとおりである。

• モバイル Pentest の前提と環境構築（エミュレータ / 実機、プロキシ設定、証明書インストール）
• MobSF を用いた静的解析／簡易動的解析
• Frida / objection を用いた動的解析・フック
• モバイルアプリにおけるデータ保護（ストレージ、キーチェーン / Keystore、ログ、バックアップ）

ここでは 2024 年時点で一般的なツールバージョン（MobSF 3.x 系、Frida 16.x 前後、objection 最新安定版）を想定するが、具体的なコマンドや UI は将来変更される可能性があるため、原則として「どのような観点で何を確認するか」に重心を置いて記述する。

本 Part を読む前提と対応演習

前提として、以下の状態を想定する。

• Part 2〜4 で Web / API の基礎と Burp Suite の利用に一通り触れている
• Android 端末またはエミュレータの基本操作に慣れている（アプリのインストールやログ確認など）

演習としては、exercises/ 配下に用意するモバイル向けサンプルアプリと MobSF / Frida / objection の組み合わせを利用し、端末内データや通信の観察・保護状況の確認を行う流れを想定する。
執筆時点では Part 5 向け演習は exercises/ に未整備であり、提供状況は exercises/README.md を参照する。

関連資料

• モバイル Pentest チェックリスト（原案）
• 用語集

本章のポイント

• モバイル Pentest は Web / API の前提に加え、クライアントアプリ固有の攻撃面と、端末内データ保護の実装・運用不備を重点的に扱う。
• ツールや UI は将来変化しうるため、バージョン依存の手順よりも「どの観点で何を確認するか」を軸に学習する。
• 環境構築（端末／エミュレータ、プロキシ、証明書、解析ツール）を整え、通信観察とデータ保護の検証を一連の流れとして実施する。

モバイル Pentest の基礎と環境構築

title: “モバイル Pentest の基礎と環境構築” part: “Part 5” chapter: “5-1”

モバイル Pentest の基礎と環境構築

本章では、モバイル Pentest の目的と特徴、および演習・評価に必要となる基本環境の構築方針を整理する。

本章のゴール

• 前提：Part 2〜4 で Web / API の基礎と Burp Suite の利用に触れている。
• 到達目標：モバイル Pentest の評価範囲（通信・端末内データ・耐性）を整理し、端末／エミュレータ、プロキシ、解析ツールを用いた検証環境の構成要素を説明できる。
• 対応演習：検証用の Android 端末／エミュレータでプロキシ設定と CA 証明書インポートを行い、Burp Suite で HTTPS 通信を観測できる状態を作る（対象アプリは演習用を想定する）。

モバイル Pentest の目的

モバイルアプリの Pentest は、単にアプリ単体の脆弱性を探すだけでなく、次の観点を含む。

• アプリとバックエンド API 間の通信が安全に設計・実装されているか
• デバイス上に保存されるデータ（キャッシュ、ログ、設定ファイル等）が適切に保護されているか
• リバースエンジニアリングや動的解析に対する耐性（難読化、root/Jailbreak 検知など）が、想定どおりに機能しているか
• 認証・認可フロー（OAuth2 / OIDC 等）が、クライアント実装の不備により迂回可能になっていないか

Web / API と比較して、クライアント側により多くのロジックや秘密情報が埋め込まれがちな点が、モバイル特有のリスクとなる。

評価対象プラットフォーム

本書では、主に次のプラットフォームを想定する。

• Android アプリ（.apk / .aab）
  Java/Kotlin ベースのネイティブアプリ、および一部のクロスプラットフォームフレームワーク（Flutter など）。
• iOS アプリ（.ipa）
  Swift/Objective-C ベースのアプリ。Jailbreak 環境が前提となるケースが多い。

演習および多くの実務環境では、Android を主対象とし、iOS については設計観点や一部ツールの使い方にフォーカスするケースが多い。

環境構築の基本方針

モバイル Pentest の環境は、おおむね次の要素から構成される。通信経路とデータ保護ポイントを把握するために、図5-1 を参照する。

図5-1: モバイルアプリとバックエンドの構成例

flowchart LR
    UA[ユーザ] --> APP[モバイルアプリ]
    APP --> API[バックエンド API]
    APP --> Store[セキュアストレージ\n(Keystore/Keychain)]
    API --> DB[(データベース)]
    API --> IDP[IdP / OAuth2 Server]

図5-1 では、モバイルアプリからバックエンド API への通信と、端末内の保存領域（セキュアストレージ）を分けて示している。前者はプロキシ観測、後者は端末内データの保護確認というように、評価アプローチが異なる点を意識する。

• テスト端末
  • Android エミュレータ（Android Studio / Genymotion 等）または実機
  • iOS シミュレータ（機能制限あり）または Jailbreak 済み実機
• プロキシ環境
  • Burp Suite 等の HTTP(S) プロキシ
  • 端末にインストールされた Burp の CA 証明書
• 解析ツール
  • MobSF（静的・動的解析用）
  • Frida / objection（ランタイムフック用）

安全性と再現性の観点から、原則として業務用端末や個人端末ではなく、専用の検証用端末／エミュレータを準備することを推奨する。

プロキシ設定のポイント

モバイルアプリとバックエンド API 間の通信を観測するためには、端末側で HTTP(S) プロキシを設定し、Burp などを経由させる必要がある。

• Wi-Fi 設定でプロキシを手動設定し、Burp のアドレス／ポートを指定する
• Burp の CA 証明書を端末にインポートし、「ユーザ証明書」として信頼させる（OS バージョンにより手順が異なる）

近年のアプリでは、証明書ピンニング（特定の証明書または公開鍵のみを信頼する仕組み）が実装されていることが多く、その場合は Frida 等を用いたバイパスが必要となる。証明書ピンニングのバイパス手法は、後述の動的解析章で扱う。

本章のポイント

• モバイル Pentest は、通信の安全性、端末内データ保護、リバースエンジニアリング耐性、クライアント実装起因の認証・認可リスクを統合して評価する。
• 再現性と安全性のため、専用の検証端末／エミュレータ、Burp Suite 等のプロキシ環境、MobSF / Frida / objection を組み合わせた評価環境を前提とする。
• 通信観測にはプロキシ設定と CA 証明書インポートが必要であり、証明書ピンニングがある場合は動的解析によるバイパスを検討する。

MobSF による静的解析

title: “MobSF による静的解析” part: “Part 5” chapter: “5-2”

MobSF による静的解析

MobSF（Mobile Security Framework）は、Android / iOS アプリケーションの静的・動的解析を支援するフレームワークであり、初期評価や自動化されたチェックに適している。本章では、主に静的解析を中心に扱う。

本章のゴール

• 前提：評価対象の APK / IPA と、MobSF を実行できる検証環境が用意されている。
• 到達目標：MobSF のレポートから重点確認項目（マニフェスト、パーミッション、ハードコード、ストレージ利用）を抽出し、後続の手動解析・動的解析の優先度付けに利用できる。
• 対応演習：評価対象アプリを MobSF に投入し、重要度の高い指摘（例：debuggable、クリアテキスト通信許可、ハードコード情報）を中心に確認結果を記録する。

MobSF の位置づけ

MobSF の主な機能は次のとおりである。

• APK / IPA ファイルの解析（パーミッション、マニフェスト、メタデータ）
• 既知の危険な設定や API 使用の検出
• 平文での鍵・トークン・URL などのハードコード検出
• 逆コンパイル結果（Smali / Java / Swift 等）の閲覧

Pentest の観点では、「モバイルアプリの初期リスク評価」として MobSF の静的解析を行い、後続の手動解析や動的解析の優先度付けに利用するのが現実的である。

基本的な利用フロー

MobSF の典型的な利用フローは次のとおりである。

1. MobSF サーバを起動し、Web UI にアクセスする。
2. 対象の APK/IPA ファイルをアップロードする。
3. 自動解析が完了した後、レポート画面で各タブ（マニフェスト、コード、セキュリティ解析結果など）を確認する。

レポートには、多数の項目が列挙されるため、すべてを均等に見るのではなく、実務上重要度の高い項目から確認する。

重点的に確認すべき項目

Android を例に、特に注目すべきポイントは次のとおりである。

• マニフェスト設定
  • android:exported 属性の不適切な設定（外部からのインテント呼び出し）
  • debuggable="true" の有無
  • クリアテキスト通信許可（usesCleartextTraffic="true" 等）
• パーミッション
  • 過剰なパーミッション要求（位置情報、連絡先、ストレージ等）
  • 実際に利用していないパーミッションの存在
• ハードコード情報
  • API キー、秘密鍵、内部 URL、認証情報などが平文で埋め込まれていないか
  • デバッグ用エンドポイントやテスト用サーバの URL
• セキュアストレージの利用有無
  • 機密情報を平文ファイルやプレーンな SharedPreferences に保存していないか

これらの結果は、後続の動的解析でどの機能・領域に注目すべきかを決める材料となる。

MobSF の限界

MobSF は有用だが、次の限界も理解しておく必要がある。

• 難読化されたコードやカスタム暗号化ロジックの解析には限界がある
• 「危険な API の使用」＝「必ずしも脆弱性」とは限らない（コンテキスト依存）
• iOS アプリについては、解析結果の網羅性が Android に比べて制約される場合がある

そのため、MobSF のレポートは「リスク候補の抽出」として利用し、実際の影響や exploitability については手動解析や動的解析で確認する必要がある。

本章のポイント

• MobSF はモバイルアプリの初期リスク評価として有用であり、マニフェスト設定、パーミッション、ハードコード情報、セキュアストレージ利用状況を重点的に確認する。
• レポートは後続の手動解析・動的解析の優先度付けに利用し、「検出＝脆弱性」と短絡せずにコンテキストで評価する。
• 難読化やカスタム実装、iOS の制約などの限界があるため、最終的な影響範囲は追加検証で確定する。

Frida / objection による動的解析

title: “Frida / objection による動的解析” part: “Part 5” chapter: “5-3”

Frida / objection による動的解析

Frida は動的計装フレームワークであり、objection は Frida をラップしてモバイル向けの操作を簡易化したツールである。本章では、これらを用いたモバイルアプリの動的解析と、代表的なユースケース（証明書ピンニングのバイパス、ランタイム検査）を整理する。

本章のゴール

• 前提：検証環境（root / Jailbreak 端末、または Frida Gadget 等）を用意し、本番端末ではなく検証用途に限定して実施する。
• 到達目標：Frida / objection の役割と前提条件を理解し、証明書ピンニングや root 検知などの防御機構の挙動を観察・評価する方針を説明できる。
• 対応演習：演習用アプリを対象に、objection 等で HTTPS 観測を可能にした上で、認証フローや機密データの取り扱いをランタイム観点で確認する。

Frida / objection の役割

• Frida
  • ランタイムで任意のスクリプトを注入し、関数の呼び出しや戻り値をフックできる
  • Android / iOS / Windows など複数プラットフォームに対応
• objection
  • Frida を利用したコマンドラインツール
  • ルート検知バイパス、証明書ピンニング無効化、ファイルシステム探索など、モバイル Pentest によく用いられる操作を提供

Pentest では、アプリが実装している「防御機構そのもの」の動作確認やバイパスに利用される。

動的解析の前提

Frida / objection を利用するには、次の前提条件がある。

• Android
  • root 化端末または Frida Gadget を組み込んだアプリ
  • USB デバッグまたはネットワーク経由での接続
• iOS
  • Jailbreak 環境が一般的
  • Frida サーバのインストール

実務では、社内検証用端末として root / Jailbreak 端末を運用するケースが多い一方で、本番端末に対してこれらの操作を行うことは推奨されない。

代表的なユースケース

Frida / objection を用いた代表的な解析シナリオは次のとおりである。

• 証明書ピンニングのバイパス
  • TLS ハンドシェイク時の検証関数をフックし、常に成功扱いにする
  • これにより、Burp 等のプロキシで HTTPS 通信内容を観測可能にする
• root / Jailbreak 検知のバイパス
  • ルート検知に利用される API 呼び出しをフックし、常に「非 root」と判断させる
• 機密データのトレース
  • 暗号化前後のデータ、トークン、キーなどがメモリ上でどのように扱われているかを観察する

これらは攻撃者も利用しうる手法であるため、「防御者としてどこまで耐性を持たせるか」を設計・評価する上でも重要である。

注意点

Frida / objection を用いた解析は強力だが、次の点に留意する。

• 実機・本番環境での利用は制限し、開発・検証環境に限定する
• アプリのライセンスや利用規約に反しない範囲で実施する
• 不具合やクラッシュを引き起こす可能性があるため、テスト用データでの検証を徹底する

本書の演習では、意図的に防御機構を簡略化したサンプルアプリを用い、Frida / objection の基本操作に慣れることを目標とする。

本章のポイント

• Frida は動的計装、objection はその操作を簡易化するツールであり、防御機構の動作確認やバイパスを含む動的解析に用いる。
• 利用には root / Jailbreak 環境や Frida Gadget などの前提があり、実務では本番端末ではなく検証環境に限定して運用する。
• 証明書ピンニングや root 検知のバイパス、機密データのトレースなどのユースケースを、法令・規約・安全性に配慮しながら実施する。

モバイルデータ保護と検証観点

title: “モバイルデータ保護と検証観点” part: “Part 5” chapter: “5-4”

モバイルデータ保護と検証観点

本章では、モバイルアプリにおけるデータ保護の観点と、Pentest での検証ポイントを整理する。

本章のゴール

• 前提：モバイルアプリの保存先（ファイル、DB、ログ等）と、通信観測の基本（プロキシ／証明書検証）の概念を把握している。
• 到達目標：端末内ストレージ、バックアップ、デバッグ情報、通信保護の観点から、情報漏洩リスクの成立条件を整理し、レポートで説明できる。
• 対応演習：演習用アプリを対象に、端末内に残る情報（トークン、個人情報、ログ等）の有無と保護状況を確認し、影響（紛失・盗難、root/Jailbreak）をシナリオとして整理する。

デバイス上のデータ保護

モバイルアプリは、次のような形でデバイス上にデータを保存する。

• 設定ファイル、SharedPreferences（Android）、UserDefaults（iOS）
• SQLite データベース
• キャッシュファイル、一時ファイル
• ログファイル

Pentest では、これらのファイルに「平文の機密情報」が含まれていないかを確認する。

• 認証情報（ID/パスワード、アクセストークン、リフレッシュトークン）
• 個人情報（氏名、メールアドレス、位置情報など）
• 暗号鍵や秘密鍵

デフォルトストレージに機密情報を保管するのではなく、Android Keystore / iOS Keychain などのセキュアストレージを利用しているかを確認することが重要である。

バックアップとデバッグ情報

バックアップ機能やデバッグ設定により、意図せず機密情報が漏洩するケースもある。

• Android のバックアップ許可設定（android:allowBackup="true"）により、アプリデータがバックアップ経路から取得可能になっていないか
• デバッグログやクラッシュレポートに、機密情報や内部構造が過剰に出力されていないか

MobSF や手動解析を通じて、これらの設定と実際のファイル内容を確認する。

通信の保護

Part 2〜4 で扱ったとおり、モバイルアプリとバックエンド API 間の通信は HTTPS を前提とすべきであり、TLS のバージョンや証明書検証、ピンニングの有無が重要となる。

Pentest では次の点を確認する。

• 平文 HTTP 通信が残っていないか（クリアテキスト通信許可の有無）
• 証明書検証が適切に行われているか（任意の自己署名証明書を受け入れていないか）
• ピンニング実装の有無と、そのバイパス難易度（Frida 等を用いた検証）

モバイル固有リスクとレポーティング

モバイルアプリ特有のリスクは、Web / API の分類だけでは十分に表現しきれない場合がある。レポートでは、次のような観点で整理すると理解されやすい。

• 「端末が紛失・盗難に遭った場合に何が漏れるか」
• 「root / Jailbreak 端末上でアプリが実行された場合、どこまで攻撃を許容するか」
• 「バックエンド API が安全でも、モバイルクライアントの実装によりどのようなリスクが追加されるか」

これらを踏まえ、キーマテリアルの保護、ストレージポリシー、ログポリシー、端末要件（root/Jailbreak 検知の方針）などを、設計と運用の両面で検討することが望ましい。

本章のポイント

• 端末内ストレージ（設定、DB、キャッシュ、ログ）に平文の機密情報が残っていないかを確認し、Keystore / Keychain 等のセキュアストレージ利用を評価する。
• バックアップ許可やデバッグログなどの設定不備が情報漏洩に直結するため、MobSF と手動解析で設定と実データの両面を確認する。
• 通信保護（TLS、証明書検証、ピンニング）と合わせて、紛失・盗難や root/Jailbreak といったモバイル固有の脅威シナリオでリスクを整理する。

Part 6：クラウド・インフラ Pentest

title: “クラウド・インフラ Pentest Part の狙い” part: “Part 6” chapter: “6-0”

Part 6：クラウド・インフラ Pentest の位置づけ

Part 6 では、クラウド（主に AWS）および Linux / コンテナを対象としたペネトレーションテストを扱う。

アプリケーションレイヤだけでなく、基盤レイヤの設計・設定ミスが攻撃チェーン全体に与える影響を理解し、攻撃者視点でどこまで侵害が進みうるかを評価することが目的である。

本 Part で扱う主なトピックは次のとおりである。

• AWS を中心としたクラウド基盤の基本（IAM、VPC、S3 など）と典型的なミスコンフィグ
• SSRF から IMDSv1 への到達、およびクラウド権限侵害への攻撃パス
• Prowler / ScoutSuite 等を用いたクラウドセキュリティ評価
• Linux privilege escalation（権限昇格）の代表的パターン
• Docker / Podman を中心としたコンテナ環境のセキュリティ

クラウドサービスや Linux ディストリビューションは頻繁に更新されるため、本書では特定バージョンに強く依存しない「考え方」と「代表的な手順」に焦点を当てる。

本 Part を読む前提と対応演習

前提として、以下の状態を想定する。

• Part 2〜4 で Web / API の基礎と代表的な脆弱性に触れている
• Linux の基本的なコマンド操作（cd、ls、ログの閲覧など）に慣れている

演習環境としては、exercises/ 配下に Docker ベースの擬似クラウド／インフラ環境を用意し、SSRF を起点とした IMDS へのアクセスや、コンテナ内シェルからの権限昇格の可能性を確認する流れを想定する。
執筆時点では Part 6 向け演習は exercises/ に未整備であり、提供状況は exercises/README.md を参照する。

関連資料

• クラウド構成ミス防止チェックリスト（原案）
• Linux / コンテナ検証事項（原案）
• 用語集

本章のポイント

• クラウド・インフラ Pentest では、基盤レイヤの設計・設定ミスが攻撃チェーン全体に与える影響を、攻撃者視点で評価する。
• AWS 基盤、SSRF→IMDS、クラウド評価ツール、Linux 権限昇格、コンテナ設定といった要素をつなげて「どこまで侵害が進みうるか」を整理する。
• 特定バージョンに依存しない考え方を中心にしつつ、演習は将来的に exercises/ 配下の模擬環境で体験できる形を想定する。

AWS を中心としたクラウド基盤の基礎

title: “AWS を中心としたクラウド基盤の基礎” part: “Part 6” chapter: “6-1”

AWS を中心としたクラウド基盤の基礎

本章では、クラウド Pentest の前提として、AWS を中心としたクラウド基盤の要素（IAM、VPC、S3 など）と、代表的なミスコンフィグのパターンを整理する。

本章のゴール

• 前提：Linux の基本操作に慣れており、Web / API レイヤの代表的リスク（Part 2〜4）を把握している。
• 到達目標：IAM / VPC / S3 / 監査ログの観点で、攻撃チェーンに影響する典型的なミスコンフィグを説明し、評価対象の攻撃面として整理できる。
• 対応演習：模擬・検証環境の範囲で、公開範囲、過剰権限、ネットワーク開放、ログ・監査の状態をチェックリスト化して記録する。

IAM（Identity and Access Management）

IAM は AWS における認証・認可の中核であり、ユーザ、ロール、ポリシーを通じてリソースへのアクセス権限を制御する。

Pentest では、次のような観点が重要となる。

• 最小権限原則に反するポリシー
  • AdministratorAccess 相当の広範な権限が付与されている
  • *:*（全アクション／全リソース）に近いポリシーが存在する
• インラインポリシーや古いロールの棚卸し不足
  • すでに利用されていないロールやユーザに高権限が残存している
• 外部 ID とロール委任
  • 第三者アカウントからの AssumeRole 設定が適切に制限されているか

攻撃者視点では、「一度侵入した環境内でどのロールまで昇格可能か」が焦点となる。Part 6 の後半では、SSRF や IMDSv1 を経由したロール悪用シナリオを扱う。

VPC（Virtual Private Cloud）

VPC は AWS 上の仮想ネットワークであり、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイなどの構成要素を持つ。

典型的なリスク要因は次のとおりである。

• 公開不要なリソースがパブリックサブネットに配置されている
• セキュリティグループやネットワーク ACL が過度に開放されている（0.0.0.0/0 向けの 22/3389 ポート開放など）
• 内部向け管理ポートが VPN や踏み台を経由せずに直接公開されている

図6-1: VPC 内のパブリック / プライベート構成例

図6-1 は、インターネットから到達可能な領域（パブリック）と、原則として直接到達させない領域（プライベート）を分け、セキュリティグループ（SG）の入口条件も合わせて示す。

graph LR
    IGW[Internet Gateway] --- Pub[パブリックサブネット\nWeb/アプリサーバ]
    Nat[NAT Gateway] --- Pri[プライベートサブネット\nアプリ/DB]

    Pub --- SG1[SG: 80/443（Internet から）]
    Pri --- SG2[SG: 5432（アプリから）\nInternet からは不可]

Pentest では、スコーピングと併せて、「どのサブネット／セキュリティグループがテスト対象か」「どこまで到達可能であるべきか」を明確にすることが重要である。

S3（オブジェクトストレージ）

S3 はオブジェクトストレージサービスであり、バケットポリシーや ACL の設定ミスにより情報漏えいが発生しやすいコンポーネントである。

代表的な問題には次のようなものがある。

• 認証なしで読み取り可能なバケット（公開バケット）
• 書き込み可能なバケット（Web シェルやスクリプトのアップロードによる悪用）
• バケット名やオブジェクトキーに機密情報が含まれている

Pentest では、公開範囲の確認とともに、「アプリケーションからどのような権限で S3 にアクセスしているか」を把握し、アプリケーション侵害からの横展開可能性を評価する。

クラウド固有のログと監査

クラウド環境では、CloudTrail、CloudWatch Logs、Config など複数の監査・ログサービスが存在する。Pentest の観点では、次の点を確認する。

• 管理系 API コール（IAM 変更、EC2 操作等）が CloudTrail で記録されているか
• ログの保存期間と保護（削除・改ざんの防止）が適切か
• セキュリティイベント（多重失敗ログイン、異常なリージョンからのアクセス等）に対する検知・アラート設計があるか

これらは直接の「脆弱性」というより、攻撃検知と対応力に関わる要素であり、総合的なリスク評価の一部として扱う。

本章のポイント

• IAM はクラウドの認可の中核であり、過剰権限、棚卸し不足、外部委任の制限不備があると侵害後の権限昇格に直結する。
• VPC とネットワーク制御では、公開不要な配置や過度な開放（0.0.0.0/0 など）が攻撃面を拡大するため、到達可能性とスコープを明確にする。
• S3 の公開・書き込み設定や監査ログ（CloudTrail 等）の整備は、情報漏えいと検知・追跡に関わるため、構成全体のリスクとして評価する。

SSRF から IMDSv1 への攻撃パス

title: “SSRF から IMDSv1 への攻撃パス” part: “Part 6” chapter: “6-2”

SSRF から IMDSv1 への攻撃パス

クラウド環境における SSRF（Server-Side Request Forgery）は、単なる内部ネットワークスキャンに留まらず、メタデータサービス（IMDS）へのアクセスを通じてクラウド権限の奪取に直結する。本章では、特に AWS の IMDSv1 を例に、その攻撃パスを整理する。

本章のゴール

• 前提：SSRF の成立条件（Part 2）と、IMDS の概要（前章）を把握している。
• 到達目標：SSRF→IMDS→クラウド権限侵害の攻撃パスと、防御策（IMDSv2、最小権限、到達制御）および評価時の統制（許可・範囲・キー管理）を説明できる。
• 対応演習：模擬・検証環境に限定し、SSRF で 169.254.169.254 への到達可否を確認する（商用アカウントや本番環境では実施しない）。

図6-2: SSRF から IMDS への攻撃パス（AWS）

graph LR
    A[攻撃者] -->|悪意ある URL を送信| W[Web アプリケーション]
    W -->|SSRF により HTTP リクエスト| M[EC2 内部の IMDS<br/>169.254.169.254]
    M -->|一時認証情報| W
    W -->|取得したクレデンシャルで AWS API 呼び出し| C[(AWS アカウント内リソース)]

図6-2 は、外部からの入力が SSRF を通じて IMDS に到達し、一時認証情報を取得して AWS API を操作するまでの流れを単一のチェーンとして示している。以降は、「SSRF の入力点」「IMDS への到達性」「付与ロールの権限範囲」を分けて整理すると、影響範囲の評価がしやすい。

IMDS（Instance Metadata Service）の概要

AWS EC2 には、インスタンス自身に関するメタデータを取得するためのサービス（IMDS）が用意されている。IMDS は、インスタンス内部からのみアクセス可能な特殊なエンドポイント（http://169.254.169.254/）で提供される。

代表的なメタデータには次のようなものがある。

• インスタンスタイプ、AMI ID、ホスト名など
• アタッチされているロールに紐づく一時的な認証情報（アクセスキー、シークレットキー、セッショントークン）

IMDSv1 では、HTTP 経由でメタデータが取得可能であり、追加のセッションバインディングがないため、SSRF 脆弱性を通じた悪用が容易である。

SSRF を起点とした攻撃シナリオ

典型的なシナリオは次のとおりである。

1. 公開 Web アプリケーションに SSRF 脆弱性が存在し、任意の URL にサーバ側からリクエストを送信できる。
2. 攻撃者は、SSRF を通じて http://169.254.169.254/latest/meta-data/iam/security-credentials/ にアクセスさせる。
3. 取得した認証情報を用いて、AWS API を直接呼び出し、S3、DynamoDB、IAM などのリソースにアクセスする。

この場合、アプリケーションレイヤの脆弱性が、クラウドアカウント全体の侵害に繋がる可能性がある。付与されたロールの権限が大きいほど、影響は深刻になる。

IMDSv2 と防御策

AWS は IMDSv2 を導入し、セッション指向のメタデータ取得方式を提供している。IMDSv2 では、事前にセッショントークンを取得し、それをヘッダに付与してメタデータを取得する必要があるため、一部の SSRF 攻撃を困難にする。

防御策としては次のようなものがある。

• IMDSv1 を無効化し、IMDSv2 のみに制限する
• メタデータサービスへのアクセス権を最小限にする（不要な場合は完全に無効化）
• ロールに付与する権限を最小化し、侵害時の影響範囲を限定する

Pentest の観点では、対象環境が IMDSv1 を許容しているか、IMDSv2 を利用しているかを確認し、SSRF からの到達可能性を評価する。

評価時の注意点

IMDS から取得した認証情報は非常にセンシティブであり、評価時には次の点に注意する。

• 商用の AWS アカウントや本番システムに対して、許可なく IMDS へのアクセスや認証情報の取得を試みてはならない
• 実際の環境で認証情報を取得する場合は、事前にスコーピングと許可を明確にする
• 取得したキーは評価後速やかに破棄し、必要に応じてローテーションを実施してもらう
• 検証は限定的な API コールに留め、リソースの破壊や大量データ取得は行わない

将来的な本書の演習環境では、限定された権限を持つテスト用ロールと IMDSv1 を組み合わせた模擬環境を用い、安全な範囲で攻撃パスを体験できるようにする想定である。

本章のポイント

• クラウド環境の SSRF は、内部到達だけでなく IMDS へのアクセスを通じてクラウド権限の奪取に繋がりうる。
• IMDSv1 はセッションバインディングがなく悪用されやすいため、IMDSv2 への移行と最小権限設計を前提に、到達可能性と影響範囲を評価する。
• 認証情報の取得は高リスクであり、スコーピング・許可・最小限の検証・キー破棄／ローテーションなど運用面の統制を前提とする。

Prowler / ScoutSuite によるクラウド評価

title: “Prowler / ScoutSuite によるクラウド評価” part: “Part 6” chapter: “6-3”

Prowler / ScoutSuite によるクラウド評価

本章では、AWS 環境を中心としたクラウドセキュリティ評価ツールである Prowler と ScoutSuite の概要と、Pentest における活用方法を整理する。ツールのバージョンや対応サービスは頻繁に更新されるため、本書では 2024 年時点の一般的な機能を前提とし、概念レベルで説明する。

本章のゴール

• 前提：クラウド基盤の構成要素（IAM / VPC / S3 等）と、評価目的（攻撃チェーンへの影響）を把握している。
• 到達目標：Prowler / ScoutSuite の出力を「設定の健全性」ではなく「攻撃者の横展開を容易にする要素」として読み替え、優先度を付けて報告できる。
• 対応演習：合意された検証環境でツール出力を確認し、過剰権限・公開設定・監査不足など、影響の大きい指摘を抽出して整理する。

Prowler

Prowler は、AWS や他クラウドに対するセキュリティベースラインチェックツールであり、CIS ベンチマークや各種ベストプラクティスに基づいたチェックを自動で実行する。

代表的なチェック項目は次のとおりである。

• IAM ユーザ／ロールの設定（MFA、有効なアクセスキー、過剰権限など）
• S3 バケットの公開設定
• CloudTrail や Config の有効化状況
• セキュリティグループの開放状況

Pentest の文脈では、Prowler の結果を「クラウド構成の健全性評価」として利用し、アプリケーションレイヤの脆弱性と組み合わせたリスクを整理する。

ScoutSuite

ScoutSuite は、AWS / Azure / GCP など複数クラウドに対応したマルチクラウドセキュリティ評価ツールであり、ブラウザベースのレポートを生成する。

特徴としては次のような点がある。

• 各種サービス（EC2、RDS、IAM、S3 等）の設定状況を一覧化
• リソースごとのリスクと推奨事項を視覚的に表示
• 複数アカウント・リージョンにまたがる構成の俯瞰

Pentest チームとクラウド運用チームが共通のレポートを見ながら議論することで、「どの設定が攻撃チェーンにとって重要か」を合意しやすくなる。

単一クラウド（特に AWS）の CIS 準拠状況を手早く確認したい場合は Prowler が有用であり、マルチクラウド環境全体の構成を俯瞰しながら議論したい場合は ScoutSuite が有用である。本書では両者のいずれか一方に依存することを意図しておらず、評価目的や組織の環境に応じて使い分けることを前提とする。

ツール利用時の考慮事項

これらのツールは強力だが、次の点に注意する必要がある。

• 実行には対象アカウントの認証情報（アクセスキーやロール）が必要であり、事前の合意とアクセス制御が必須
• 出力結果は膨大になりがちで、すべてを Pentest の範囲で扱うことは現実的でない
• ベストプラクティスからの逸脱が「必ずしも直ちに exploitable な脆弱性」とは限らない

Pentest では、「アプリケーションからの侵害を前提として利用されうる設定」や「攻撃者の横展開を容易にする設定」にフォーカスして、優先度を付けて報告することが重要である。

本章のポイント

• Prowler はベースライン（CIS 等）確認、ScoutSuite は構成の俯瞰とレポーティングに強みがあり、目的と環境に応じて使い分ける。
• ツール結果は運用チームとの共通言語として有用だが、出力が膨大になりやすいため、攻撃チェーンに効く設定に焦点を当てて整理する。
• 認証情報の扱い、事前合意、アクセス制御を前提にしつつ、ベストプラクティス逸脱を機械的に「脆弱性」と断定せずに評価する。

Linux 権限昇格とコンテナセキュリティ

title: “Linux 権限昇格とコンテナセキュリティ” part: “Part 6” chapter: “6-4”

Linux 権限昇格とコンテナセキュリティ

本章では、サーバ側で一般ユーザ権限を取得した後の Linux privilege escalation（権限昇格）と、Docker / Podman を中心としたコンテナ環境の典型的なリスクを整理する。

本章のゴール

• 前提：Linux の基本コマンドで情報収集でき、Web / API 侵害後の横展開シナリオとして位置づけて評価できる。
• 到達目標：権限昇格の代表的パターン（SUID/SGID、sudo、権限、カーネル）と、コンテナ設定ミスによるホスト侵害リスクを説明し、優先度付けできる。
• 対応演習：模擬・検証環境で sudo -l や権限確認を実施し、コンテナ設定（--privileged、docker.sock 等）のリスク要因を洗い出して記録する。

Linux 権限昇格の代表的パターン

Linux 権限昇格の代表的な攻撃パターンには次のようなものがある。

• SUID/SGID バイナリの悪用
  • root 所有かつ SUID ビットが立っているバイナリを利用し、任意コマンド実行やシェル取得を行う
• 不適切な sudo 設定
  • パスワードなしで実行可能なコマンドや、任意のエディタ／インタプリタを介した権限昇格
• 権限の緩いファイル／ディレクトリ
  • /etc/passwd やサービス設定ファイルへの書き込み権限が一般ユーザに付与されている
• 古いカーネルや特権昇格脆弱性
  • 既知のローカル権限昇格脆弱性（例：Dirty COW 等）が適用されていないカーネル

Pentest では、sudo -l、find、ls -la、uname -a などの基本コマンドを通じて情報を収集し、既知のテクニック集（GTFOBins 等）と照らし合わせながら攻撃面を特定する。

コンテナ環境のリスク

Docker / Podman 等のコンテナ環境では、ホストとコンテナ間の隔離が前提となる一方で、設定ミスによりホスト侵害に繋がるケースがある。

代表的なリスクには次のようなものがある。

• 特権コンテナ（--privileged）
  • ホストのデバイスやカーネル機能に広範なアクセスを持ち、コンテナからホストへのエスケープリスクが高まる
• /var/run/docker.sock のマウント
  • コンテナ内から Docker デーモンにアクセスできる場合、任意コンテナの起動を通じてホスト権限取得が可能となる
• ホストファイルシステムの過剰なマウント
  • / や /etc を読み書き可能なボリュームとしてマウントしている

図6-3: コンテナ環境のレイヤ構造

flowchart TB
    HW[ハードウェア] --> HostOS[ホスト OS]
    HostOS --> Engine[Docker / Podman エンジン]
    Engine --> C1[コンテナ1\nWeb]
    Engine --> C2[コンテナ2\nAPI]
    Engine --> C3[コンテナ3\nDB]

図6-3 のように、ホスト OS / コンテナエンジン / 各コンテナのレイヤを分け、設定ミスがどの境界を弱めるかを意識しながら構成を確認することが重要である。

これらは「設計上の便利さ」を優先した結果として導入されることが多く、Pentest では構成ファイルや実行中コンテナの設定を確認することで発見できる。

Pentest におけるアプローチ

Linux / コンテナ環境の Pentest では、次のようなアプローチが現実的である。

• Web / API レイヤから侵入後の「横展開シナリオ」として位置づける
  • 例：Web アプリから OS コマンドインジェクション → コンテナ内シェル取得 → ホストへのエスケープ可否を評価
• メタデータやクラウドロールとの組み合わせを評価する
  • コンテナ内から IMDS へのアクセス可否、AWS SDK の利用状況を確認
• 最小権限と分離の観点で設計をレビューする
  • root コンテナの利用有無、ユーザ名前空間・ネットワーク名前空間の設定など

将来的な本書の演習環境では、意図的に脆弱な Linux / コンテナ構成を準備し、Web レイヤの侵害からクラウド／ホスト権限昇格までの流れを体験できるようにする想定である。

本章のポイント

• Linux 権限昇格では、SUID/SGID、sudo 設定、ファイル権限、カーネル脆弱性の観点で情報収集し、成立条件を絞り込む。
• コンテナは隔離が前提だが、特権コンテナ、docker.sock マウント、過剰なホストマウントなどの設定ミスでホスト侵害に繋がりうる。
• Web / API 侵害後の横展開シナリオとして、IMDS への到達やクラウドロールとの組み合わせも含めて評価し、最小権限と分離の観点で改善提案へ繋げる。

Part 7：総合演習

title: “総合演習 Part の狙い” part: “Part 7” chapter: “7-0”

Part 7：総合演習（1週間カリキュラム）

Part 7 では、本書で扱った Web / API / モバイル / クラウド / インフラの要素を統合し、1 週間程度の総合演習としてまとめる。目的は、個別技術の習得に留まらず、「スコーピング → 情報収集 → 攻撃チェーン構築 → 権限昇格 → レポート作成」という一連の流れを、実務に近い形で体験することである。

本 Part で扱う主なテーマは次のとおりである。

• 演習シナリオと環境の設計（複数コンポーネントを含む模擬システム）
• スコーピングとテスト計画の策定
• 情報収集と脆弱性発見、攻撃チェーンの構築
• 権限昇格とクラウド／インフラへの横展開
• レポート作成と振り返り

ここでの総合演習は、本書の集大成として位置づけられ、社内研修や外部トレーニングでそのまま流用できることを意図して構成する。

1週間カリキュラムのイメージ

総合演習は、おおむね次のような時間配分を想定する。

• 1日目：スコーピングとテスト計画の策定
• 2〜3日目：Web / API を中心とした初期侵入と攻撃面の把握
• 4日目：クラウド / インフラ（Linux / コンテナ）への横展開と権限昇格
• 5日目：攻撃チェーンの整理とレポート作成、振り返り

実際の研修では、参加者の経験や利用可能な時間に応じて調整してよいが、本書では上記の流れを標準パターンとして想定する。

対応演習と提供状況

総合演習で利用する環境は、複数コンポーネントを含む模擬システムを想定する。
執筆時点では Part 7 向け演習は exercises/ に未整備であり、提供状況は exercises/README.md を参照する。

関連資料

• テスト計画書テンプレート（Pentest）
• Pentest レポートテンプレート
• Web Pentest チェックリスト（原案）
• API Security チェックリスト（原案）
• OAuth2 / OIDC テスト項目表（原案）
• モバイル Pentest チェックリスト（原案）
• クラウド構成ミス防止チェックリスト（原案）
• Linux / コンテナ検証事項（原案）
• 用語集

本章のポイント

• Part 7 は、本書の各レイヤ（Web / API / モバイル / クラウド / インフラ）を統合し、スコーピングからレポートまでの一連プロセスを実務に近い形で体験することを目的とする。
• 目標は個別テクニックの列挙ではなく、攻撃チェーン構築と影響評価を通じて、再現可能な成果物として残すことである。
• 1 週間カリキュラムは標準パターンとして提示し、研修の制約（参加者経験、時間）に応じて調整できる前提で設計する。

演習環境とシナリオ設計

title: “演習環境とシナリオ設計” part: “Part 7” chapter: “7-1”

演習環境とシナリオ設計

本章では、総合演習で利用する環境とシナリオの例を示す。実際の構築手順や Docker Compose ファイル等は exercises/ ディレクトリ側で扱い、本章では「どのような構成要素があり、何を学ぶための環境か」を整理する。

本章のゴール

• 前提：Part 1〜6 で扱った各レイヤ（Web / API / モバイル / クラウド / インフラ）の攻撃面と、総合演習の目的を把握している。
• 到達目標：演習環境の構成要素と学習ゴールを明確化し、総合演習が「攻撃チェーンの構築」と「成果物作成」に接続するよう設計できる。
• 対応演習：既存の exercises/（例：dvwa / juice-shop / crapi）を前提に、演習対象コンポーネントと評価範囲、期待成果物を文書化する（起動手順は 付録「演習環境クイックスタート」 を参照）。

想定する演習環境の構成（例）

以下は、1 週間の総合演習で利用する模擬システム構成の一例である。

• Web フロントエンド
  • 脆弱な Web アプリ（例：Juice Shop または自作アプリ）
  • 認証機能、商品閲覧・購入機能、管理画面を含む
• バックエンド API
  • REST ベースの API（ユーザ情報、注文情報、管理 API 等）
  • JWT ベースの認証、RBAC による権限管理
• モバイルクライアント（オプション）
  • 上記 API を利用する Android アプリ（演習用簡易クライアント）
• クラウド／インフラ
  • Docker ベースの擬似クラウド環境（本番ではなくローカルで完結）
  • Web / API / DB / ログサーバなど複数コンテナで構成

これらを docker-compose 等で一括起動できるようにし、受講者が自身のマシン上で環境を再現可能とする。

学習ゴールの明確化

演習開始時に、次のような学習ゴールを明示しておく。

• Web / API / モバイル / クラウド／インフラの各レイヤで、少なくとも 1 つ以上の脆弱性を発見し、PoC を作成する
• Kill Chain や MITRE ATT&CK 等のモデルに基づき、攻撃チェーン全体を説明できる
• テスト計画書とレポートテンプレートを用いて、再現可能な形で成果を残す

ゴールが曖昧だと、演習が個々のテクニック集に分解されてしまうため、事前の合意が重要である。

本章のポイント

• 演習環境は Web、API、（任意で）モバイル、クラウド／インフラの複数コンポーネントで構成し、docker-compose 等で再現可能にする。
• 本章は環境の構築手順ではなく、「構成要素」と「学習目的」を整理し、具体物（Docker Compose 等）は exercises/ 側で管理する。
• 学習ゴール（脆弱性発見と PoC、攻撃チェーン説明、テンプレートに基づく成果物）を開始時に明確化し、演習の焦点を維持する。

スコーピングとテスト計画

title: “スコーピングとテスト計画” part: “Part 7” chapter: “7-2”

スコーピングとテスト計画

本章では、総合演習におけるスコーピングとテスト計画の策定方法を扱う。これは、実務で Pentest を実施する際の最初のステップに相当する。

本章のゴール

• 前提：スコープ合意の重要性（法的・安全面の制約を含む）を理解している。
• 到達目標：対象範囲・許可手法・期間・成果物を明文化し、標準（ASVS / WSTG / API Security Top 10 等）と対応付けたテスト計画に落とし込める。
• 対応演習：付録『テスト計画書テンプレート（Pentest）』をベースに、演習用のスコーピングシートとテスト計画書を作成する。

スコーピングの要素

スコーピングでは、少なくとも次の要素を明確にする。

• 対象システムの範囲
  • ドメイン、IP アドレス範囲、クラウドアカウント、VPC 等
  • 本演習では、Docker 上の疑似環境に限定
• 許可された攻撃手法
  • DoS に相当する負荷試験の有無
  • ソーシャルエンジニアリングや物理的侵入の有無
• 実施期間と時間帯
  • 1 週間カリキュラム内での実施日程、各日の作業時間
• 成果物の定義
  • 最低限作成すべきレポート、PoC、ログ類

演習では、これらをテンプレート化した「スコーピングシート」として配布し、参加者が自ら記入する形式とすると、実務への転用が容易になる。

テスト計画の立案

スコーピングを踏まえ、テスト計画書を作成する。典型的な項目は次のとおりである。

• テスト目的と背景
• 利用する標準（OWASP ASVS / WSTG / API Security Top 10 等）
• テスト対象コンポーネントごとの観点（Web、API、モバイル、クラウド、Linux/コンテナ）
• 使用ツール（Burp Suite、MobSF、Frida、Prowler、ScoutSuite 等）
• スケジュール（1 週間の中での配分）

演習では、「計画と実際の乖離」を振り返りに活用するため、計画書を単なる形式ではなく、実際の進行管理に使うことを推奨する。

本章のポイント

• スコーピングでは、対象範囲、許可手法（DoS 等）、期間、成果物を明確化し、テンプレート化したシートで合意形成を行う。
• テスト計画は、目的、参照標準、コンポーネント別観点、使用ツール、スケジュールを整理し、1 週間の進行に落とし込む。
• 計画書は「形式」ではなく進行管理と振り返りの入力として利用し、実施結果との乖離を分析できる状態にする。

評価実施と攻撃チェーンの構築

title: “評価実施と攻撃チェーンの構築” part: “Part 7” chapter: “7-3”

評価実施と攻撃チェーンの構築

本章では、計画に基づいた評価実施と、発見した脆弱性を攻撃チェーンとして整理する方法を扱う。

本章のゴール

• 前提：スコーピングとテスト計画（前章）が合意済みであり、評価対象環境が準備されている。
• 到達目標：情報収集→初期侵入→横展開→攻撃チェーン可視化の流れで評価を進め、再現性のある証拠と説明可能なストーリーとして整理できる。
• 対応演習：exercises/ の演習環境を対象に、少なくとも 1 本の攻撃チェーン（例：Web → API → クラウド）を構築し、図と根拠（リクエスト／レスポンス等）を記録する（起動手順は 付録「演習環境クイックスタート」 を参照）。

総合演習における各ステップは、Part 1〜6 で扱った内容と次のように対応する。

• スコーピングとテスト計画：Part 1（攻撃モデル・リスク評価）、Part 7（テスト計画テンプレート）
• Web / API 初期侵入：Part 2（Web セキュリティ基盤）、Part 3（Burp Suite）、Part 4（API / 認証・認可）
• モバイル観点の確認（必要に応じて）：Part 5（モバイル Pentest）
• クラウド / インフラへの横展開と権限昇格：Part 6（クラウド・Linux / コンテナ）
• レポート作成と振り返り：Part 3（レポート作成）、Part 7（レポートテンプレートとレトロスペクティブ）

1. 情報収集と初期侵入

Part 3 で扱った Web Pentest ワークフローを適用し、次のステップを踏む。

• Burp Suite を用いたサイトマップ作成とアタックサーフェスの把握
• 認証・セッション管理・アクセス制御の確認
• 代表的な脆弱性（XSS、SQL インジェクション、IDOR / BOLA 等）の有無を調査

初期侵入の段階では、過度な横展開に進まず、まずは「信頼できる 1 つの攻撃ベクトル」を確保することに集中する。

2. 横展開と権限昇格

初期侵入後は、Part 4〜6 の内容を踏まえ、次のような横展開シナリオを検討する。

• API 経由で他ユーザデータへのアクセス（BOLA）
  • 発見した IDOR / BOLA を起点に、管理者データや機密情報への到達可否を確認
• SSRF を通じた内部リソースやメタデータサービスへのアクセス
  • IMDSv1 への到達とクラウドロールの悪用可能性（演習環境に限定）
• Linux / コンテナ環境での権限昇格
  • コンテナ内シェル取得後、ホストへのエスケープ可否を評価

これらは「すべて実行する」ことが目的ではなく、少なくとも 1 つ以上の実行可能な攻撃チェーン（例：Web → API → クラウド）のストーリーを構築することを狙いとする。

3. 攻撃チェーンの可視化

発見した脆弱性がバラバラのリストにならないよう、Kill Chain や MITRE ATT&CK マトリクスを参照しながら、攻撃チェーンを可視化する。

図7-1: 攻撃チェーン例（Web → クラウド）

flowchart LR
    R[Reconnaissance<br/>情報収集] --> E[Exploitation<br/>Web 脆弱性悪用]
    E --> L[Lateral Movement<br/>API / BOLA]
    L --> S[SSRF → IMDS]
    S --> C[Cloud Privilege Escalation<br/>クラウド権限昇格]
    C --> AO[Actions on Objectives<br/>データ窃取等]

図7-1 は、個々の発見事項を「次の段階への足場」としてつなぎ、評価結果を攻撃チェーンとして説明するための例である。以降は、各ステップの根拠（リクエスト／レスポンス、設定値、ログ等）を残し、チェーン全体として再現可能にすることを意識する。

• 各ステップで利用した脆弱性・ミスコンフィグを整理
• 「どの段階で検知・遮断できたか／できなかったか」をまとめる
• 防御側の想定（設計時の前提）とのギャップを明確にする

演習では、簡易な図（DFD やシーケンス図）を用いて攻撃チェーンを図示することを推奨する。

本章のポイント

• Part 1〜6 の内容を前提に、情報収集→初期侵入→横展開→可視化という流れで総合演習を進める。
• 初期侵入では「信頼できる 1 つの攻撃ベクトル」を確保し、横展開は BOLA、SSRF→IMDS、Linux / コンテナ権限昇格などから少なくとも 1 本の攻撃チェーンを成立させる。
• 攻撃チェーンは Kill Chain / MITRE ATT&CK と図（DFD 等）で整理し、脆弱性の列挙ではなくストーリーとして説明可能にする。

レポート作成と振り返り

title: “レポート作成と振り返り” part: “Part 7” chapter: “7-4”

レポート作成と振り返り

本章では、総合演習の成果をレポートとしてまとめ、今後の改善に繋げるための振り返り方法を示す。

本章のゴール

• 前提：発見事項と攻撃チェーンが整理され、再現手順と証拠が揃っている。
• 到達目標：演習版レポートをテンプレートに沿って作成し、技術・プロセス・組織観点の振り返りに接続できる。
• 対応演習：付録『Pentest レポートテンプレート』をベースにレポートを作成し、レトロスペクティブの観点で次アクションを決める。

レポートの構成（演習版）

Part 3 で示したレポート構成をベースに、演習用に次のような項目を含める。

• エグゼクティブサマリ
  • 演習環境の概要、実施期間、主な攻撃チェーンとリスク
• 評価範囲と前提条件
  • スコーピング結果、テスト計画の要点、利用したツール
• 発見事項一覧
  • 脆弱性／ミスコンフィグごとに、概要・影響度・再現手順・証拠・推奨対策
• 攻撃チェーンのまとめ
  • 図やテキストでの攻撃シナリオの説明
• 学習ポイントと今後のアクション
  • チームとして強化すべき領域、プロセス改善案

付録『Pentest レポートテンプレート』に、これに対応する Markdown テンプレートを用意し、演習参加者が直接記入できる形とする。

振り返り（レトロスペクティブ）

演習終了後には、次の観点での振り返りを行う。

• 技術的観点
  • どのレイヤ（Web / API / モバイル / クラウド / インフラ）で弱点が多かったか
  • どのツールやテクニックの習熟が不足していたか
• プロセス観点
  • スコーピングや計画が現実に即していたか
  • チーム内の役割分担やコミュニケーションに課題はなかったか
• 組織的観点（実務への転用）
  • 実際のプロジェクトに適用する際の障壁（工数、権限、文化など）
  • トレーニングを継続するための仕組み（定期的な演習、CTF、勉強会等）

本書の目標は、単に「演習を完了すること」ではなく、「演習を通じて組織のセキュリティケイパビリティを継続的に向上させるための基盤」を提供することである。

本章のポイント

• 演習版レポートは、エグゼクティブサマリ、スコープ・前提、発見事項、攻撃チェーン、学習ポイントとアクションを含め、再現可能性を担保する。
• 付録のテンプレート（例：『Pentest レポートテンプレート』）を用いて成果物を標準化し、受講者が記入して提出できる運用を前提にする。
• 振り返りは技術・プロセス・組織の 3 観点で実施し、継続的なトレーニングと改善サイクルに接続する。

用語集

本書で使用する用語のうち、初学者が混乱しやすいものを抜粋して整理する。完全な網羅ではない。

一般

• Pentest（penetration test）
  攻撃者の視点で対象システムを評価し、脆弱性の有無や影響範囲を確認する活動。本書では、許可された範囲（スコープ）内で実施することを前提とする。
• 脆弱性診断（Vulnerability Assessment）
  脆弱性の有無を中心に確認する評価。本書では、Pentest と脆弱性診断の差分（目的、合意、手法、報告の粒度）を Part 0 で整理する。
• スコープ（Scope）
  評価対象・評価手法・禁止事項など、評価の前提条件の合意。Pentest では安全性と法的観点から最重要の前提となる。
• DoS（Denial of Service）
  サービス停止（または性能劣化）を目的とする攻撃。本書では、DoS 相当の負荷試験を実施するかはスコープで事前に合意する前提とする。
• アタックサーフェス（Attack Surface）
  攻撃可能性がある入口（公開 URL、API、認証フロー、管理画面、外部連携、クラウド設定など）の集合。テスト計画・優先度付けの起点となる。
• PoC（Proof of Concept）
  脆弱性が成立することを示す最小限の再現手順。実務では「影響を過度に拡大しない」範囲で作る。
• ミスコンフィグ（Misconfiguration）
  設定不備（例：アクセス制御の過度な開放、不要な権限付与、公開範囲の誤り）。アプリの実装脆弱性と同様に重大なリスク要因となる。

環境・運用

• VPN（Virtual Private Network）
  通信経路を論理的に分離・保護するための仕組み。本書では、脆弱な演習環境を業務ネットワークから分離する文脈で言及する。
• WSL2（Windows Subsystem for Linux 2）
  Windows 上で Linux 環境を利用する仕組み。本書では、Windows 利用時の演習環境として推奨構成の一例として言及する。
• MFA（Multi-Factor Authentication）
  パスワードに加えて別要素（例：ワンタイムコード等）を要求する認証方式。不正利用やアカウント乗っ取りのリスク低減に有用である。
• SOC（Security Operations Center）/ CSIRT（Computer Security Incident Response Team）
  セキュリティ監視・インシデント対応を担う組織／チーム。本書では、検知・対応側との連携先の例として言及する。

攻撃モデル・リスク評価

• Cyber Kill Chain
  攻撃を複数フェーズに分解して整理するモデル。本書では「攻撃チェーンの可視化」に利用する。
• MITRE ATT&CK
  実攻撃に基づく戦術（Tactic）・技術（Technique）のナレッジベース。本書ではテスト観点の共通言語として利用する。
• STRIDE
  脅威を 6 カテゴリ（Spoofing/Tampering/Repudiation/Information Disclosure/Denial of Service/Elevation of Privilege）に分類するフレームワーク。本書ではスコープ検討・設計段階の抜け漏れ防止に利用する。
• DREAD
  リスク評価の観点（Damage/Reproducibility/Exploitability/Affected Users/Discoverability）を整理する枠組み。本書では「優先度付け」の一例として扱う。
• CVSS（Common Vulnerability Scoring System）
  脆弱性の深刻度をスコアとして表現する仕組み。本書では DREAD と併用する例として言及する。
• DFD（Data Flow Diagram）
  データの流れを可視化する図。STRIDE の適用対象（コンポーネント）を明確にする際に有用である。

標準・ガイドライン

• OWASP（Open Worldwide Application Security Project）
  Web アプリケーションセキュリティに関するガイドラインやツールを公開するコミュニティ。本書では ASVS / WSTG / Top 10 などを参照する。
• OWASP Top 10
  Web アプリケーションの代表的リスクを分類したリスト。コミュニケーションや優先度付けの入口として利用される。
• OWASP API Security Top 10
  API の代表的リスクを分類したリスト。BOLA / BFLA などのカテゴリを含む。
• ASVS（Application Security Verification Standard）
  Web アプリケーションのセキュリティ要件（何を満たすべきか）を体系化した標準。本書ではスコーピング、テスト設計、報告の対応付けに利用する。
• WSTG（Web Security Testing Guide）
  Web アプリケーションのテスト手順（どのように検証するか）を体系化したガイド。本書では具体的な検証手順の参照として利用する。
• CIS ベンチマーク（CIS Benchmarks）
  OS やクラウドサービス等のセキュリティベースラインを示すベンチマーク。本書ではクラウド設定評価の背景知識として言及する。

Web / API セキュリティ

• HTTP
  リクエスト／レスポンスで通信するプロトコル。Pentest ではヘッダ・メソッド・ボディを読み解くことが前提となる。
• HTTPS
  HTTP を TLS で保護したもの。本書では、プロキシによる HTTPS 復号（許可された範囲での観測）などの前提として扱う。
• CA（Certificate Authority）
  証明書を発行する認証局。本書では、Burp Suite の CA 証明書をブラウザ／端末にインポートして HTTPS 通信を観測する文脈で言及する。
• Cookie
  ブラウザの状態管理に利用される仕組み。属性（Secure、HttpOnly、SameSite 等）がセキュリティに直結する。
• セッション（Session）
  認証状態などの「継続状態」を管理する仕組み。Cookie などと組み合わせて実現されることが多い。
• CSRF（Cross-Site Request Forgery）
  ブラウザが Cookie を自動送信する性質を悪用し、ユーザの意図しない操作を成立させる攻撃。
• XSS（Cross-Site Scripting）
  Web ページ上で攻撃者が用意したスクリプトが実行される状態。セッション情報の窃取や操作の自動化などに繋がる。
• CORS（Cross-Origin Resource Sharing）
  ブラウザの同一生成元ポリシー（SOP）を補完し、クロスオリジンのアクセス許可を制御する仕組み。誤設定は情報漏えいの増幅要因となる。
• SOP（Same-Origin Policy）
  ブラウザが異なるオリジン間の読み取りアクセスを制限するポリシー。CORS は SOP の例外を安全に許可するための仕組みである。
• SameSite
  クロスサイト環境で Cookie を送信する条件を制御する属性。CSRF リスクに関係する。
• SQL インジェクション（SQL Injection）
  入力値がクエリ構築に混入し、意図しない SQL が実行される状態。DB の情報漏えい・改ざんに繋がる。
• IDOR（Insecure Direct Object Reference）
  参照 ID を変更することで他者のリソースにアクセスできる状態。API 文脈では BOLA と近い意味で扱われることが多い。
• BOLA（Broken Object Level Authorization）
  オブジェクト単位の認可が破綻し、他者のオブジェクトにアクセスできる状態。API Security Top 10 で最重要のクラスとして扱われる。
• BFLA（Broken Function Level Authorization）
  機能（エンドポイント）レベルの認可が破綻し、本来許可されない操作（例：管理者専用 API）が実行できてしまう状態。
• RBAC（Role-Based Access Control）/ ABAC（Attribute-Based Access Control）
  RBAC はロール（役割）に基づいて許可を決めるモデル、ABAC はユーザ属性・リソース属性・環境属性などの条件に基づいて許可を決めるモデル。アクセス制御の設計・検証の前提となる。
• Mass Assignment
  リクエストボディの想定外フィールドがサーバ側オブジェクトに自動バインディングされ、権限昇格や設定改変に繋がる状態。
• Rate Limit（レート制限）
  一定時間あたりのリクエスト数などを制限する仕組み。認証試行や列挙攻撃への対策として重要である。
• REST（Representational State Transfer）
  Web API 設計の代表的なスタイルの一つ。本書では REST API を中心に扱い、必要に応じて GraphQL にも言及する。
• OpenAPI（Swagger）
  API の仕様（エンドポイント、スキーマ、認証スキーム等）を機械可読で記述する形式。攻撃面の抽出・テスト設計に利用できる。
• GraphQL
  API のクエリ言語／実行基盤の一つ。クライアントが取得フィールドや関連データをクエリで指定できる点が特徴である。

JWT / OAuth2 / OIDC

• JWT（JSON Web Token）
  ヘッダ・ペイロード・署名（または暗号化）からなるトークン形式。クレーム検証と署名検証が焦点となる。
• クレーム（Claims）
  トークン内の属性情報（例：iss、aud、sub、exp）。信頼境界と検証条件を明確にする必要がある。
• OAuth2
  認可のフレームワーク。クライアント、認可サーバ、リソースサーバ等のロールが登場する。
• OIDC（OpenID Connect）
  OAuth2 をベースとした認証レイヤ。ID トークン（通常 JWT）を定義する。
• IdP（Identity Provider）
  認証情報を管理し、認証結果（例：OIDC の ID トークン発行など）を提供する主体。OAuth2 / OIDC の文脈では認可サーバとして実装されることが多い。
• 認可サーバ（Authorization Server）
  クライアントに対して認可コードやトークンを発行するサーバ。OIDC では認証（ID トークン発行）も担う。
• リソースサーバ（Resource Server）
  保護された API を提供し、アクセストークン等を検証してアクセス制御を行うサーバ。
• 認証（Authentication）/ 認可（Authorization）
  「誰であるか」を確認するのが認証、「何をしてよいか」を制御するのが認可。本書では混同しないことを重視する。
• Authorization Code フロー
  認可コードを経由してトークンを取得する代表的フロー。本書では主にこのフロー（PKCE を含む）を前提とする。
• PKCE（Proof Key for Code Exchange）
  認可コードの奪取に対する保護を強化する仕組み。特に公開クライアント（SPA/モバイル）で重要となる。
• アクセストークン（Access Token）
  リソースサーバに対する API アクセスに用いるトークン。権限（スコープ）と有効期限の設計が重要である。
• ID トークン（ID Token）
  認証結果（ID）を表現するトークン。クレーム（iss/aud/nonce 等）の検証が焦点となる。
• スコープ（Scope）
  トークンに紐づく権限範囲。過剰権限は API 側のリスクに直結する。
• リダイレクト URI（redirect_uri）
  認可サーバが応答を返す先。検証不備は認可コード／トークンの奪取に繋がる。

クラウド・インフラ

• AWS
  クラウドサービス。本書では IAM/VPC/S3/IMDS を中心に扱う。
• IAM（Identity and Access Management）
  AWS の認証・認可の中核。ユーザ／ロール／ポリシーにより権限を制御する。
• VPC（Virtual Private Cloud）
  AWS 上の仮想ネットワーク。サブネット、ルート、IGW/NAT、セキュリティグループ等で構成される。
• S3
  オブジェクトストレージ。公開設定やアクセス制御の誤りが情報漏えいに直結する。
• SSRF（Server-Side Request Forgery）
  サーバ側から任意の URL にリクエストできる状態。クラウド環境では IMDS 到達を通じて権限奪取に繋がりうる。
• IMDS（Instance Metadata Service）
  EC2 内部から到達できるメタデータ取得機構。IMDSv1 は SSRF から悪用されやすい。
• コンテナ
  アプリケーション実行環境の分離手法。設定ミス（特権付与、ソケット公開等）がホスト侵害に繋がる場合がある。
• --privileged
  Docker の特権コンテナ。隔離が弱まり、ホストへのエスケープリスクが高まる。
• /var/run/docker.sock
  Docker デーモンの制御ソケット。コンテナ内から操作できると、ホスト権限取得に繋がりうる。
• SUID/SGID
  実行時の権限を昇格させる Unix パーミッション。誤設定はローカル権限昇格に利用されうる。
• sudo
  特定コマンドの権限昇格を許可する仕組み。不適切な許可設定は権限昇格に直結する。

ツール（本書で言及する代表例）

• Burp Suite
  Web/API を対象としたプロキシ型テストプラットフォーム。Proxy/Target/Repeater/Intruder などのコンポーネントを利用する。
• OWASP ZAP
  Web/API を対象としたオープンソースのプロキシ型テストツール。Burp Suite の代替として言及する。
• PortSwigger Web Security Academy（Burp Academy）
  Web セキュリティ学習プラットフォーム。本書では Burp Suite を用いたハンズオンの参照先として言及する。
• MobSF
  モバイルアプリ（Android/iOS）の静的・動的解析に利用されるツール。本書ではモバイル Pentest の導入として扱う。
• Frida / objection
  アプリのランタイムにフックして挙動を観測・改変するためのツール。証明書ピンニングの検証などで利用される。
• Prowler / ScoutSuite
  クラウド設定の監査（ミスコンフィグ検出）に利用されるツール。本書ではクラウド評価の補助として扱う。
• DVWA（Damn Vulnerable Web Application）
  意図的に脆弱性を含む Web アプリケーション。基礎的な Web 脆弱性の演習環境として利用する。
• OWASP Juice Shop
  意図的に脆弱性を含む Web アプリケーション。Web セキュリティの演習環境として利用する。
• OWASP crAPI
  意図的に脆弱性を含む API。API セキュリティの演習環境として利用する。
• GTFOBins
  Unix 系の標準コマンド／バイナリを悪用し、権限昇格や制限回避に繋げるテクニック集。本書では Linux 権限昇格の補助情報として言及する。

付録：演習環境クイックスタート（DVWA / Juice Shop / crAPI）

本付録は、exercises/ 配下の演習環境（DVWA / Juice Shop / crAPI）を「起動 → 疎通確認 → 停止」まで最短で進めるための導線をまとめる。詳細な注意事項や補足は、各ディレクトリの README.md を参照する。

スクリプトで実行する場合（推奨）

演習環境の起動・停止は、scripts/ 配下の補助スクリプトでも実行できる。

例（DVWA を起動）：

bash scripts/setup_exercises.sh dvwa

例（DVWA を停止）：

bash scripts/cleanup_exercises.sh dvwa

共通の前提

• 演習環境は意図的に脆弱である。必ずローカル環境（または許可された検証環境）でのみ利用する。
• Docker Engine と docker compose（Compose v2）が利用可能であること。
• ポート公開は 127.0.0.1 バインドを前提とし、外部ネットワークから到達できない構成で運用する。

Juice Shop（Part 2〜3）

• ディレクトリ：exercises/juice-shop/
• 起動：

cd exercises/juice-shop
docker compose up -d

• アクセス：http://127.0.0.1:3000/
• 停止：

docker compose down

DVWA（Part 2〜3）

• ディレクトリ：exercises/dvwa/
• 起動：

cd exercises/dvwa
docker compose up -d

• アクセス：http://127.0.0.1:8081/
• 停止：

docker compose down

補足：初回起動時は、画面の案内に従って DB 初期化（/setup.php）が必要になる場合がある。

crAPI（Part 4）

• ディレクトリ：exercises/crapi/
• 事前準備（推奨）：.env を作成し、LISTEN_IP=127.0.0.1 を明示する。

cd exercises/crapi
cp .env.example .env

• 起動：

docker compose up -d

• アクセス：
  • crAPI Web：http://127.0.0.1:8888/
  • crAPI Web（HTTPS）：https://127.0.0.1:8443/（検証用証明書のためブラウザ警告は想定内）
  • MailHog UI：http://127.0.0.1:8025/（テスト用メールの確認に利用可能）
• 停止：

docker compose down

補足：演習ごとにデータベース状態をリセットする場合は docker compose down -v を利用する（named volume が削除されるため注意）。

付録：チェックリスト

title: “Web Pentest チェックリスト（原案）” version: “0.1-draft”

Web Pentest チェックリスト（原案）

本チェックリストは、Web アプリケーションに対する Pentest の観点を整理するための原案である。
詳細な分類やテスト手順については OWASP ASVS / WSTG を参照しつつ、本書の Part 2〜3 に沿って更新していく。

認証・セッション管理

• 認証フローが強固であり、パスワードリスト攻撃やブルートフォースに対する防御がある
• ログイン直後にセッション ID が再発行される（Session Fixation 対策）
• セッション Cookie に Secure / HttpOnly / 適切な SameSite が設定されている
• パスワードリセット・アカウントロック・多要素認証の実装が適切である

アクセス制御

• 認可チェックがサーバサイドで実装されており、UI だけに依存していない
• ID 変更やパラメータ改変により、他者リソースへのアクセスが発生しない（IDOR/BOLA）
• 管理機能エンドポイントへのアクセス制御が適切である（直接 URL アクセスの検証）

入力値検証・出力エスケープ

• すべての外部入力に対して、型・長さ・フォーマットの検証が行われている
• 出力時にコンテキストに応じたエスケープが行われている（HTML / 属性 / JavaScript / JSON）
• SQL インジェクション対策として、プレースホルダ付きクエリが利用されている
• コマンドインジェクションやファイルパス操作時に、ホワイトリスト等の対策がある

セキュリティ設定・エラーハンドリング

• エラーメッセージに過度な内部情報（スタックトレース、SQL 文等）が含まれない
• HTTP セキュリティヘッダ（CSP、X-Frame-Options 等）が適切に設定されている
• 管理用インタフェースやデバッグエンドポイントが公開されていない

ログ・監査

• 重要操作（ログイン、パスワード変更、権限変更等）がログに記録されている
• ログに機密情報（パスワード、完全なカード番号等）が含まれていない
• ログの保存期間と保護が適切に設計されている

API Security チェックリスト

title: “API Security チェックリスト（原案）” version: “0.1-draft”

API Security チェックリスト（原案）

本チェックリストは、REST API を中心とした API セキュリティの観点を整理するための原案である。
OWASP API Security Top 10 を参考に、本書の Part 4〜6 に沿って更新する。

認証・認可

• すべての保護対象 API に対して認証が必須となっている（不要な匿名アクセスがない）
• オブジェクトレベルのアクセス制御が実装されており、ID 変更による BOLA が発生しない
• 機能レベルのアクセス制御（管理 API 等）が適切に実装されている
• JWT 等のトークンについて、署名・iss・aud・exp 等のクレーム検証が行われている

入力・出力・データ最小化

• リクエストボディやクエリに対する入力検証が行われている
• レスポンスに不要なフィールドや内部情報が含まれていない（データ最小化）
• fields / include 等のパラメータで非公開情報を取得できない

Rate Limit / リソース保護

• 認証エンドポイントやワンタイムコード検証に対して適切なレート制限がある
• 重いバッチ処理やレポート生成 API に対して DoS を防ぐ制限がある
• API キーやトークンの誤用検知（異常なアクセスパターン）が行われている

API 管理・ミスコンフィグ

• 不要な古いバージョンの API が公開されたままになっていない
• ステージング・デバッグ用のエンドポイントが本番環境に露出していない
• CORS 設定が適切であり、認証付き API に対して Access-Control-Allow-Origin: * が設定されていない

OAuth2 / OIDC テスト項目表

title: “OAuth2 / OIDC テスト項目表（原案）” version: “0.1-draft”

OAuth2 / OIDC テスト項目表（原案）

本チェックリストは、OAuth2 / OpenID Connect（OIDC）ベースの認証・認可実装を評価するための観点を整理したものである。

クライアント登録・リダイレクト URI

• リダイレクト URI が事前登録制となっている
• ワイルドカードやオープンリダイレクトを許容していない
• 本番・検証環境でクライアント ID / シークレットが適切に分離されている

フローとスコープ

• パブリッククライアントには Authorization Code + PKCE 等、適切なフローが選択されている
• 付与されるスコープが必要最小限に制限されている
• クライアントごとにスコープが分離されている

トークン検証

• ID トークン／アクセストークンの署名検証が行われている
• iss・aud・exp・iat などのクレーム検証が実装されている
• nonce が利用されるフローでリプレイ防止が適切に行われている

外部 IdP 連携

• メールアドレスやドメインの検証が適切であり、想定外のユーザが管理権限を取得できない
• 既存アカウントとの紐付け時に、ユーザ本人確認や衝突検出が行われている
• 外部 IdP 障害時のフェイルセーフ（代替ログイン手段等）が検討されている

モバイル Pentest チェックリスト

title: “モバイル Pentest チェックリスト（原案）” version: “0.1-draft”

モバイル Pentest チェックリスト（原案）

本チェックリストは、Android / iOS アプリケーションを対象とした Pentest 観点を整理するものである。

データ保護（端末内）

• 認証情報・トークン・鍵が平文ファイルやプレーンな設定ストアに保存されていない
• Android Keystore / iOS Keychain 等のセキュアストレージが利用されている
• バックアップ経路（allowBackup 等）を通じて機密情報が取得できない

通信

• すべてのバックエンド通信が HTTPS となっている（クリアテキスト通信がない）
• 証明書検証が適切に行われている（任意の自己署名証明書を許容していない）
• 証明書ピンニング実装の有無と、そのバイパス難易度が設計意図と整合している

リバースエンジニアリング耐性

• アプリバイナリに API キーや秘密情報がハードコードされていない
• 難読化やデバッグ保護が、必要な範囲で適用されている
• root / Jailbreak 検知の方針が明確であり、その実装が想定通りに動作している

クラウド構成ミス防止チェックリスト

title: “クラウド構成ミス防止チェックリスト（原案）” version: “0.1-draft”

クラウド構成ミス防止チェックリスト（原案）

本チェックリストは、主に AWS を想定したクラウド構成のミスコンフィグ防止を目的とした観点を整理するものである。

IAM

• 最小権限原則に基づき、ロール／ユーザに過剰な権限が付与されていない
• 管理者権限ロールの利用が適切に制限されている
• 古い・未使用のアクセスキーやロールが定期的に棚卸しされている

ネットワーク（VPC / SG / NACL）

• 管理用ポート（22/3389 等）がインターネット全体に公開されていない
• 内部向けシステムがパブリックサブネットに配置されていない
• セキュリティグループの入出力ルールが適切に制限されている

ストレージ（S3 等）

• 機密データを格納するバケットが公開されていない
• バケットポリシー・ACL が最小限の公開範囲となっている
• バージョニングや削除保護が必要なデータに対して有効になっている

ログ・監査

• CloudTrail が有効化され、重要アクティビティが記録されている
• ログの保存期間と保護（削除・改ざん防止）が設計されている
• セキュリティイベントに対するアラートが設定されている

Linux / コンテナ検証事項

title: “Linux / コンテナ検証事項（原案）” version: “0.1-draft”

Linux / コンテナ検証事項（原案）

本チェックリストは、Linux サーバおよび Docker / Podman 等のコンテナ環境における代表的な検証観点を整理したものである。

Linux 権限・設定

• 不要なユーザ・グループが存在しない
• sudo 設定に過剰な権限付与やパスワード不要設定がない
• SUID/SGID バイナリが必要最低限であり、怪しいものが存在しない
• 重要ファイル・ディレクトリのパーミッションが適切に制御されている

コンテナ構成

• 特権コンテナ（--privileged）の利用が最小限に抑えられている
• docker.sock やホストファイルシステムのマウントが安易に行われていない
• コンテナ内で root ユーザを使用する必要性が検討されている

監査・更新

• ベースイメージやホスト OS に既知の脆弱性がないか定期的に確認している
• セキュリティアップデートの適用方針が定義されている
• コンテナログやホストログが一元的に収集・監視されている

付録：テンプレート

title: “Pentest レポートテンプレート” version: “0.1-draft”

Pentest レポートテンプレート

本テンプレートは、本書の Part 3 および Part 7 で説明する Pentest レポート構成に基づくものである。
実際の案件・演習に応じて、章立てや粒度を調整して利用する。

1. レポート情報

• 顧客名 / プロジェクト名
• 評価対象システム名
• 実施期間
• レポート作成日
• 作成者 / 所属

2. エグゼクティブサマリ

• 評価の目的
• 全体的なリスク評価（高 / 中 / 低 など）
• 主要な所見の概要（例：アクセス制御不備、クラウド設定ミスなど）
• 推奨される優先対応事項（トップ 3 程度）

3. 評価概要

• 評価範囲
  • 対象ドメイン・IP 範囲
  • 対象コンポーネント（Web / API / モバイル / クラウド / Linux/コンテナ 等）
• 前提条件・制約
  • スコーピングで合意した前提（禁止事項、時間帯制限等）

4. 手法・基準

• 参照した標準・ガイドライン
  • OWASP ASVS / WSTG / API Security Top 10 等
• 利用したツール
  • Burp Suite、MobSF、Frida、Prowler、ScoutSuite 等（バージョン含む）

5. 主要所見の要約

重大度は、組織の基準（例：Critical / High / Medium / Low）に合わせる。

6. 個別所見（詳細）

6.X 所見タイトル

• 概要
  • 脆弱性またはミスコンフィグの概要説明
• 影響
  • ビジネスインパクト、想定される攻撃シナリオ、Kill Chain / ATT&CK 上の位置づけ
• 再現手順
  1. 前提条件（ログイン状態、利用アカウント等）
  2. 送信リクエスト（Burp Repeater などの例）
  3. 確認すべきレスポンスや画面
• 証拠
  • スクリーンショット、ログ抜粋、リクエスト／レスポンス等
• 推奨対策
  • 実装レベルおよび設計レベルの対策案

7. 攻撃チェーンの整理

• 初期侵入から権限昇格・横展開に至るまでの流れを、ステップごとに記載する。
• 図（DFD、シーケンス図等）を用いて可視化するとよい。

8. 総括と今後の対応

• 発見されたリスクに対する総括
• 優先度の高い改善アクション
• 今後の評価計画（定期 Pentest、マネージドサービスの導入など）

付録

• テスト対象一覧（URL / IP / ポート等）
• 使用したチェックリスト（Web / API / モバイル / クラウド）
• 用語集（必要に応じて）

テスト計画書テンプレート（Pentest）

title: “テスト計画書テンプレート（Pentest）” version: “0.1-draft”

テスト計画書テンプレート（Pentest）

本テンプレートは、Pentest 実施前の計画策定に利用することを想定している。
実案件および本書 Part 7 の総合演習で共通して利用可能な構成とする。

1. 背景と目的

• テストの背景（法令対応、監査、リリース前評価等）
• テストの目的（例：新規機能のセキュリティ検証、クラウド移行後の確認）

2. 評価範囲

• 対象システム・コンポーネント
  • Web アプリケーション、API、モバイルアプリ、クラウド構成、Linux/コンテナ 等
• 対象ドメイン・IP 範囲
• 対象環境（本番 / 準本番 / ステージング 等）

3. 前提条件・制約

• 許可された攻撃手法（DoS の可否、ソーシャルエンジニアリングの有無等）
• 作業可能時間帯・期間
• 関係者（窓口担当、インシデント連絡先等）

4. 評価基準・リスク評価

• 参照する標準（OWASP ASVS / WSTG / API Security Top 10 等）
• リスク評価基準（DREAD / CVSS / 独自基準 等）
• 重大度ランクと定義

5. テスト観点

• Web
  • 認証／セッション管理、アクセス制御、入力値検証、エラーハンドリング 等
• API
  • BOLA、Mass Assignment、Rate Limit、不適切なデータ露出 等
• モバイル
  • データ保護、通信保護、リバースエンジニアリング耐性 等
• クラウド / インフラ
  • IAM、ネットワーク、ストレージ、ログ・監査、SSRF→IMDS 等

6. 体制と役割

• テスト実施者（Pentest チーム）と役割
• システム側窓口、運用・開発担当者
• レビュー担当者（技術・マネジメント）

7. スケジュール

• 準備期間（環境整備、アカウント発行等）
• テスト実施期間
• レポート作成・レビュー期間
• 再テスト（Fix 確認）の予定

8. 成果物

• レポート（本書のレポートテンプレートに準拠）
• PoC 一式（提供範囲・形式は事前に合意）
• 補足資料（ログ、設定ファイル差分等）

ライセンス

基本ライセンス

本作品（「実務で使えるペネトレーションテスト大全」）は以下のライセンスの下で提供されます：

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

詳細：https://creativecommons.org/licenses/by-nc-sa/4.0/

商用利用について

商用利用の定義

以下の用途は商用利用に該当し、事前の商用ライセンス契約が必要です：

• 有料での販売・配布・頒布
• 営利法人・団体での研修・教育利用
• 広告収益を伴うメディア・プラットフォームでの利用
• 商品・サービスの一部としての組み込み・統合
• 企業内教育プログラムでの活用
• コンサルティング・研修サービスでの教材利用

商用ライセンス契約

商用利用をご希望の場合は、以下にお問い合わせください：

お問い合わせ先
株式会社アイティードゥ（ITDO Inc.）
Email: knowledge@itdo.jp
件名: [実務で使えるペネトレーションテスト大全] 商用ライセンス利用申請

契約に必要な情報

• 申請者情報（法人名・担当者名・連絡先）
• 利用目的・用途の詳細
• 利用範囲・対象人数
• 利用期間・契約期間
• 収益モデル・事業規模
• 技術的利用方法

商用ライセンス料金

ライセンス料金は以下の要素を総合的に勘案し、個別にお見積もりいたします：

価格決定要素

• 利用規模・対象人数
• 利用期間・契約期間
• 利用用途・事業内容
• カスタマイズ・サポート要件
• 地理的範囲・多言語対応
• 既存システムとの統合要件

契約オプション

• 年間契約による優遇価格
• 複数年契約による大幅割引
• ボリュームライセンス
• 教育機関向け特別価格
• スタートアップ支援プログラム

お客様の具体的なご要件をお聞かせいただき、最適なプランをご提案いたします。

契約条件

商用ライセンス契約には以下の条件が含まれます：

• 利用許諾範囲の明確化
• 著作権表示義務
• 改変・翻案に関する制限事項
• 再配布・第三者提供に関する条件
• 契約期間・更新条件
• 損害賠償・免責事項

著作権表示

本作品を利用する際は、以下の著作権表示を含めてください：

"実務で使えるペネトレーションテスト大全" by 株式会社アイティードゥ (ITDO Inc.) is licensed under CC BY-NC-SA 4.0
Original work: https://github.com/itdojp/pentest-learning-book
License details: https://github.com/itdojp/pentest-learning-book/blob/main/LICENSE.md

第三者成果物

本リポジトリには第三者が提供する成果物（設定ファイルや JavaScript 等）が含まれます。詳細は THIRD_PARTY_NOTICES.md を参照し、各ライセンス条件に従ってください。

免責事項

株式会社アイティードゥ（ITDO Inc.）は本作品の利用に関していかなる保証も行わず、 利用によって生じた損害について責任を負いません。 ただし、商用ライセンス契約における保証・責任条項は別途定めるものとします。

お問い合わせ

本ライセンスに関するご質問・ご相談は以下までお願いいたします：

株式会社アイティードゥ（ITDO Inc.）
Email: knowledge@itdo.jp
URL: https://itdo.jp

© 2025 株式会社アイティードゥ (ITDO Inc.) All Rights Reserved.

Third-Party Notices

本リポジトリには、第三者が提供する成果物（設定ファイルや JavaScript 等）が含まれる。配布形態（HTML/PDF/EPUB など）に応じて、各ライセンス条件に従い適切に取り扱うこと。

Mermaid

• 対象ファイル: mermaid.min.js
• ライセンス: MIT
• 参照: ファイル先頭コメントおよび https://github.com/mermaid-js/mermaid/blob/develop/LICENSE

mdbook-mermaid（初期化スクリプト）

• 対象ファイル: mermaid-init.js
• ライセンス: MPL-2.0
• 参照: ファイル先頭コメントおよび https://mozilla.org/MPL/2.0/

OWASP/crAPI（演習環境）

本リポジトリの crAPI 演習環境は、OWASP/crAPI の構成を参考にしている（派生ファイルを含む）。

• 対象ファイル: exercises/crapi/docker-compose.yml, exercises/crapi/keys/jwks.json
• ライセンス: Apache-2.0
• 参照: https://github.com/OWASP/crAPI