performing-web-application-penetration-test

Web アプリケーションの侵入テストの実施

使用するタイミング

• 本番環境へのデプロイ前に Web アプリケーションをテストし、悪用可能な脆弱性を特定する場合
• コンプライアンス要件に基づくセキュリティ評価（PCI-DSS 要件 6.6、SOC 2 Type II）を実施する場合
• 再テスト時に、以前に特定された Web アプリケーションの脆弱性が修正されたことを検証する場合
• 組織の環境に統合する前に、サードパーティ製 Web アプリケーションを評価する場合
• 自動スキャンだけでは不十分な、独自開発の Web アプリケーションを評価する場合

書面による承認がない Web アプリケーション、本番システムのピークトラフィック時間帯（明示的な承認がない場合）、または Web インフラストラクチャに対するサービス拒否テストには使用しないでください。

前提条件

• 対象アプリケーションの URL、環境（ステージング／本番）、テスト範囲を定義した、署名済みの作業範囲記述書（SoW）
• 最新の拡張機能（Active Scan++、Autorize、JSON Beautifier、Logger++）を備えた Burp Suite Professional ライセンス
• 認可テスト用に、各権限レベル（未認証、一般ユーザー、管理者）の有効なテストアカウント
• API 仕様（OpenAPI/Swagger）、サイトマップ、テクノロジースタックの詳細を含むアプリケーションのドキュメント
• Burp Suite プロキシ（FoxyProxy を推奨）を設定し、Burp CA 証明書をインストールしたブラウザー

ワークフロー

ステップ 1：偵察とアプリケーションのマッピング

Web アプリケーションの攻撃対象領域全体をマッピングします。

• Burp Suite プロキシを設定し、すべてのページ、フォーム、機能を手動で操作してアプリケーションをクロールしながら、Burp にサイトマップを記録させます
• Burp の Discover Content 機能を使用し、表示中のアプリケーションからリンクされていない隠しディレクトリやファイルを見つけます
• レスポンスヘッダー（X-Powered-By、Server）、Cookie（JSESSIONID = Java、PHPSESSID = PHP、ASP.NET_SessionId = .NET）、ページ拡張子からテクノロジースタックを特定します
• ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u https://target.com/FUZZ -mc 200,301,302,403 を使用してエンドポイントを列挙します
• Burp の JS Link Finder 拡張機能または LinkFinder.py を使用して、JavaScript ファイルにハードコードされた API エンドポイント、シークレット、クライアント側ルーティングがないか確認します
• URL パラメーター、POST ボディ、HTTP ヘッダー、Cookie、ファイルアップロード、WebSocket 接続など、すべてのエントリーポイントを記録します

ステップ 2：認証テスト

認証メカニズムに弱点がないかテストします。

• 認証情報の列挙：有効なユーザー名と無効なユーザー名を送信し、レスポンスの違い（応答時間、メッセージ、HTTP ステータス）から有効なアカウントが特定できないか確認します
• ブルートフォース対策：無効な認証情報で 10～20 回すばやくログインを試行し、アカウントロックアウトとレート制限が適用されることを確認します
• パスワードポリシー：弱いパスワード（123456、password、1 文字）を使ってパスワードを作成し、ポリシーが適用されることを確認します
• 多要素認証のバイパス：認証後のページへの直接アクセス、MFA トークンの改ざん、認証に成功した MFA レスポンスの再送信により、MFA をバイパスできないかテストします
• セッション固定：認証の前後でセッショントークンを記録します。ログイン後にトークンが変化しない場合、セッション固定の可能性があります
• ログイン状態の保持機能：永続的な認証トークンの予測可能性、暗号化、適切な有効期限を調べます
• パスワードリセット：パスワードリセットのフローについて、トークンの予測可能性、トークンの有効期限、リセットフォームを介したアカウント列挙、ホストヘッダーインジェクションをテストします

ステップ 3：認可テスト

アクセス制御が適切に適用されていることを確認します。

• 水平権限昇格（IDOR）：アカウント A を使用して、アカウント A のリソースにアクセスするリクエストを取得します。アカウント B の識別子（ユーザー ID、注文番号、ファイル名）に置き換えて、これらのリクエストを再送信します。Burp の Autorize 拡張機能を使用して、すべてのエンドポイントでこれを自動化します。
• 垂直権限昇格：低権限アカウントを使用して、管理者用 URL に直接アクセスする、リクエスト内のロールパラメーターを変更する、または JWT クレームを操作することで、管理機能へのアクセスを試みます。
• 強制ブラウジング：マッピング中に収集した内部 URL に直接アクセスして、認証が必要なはずのリソースへのアクセスを試みます。
• HTTP メソッドの改ざん：エンドポイントで GET がブロックされる場合は、PUT、POST、DELETE、PATCH を試すか、メソッドオーバーライドヘッダー（X-HTTP-Method-Override: DELETE）を使用します。
• 認可におけるパストラバーサル：URL パスの操作（/api/users/123/../456/profile）をテストして、パスベースの認可チェックを回避できるか確認します。

