Burp Suite 入門 — HTTP通信の読み方と安全な確認範囲

Burp Suiteとは：HTTP通信を観察するための入口

Burp SuiteはWebアプリケーションのセキュリティテストを支援する製品です。このページは開発者・情シス向けに、取得済みの架空のHTTP記録を読む演習を提供します。SQLインジェクション、認証回避、総当たり、実データ取得の手順は扱いません。

製品の機能やエディション差は公式資料で確認してください。ツールを導入しただけでは、アプリの安全性を証明できません。

確認前に決める範囲と停止条件

• 自分が所有する専用テスト環境か、書面で対象と方法が許可されているか。
• 本番アカウント、実際の顧客情報、決済・通知・外部連携を使わない設計か。
• 負荷、ログイン失敗、アカウントロック、異常検知が起きたときの停止条件があるか。
• 通信履歴に含まれるトークン、Cookie、個人情報を保護できるか。
• 作業後にプロキシ設定や追加した検証用証明書を戻す手順があるか。

通常業務のブラウザや個人アカウントの通信を、学習目的で無差別に取得しないでください。演習環境構築を先に確認します。

架空のHTTP記録から分かること

GET /reports/quarterly HTTP/1.1
Host: app.example.com
Cookie: [教材では省略]

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: private, no-store

文書例示用ドメインを使った合成データです。200は要求が処理されたことを示しますが、「閲覧権限が正しい」「個人情報が含まれない」「後続処理が安全」という証明ではありません。

最初に、要求のメソッド、対象機能、認証状態、応答コード、応答のデータ分類を読みます。CookieやAuthorization値はチケットにコピーせず、存在と種類のみ記録します。

認証と認可の違いをレビューする

認証は利用者を確かめること、認可はその利用者に操作を許すか決めることです。画面のボタンが非表示でも、サーバー側の権限確認が省かれていれば適切なアクセス制御ではありません。

レビューでは、所有者が用意したテストアカウントと合成データについて「役割・機能・許可される対象・期待する拒否」を表にします。他人の本番データを取得して証明する必要はありません。詳細は認証と認可の基礎とOWASP Top 10で学べます。

記録テンプレートと修正の完了条件

対象環境・機能:
確認の許可・範囲:
テスト用役割・合成データ:
期待される許可／拒否:
観測した応答・時刻:
秘密情報を除いた根拠:
担当者・修正方針:
再確認結果・残る制約:

修正後は、拒否されるべき要求だけでなく、正規の業務が動作することも確認します。判定できない箇所を「問題なし」にせず、未確認として担当者へ戻します。

やってはいけないこと

未承認のリクエスト改変・大量送信・スキャン、本番の秘密情報の保存、業務ブラウザへの恒久的な検証用証明書の追加は行いません。表示された製品名や単一の200応答だけで脆弱性を断定しないことも重要です。

安全な理解確認にはアクセスログ解析ミニCTFを、発見後の優先度整理にはCVE初動チェックリストを使えます。