ステップ 4：入力検証とインジェクションのテスト

すべての入力ポイントでインジェクションの脆弱性をテストします。

• SQL インジェクション：' OR 1=1--、' UNION SELECT NULL,NULL--、時間ベースのブラインドペイロード（'; WAITFOR DELAY '0:0:5'--）などのペイロードをすべてのパラメーターに挿入します。sqlmap を使用して、自動検出と、インジェクションが確認されたポイントの悪用を行います。
• クロスサイトスクリプティング（XSS）：<script>alert(document.domain)</script>、"><img src=x onerror=alert(1)>、イベントハンドラーなどのペイロードを使用して、反射型、格納型、DOM ベースの XSS をテストします。HTML 本文、属性、JavaScript、URL のすべてのコンテキストでテストします。
• サーバーサイドリクエストフォージェリ（SSRF）：外部リソースを取得するパラメーター（Webhook、画像 URL、インポート機能）に、内部 URL（http://169.254.169.254/latest/meta-data/、http://127.0.0.1:6379/）を指定します。
• コマンドインジェクション：サーバーで処理されるパラメーターに、OS コマンドの区切り文字（;、|、&&、`）と、それに続くコマンド（id、whoami、ping -c 3 collaborator.net）を挿入します。
• XML 外部エンティティ（XXE）：XML アップロードまたは API エンドポイントに、外部エンティティ宣言（<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>）を含む XML ペイロードを送信します。
• サーバーサイドテンプレートインジェクション（SSTI）：テンプレートエンジンでレンダリングされるパラメーターに、{{7*7}}、${7*7}、<%= 7*7 %> を使ってテストします。

ステップ 5：セッション管理テスト

セッション処理のセキュリティを評価します。

• セッショントークン分析：セッショントークンを 100 個以上収集し、Burp Sequencer を使用してランダム性を分析します。トークンの長さ（エントロピーが最低 128 ビットあること）、文字セット、予測可能性を確認します。
• セッションの有効期限：セッションが定義されたアイドルタイムアウトおよび絶対タイムアウト後に期限切れになることを確認します。セッショントークンを取得し、タイムアウトを超えるまで待ってから再送信してテストします。
• Cookie のセキュリティフラグ：セッション Cookie に Secure、HttpOnly、SameSite フラグが設定されていることを確認します。HttpOnly がないと、XSS によるセッション窃取が可能になります。SameSite がないと、CSRF が可能になります。
• CSRF テスト：状態を変更する操作（パスワード変更、メールアドレス更新、資金移動）を特定し、有効な CSRF トークンなしでクロスオリジンページから実行できるかテストします。
• 同時セッションの処理：アプリケーションが同時セッション数を制限しているか、また新しい場所からログインした際に以前のセッションが無効になるかをテストします。

ステップ 6：ビジネスロジックのテスト

自動スキャナーでは検出できない、アプリケーション固有のロジックの欠陥をテストします。

• 競合状態：Burp Turbo Intruder を使用して複数のリクエストを同時に送信し、タイムオブチェックからタイムオブユース（TOCTOU）の脆弱性（二重支払い、クーポンの再利用、複数回の投票）を悪用します
• ワークフローのバイパス：後の段階のエンドポイントに直接リクエストを送信し、複数段階のプロセス（チェックアウト、登録、承認）のステップをスキップできるか試します
• 数値の操作：価格、数量、金額を負の値、ゼロ、または極端に大きな数値に変更し、整数オーバーフローやロジックエラーが発生するかテストします
• ファイルアップロード制限のバイパス：MIME タイプの変更、二重拡張子（file.php.jpg）、ヌルバイト（file.php%00.jpg）、コンテンツタイプの操作によって、ファイルアップロード制限をテストします

ステップ 7：レポートと修正ガイダンス

すべての調査結果を構造化されたレポートにまとめます。

• アプリケーション全体のセキュリティ態勢をビジネスの観点から説明するエグゼクティブサマリーを作成します
• 各調査結果について、タイトル、深刻度（CVSS 3.1）、影響を受ける URL／パラメーター、説明、再現手順、スクリーンショット、Burp で取得した HTTP リクエスト／レスポンスのペアを記録します
• コードレベルの修正が可能な場合はそれも含め、各調査結果に対する具体的な修正ガイダンスを提示します
• 深刻度ごとの調査結果の分布を示すリスクマトリックスを含めます
• レポートは安全な方法（メール添付ではなく暗号化）で納品し、開発チームと調査結果の説明会を予定します

主な概念

用語	定義
OWASP WSTG	Web Security Testing Guide。テストカテゴリ（認証、認可、入力検証など）別に構成された、Web アプリケーションのセキュリティテストに関する包括的なオープンソースガイドです
IDOR	Insecure Direct Object Reference。アプリケーションが内部オブジェクト識別子を公開し、リクエストを行うユーザーにそのオブジェクトへのアクセス権があるか検証しない脆弱性です
CSRF	Cross-Site Request Forgery。認証済みユーザーのブラウザーに、脆弱な Web アプリケーションへ偽造リクエストを送信させる攻撃です
セッション固定化	攻撃者がユーザーの認証前に既知の値へセッション ID を設定し、ログイン後にセッションを乗っ取る攻撃です
強制ブラウジング	アプリケーション上で見えるリンクからアクセスできない URL を直接リクエストし、意図されたアクセス制御を回避してアプリケーションのリソースにアクセスしようとすることです
SSTI	Server-Side Template Injection。サーバーサイドのテンプレートエンジンにテンプレートディレクティブを注入し、リモートコード実行を達成する攻撃です

ツールとシステム

• Burp Suite Professional：インターセプト、スキャン、手動テストの各ツールを提供する主要な Web アプリケーションテスト用プロキシです。Repeater、Intruder、Sequencer などが含まれます
• ffuf：ディレクトリ／ファイルの検出、パラメーターのファジング、仮想ホストの列挙に使用する高速な Web ファザーです
• sqlmap：主要なデータベースエンジンとインジェクション手法すべてに対応する、自動 SQL インジェクション検出・悪用ツールです
• Nuclei：既知の CVE や設定ミスに対応するコミュニティ管理のテンプレートを備えた、テンプレートベースの脆弱性スキャナーです
• SecLists：Web アプリケーションのテスト全体で使用される、ファジング、認証情報のテスト、ペイロードの送信向けの厳選されたワードリスト集です

よくあるシナリオ

シナリオ：EC アプリケーションのローンチ前セキュリティ評価

コンテキスト：小売企業が、Node.js を基盤とし、React フロントエンドと PostgreSQL データベースを使用する新しい EC プラットフォームをローンチしようとしています。このアプリケーションは Stripe 連携を通じてクレジットカード決済を処理し、顧客の個人識別情報（PII）を保存します。テスト対象には、すべての API にアクセスできるステージング環境が含まれます。

アプローチ：

1. 手動でのブラウジングと API ドキュメントの確認を通じてアプリケーションをマッピングし、47 個の一意なエンドポイントを特定する
2. ソーシャルログイン（OAuth）、標準ログイン、パスワードリセットを含む認証フローをテストする
3. 注文取得 API（/api/orders/{orderId}）に IDOR 脆弱性があることを発見する。認証済みのユーザーであれば、注文 ID を順番に試すことで、任意の注文を閲覧できます
4. 商品レビュー機能に保存型 XSS があることを特定する。管理者が管理ダッシュボードを表示すると実行されます
5. 商品画像のインポート機能に SSRF があることを発見する。この機能を利用すると、AWS EC2 インスタンスのメタデータを読み取れます
6. チェックアウトの送信前にクライアント側のカートで価格を操作し、決済ロジックをテストする
7. Node.js の具体的なコードレベルの修正策（パラメーター化クエリ、DOMPurify を使用した入力のサニタイズ、認可ミドルウェア）を添えて、すべての発見事項を報告する

注意点：

• API レイヤーには独立した認可チェックがないにもかかわらず、API を無視してフロントエンドだけをテストする
• 手動テストを行わず、自動スキャンだけに頼ることで、ビジネスロジックの欠陥を見逃す
• 認可の問題を検出するために、異なる権限レベルで同じ機能をテストしない
• ハードコードされた API キー、デバッグエンドポイント、内部 URL がないか、クライアント側の JavaScript を確認しない

出力形式

## Finding: Insecure Direct Object Reference in Order API

**ID**: WEB-003
**Severity**: High (CVSS 7.5)
**Affected URL**: GET /api/v1/orders/{orderId}
**Parameter**: orderId (path parameter)

**Description**:
The order retrieval endpoint does not verify that the authenticated user owns
the requested order. Any authenticated user can access any order's details
including customer name, shipping address, email, phone number, and order
items by incrementing the orderId path parameter.

**Reproduction Steps**:
1. Authenticate as user A ([email protected])
2. Note user A's order ID: 10451
3. Send GET /api/v1/orders/10452 with user A's session token
4. Observe that user B's order details are returned with full PII

**HTTP Request**:
GET /api/v1/orders/10452 HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGc....[User A's token]

**HTTP Response** (truncated):
HTTP/1.1 200 OK
{"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}

**Impact**:
An attacker can enumerate all customer orders and extract PII (names, emails,
addresses, phone numbers) for an estimated 25,000 customers.

**Remediation**:
Add authorization middleware that verifies the authenticated user's ID matches
the order's userId field before returning order data. Implement UUIDs instead
of sequential integers for order identifiers to prevent enumeration.