セキュリティ PR

ゼロからわかる「Burp Suite 使い方」— インストールから基本操作、よく使う機能まで(初心者向け)

BurpSuiteの使い方
記事内に商品プロモーションを含む場合があります

この記事のゴール

  • これからBurp Suiteを触る初心者が、安全に・最短で基本操作(プロキシ/Intercept/Repeater/簡単なIntruder)を身につける
  • ブラウザ設定とHTTPS証明書の“つまずき”を回避し、明日から社内検証で使える状態にする

まずは前提(と大事な約束)

  • 目的:自社/自分が管理する環境の“防御力向上”のために、Webアプリの挙動を可視化して弱点を早期に見つけること
  • 法と倫理許可のない第三者サイトやサービスへの試験はNG。社内規定・契約・法令を必ず確認
  • 安全第一:本番への負荷・データ改変を避けるため、まずは開発/検証環境で小さく始める

Burp Suiteとは?—「通信を見て・変えて・確かめる」ための統合ツール

Burp Suiteは、ブラウザとサーバの間に入り、HTTP(S)通信を記録・編集・再送できる“検証者の拡張ブラウザ”。

アプリの実態はHTTPリクエストとレスポンス。その中身を見える化できれば、脆弱性の芽や実装ミスに早く気づける。

フォーム送信前にパラメータを書き換えて挙動を確認/Cookieやヘッダの取り扱いを検証/想定外の入力を与えて堅牢性チェック。

初心者はCommunity Editionで十分。まずはProxy・Repeater・(軽い)Intruderから。

エディションの違い(ざっくり)

  • Community:手動検証メイン(無料)。学習・社内PoCに◎
  • Professional:自動スキャン等の支援が充実(有料)。運用チーム・専任者向け

導入と初期設定

インストール(Windows/Mac/Linux)

  1. 公式配布からインストーラを取得し、OSに沿ってセットアップ
    https://portswigger.net/burp/documentation/desktop/getting-started/system-requirements
  2. 初回起動でTemporary projectUse Burp defaultsでOK(まずは保存設定を気にしない)
  3. 表示言語は英語UIが前提(情報量が多く学習が楽)

プロジェクト保存の考え方

  • 学習時は“Temporary”でOK
  • チーム利用や長期調査ではプロジェクトファイルカスタム設定を分けて保存

ブラウザの接続設定(最初の“山場”をサクッと越える)

Burpのローカルプロキシ(既定127.0.0.1:8080)をブラウザに設定し、通信をBurp経由にする。

これでIntercept(盗み見&一時停止)やHTTP historyが働く。
Example(やり方の型)

  • 一番簡単:Burp内蔵の“Open Browser”を使う(設定済みブラウザが起動)
  • 既存ブラウザを使う場合
    • プロキシを 127.0.0.1:8080 に手動設定
    • HTTPSを正しく見るための証明書インポート(下記)

HTTPS(証明書)の設定

  1. ブラウザで http://burpsuite/ へアクセス(内蔵ブラウザまたはプロキシ経由)
  2. “CA Certificate”をダウンロード
  3. ブラウザの証明書ストアへ信頼する認証局としてインポート
    Point:ここで失敗すると証明書エラーで何も進まない。まずは検証用プロファイルを分けるのが安全。

最初に覚える3つの機能(Proxy/Repeater/Intruder)

1) Proxy(Intercept & HTTP history)

  • Intercept:送信前のリクエストを一時停止して内容を確認・編集
  • HTTP history:これまでの通信が一覧化。検索・フィルタで解析が速くなる
    ミニ手順
  1. InterceptをON
  2. 対象サイトでフォーム入力→送信
  3. Burpで止まったリクエストを確認・必要なら編集→「Forward」
  4. 結果をブラウザで確認

HTTPサンプル(学習用ダミー)

POST /api/profile/update HTTP/1.1
Host: example.test
Cookie: session=abc123
Content-Type: application/json

{"nickname":"guest","role":"user"}

  • 試しに "role":"admin" に書き換えて挙動を観察(※許可された検証環境のみ

2) Repeater(手動で何度も試す)

同じリクエストを編集して再送できる“検証ループ”的な機能。
使い方の型:HTTP history → 右クリック → Send to Repeater → タブで編集 → Send → レスポンス比較
よく試す観点

  • 値域外・型違い・空・長文などの境界値
  • ヘッダ(X-Forwarded-For など)
  • 認可まわり(別ユーザーIDを指定 等)

3) Intruder(簡易の繰り返し試験)

パラメータの一部を自動的に差し替え、反応を一覧で比較。
ミニ手順

  1. 対象リクエストをSend to Intruder
  2. Positionsで差し替え箇所を指定(§value§ の形に)
  3. Payloadsにテスト値(小さく・安全に)を設定
  4. Start attack → ステータスや長さで異常反応を探す
    注意:負荷をかけすぎない/本番禁止/認証つきはロックアウトに注意

スコープ(Scope)設定とターゲット管理

対象外への誤送信や無駄なログを防ぐ。
やること

  • Target → Scopeで対象ドメイン/パスを登録
  • Proxyや各ツールで「Use suite scope」を有効化
    効果:履歴や自動送信の対象が絞られ、作業効率&安全性アップ

具体的な確認テーマ(“型”で覚える)

入力と表示(XSSの芽)

  • 文字列・HTML断片がそのまま返る箇所は要観察
  • ""><script>alert(1)</script> のような“構造を壊す”系の入力は検証環境で最小限
  • **Context(属性値/テキスト/JS内)**で何が違うかを理解

認可/アクセス制御

  • IDを他人のものに替えて水平権限を確認
  • 直接URL叩き(Direct Object Reference)で不可視データに触れないか
  • 重要操作にCSRF対策(トークン/SameSite)あり?

セッション管理・ヘッダ

  • Cookie属性(HttpOnly/Secure/SameSite
  • キャッシュ制御・CSP・CORSの設定

便利な拡張(BApp Storeのおすすめ入門)

  • Authorize:ユーザー権限の差分を可視化
  • Param Miner:隠しパラメータの当たりをつける
  • JWT Editor:JWTの中身確認や署名検証(学習用)
  • Turbo Intruder:慎重に!多リクエストの自動化(本番禁止)
  • Logger++:通信ログの拡張表示

つまずきやすいポイントと対処

通信がBurpに来ない

  • ブラウザのプロキシ設定を再確認
  • VPN/企業プロキシの干渉→例外設定やBurpのリスナーポート変更
  • スコープ外フィルタで非表示になっていないか

HTTPSが警告だらけ

  • CA証明書のインポート手順を再確認
  • 証明書は検証用プロファイルに限定して信頼させる

レスポンスが文字化け

  • Repeaterのレスポンスタブで文字コード推定を試す
  • Content-Type のcharsetを確認

モバイルアプリを見たい

  • 端末のWi-FiプロキシをBurpに向け、端末側へCA証明書をインストール
  • OSバージョン毎の制約に注意(会社規程も要確認)

作業を速くする小ワザ

  • 検索(Ctrl/Cmd+F)とFiltersでノイズ除去
  • マクロセッションハンドラで認証維持
  • ショートカットCtrl+R=Repeaterへ送る 等)を覚える
  • レビューでは変更点の差分(ヘッダ/ボディ)に注目

学びを継続するコツ

  • 再現ノートを残す:入力→変更→反応→メモ
  • 1日1テーマ(例:Cookie属性/認可の型)を小さく検証
  • 公式ドキュメントや学習用ラボで安全に反復

まとめ(明日から使うためのチェックリスト)

  • Community Editionを入れて起動できた
  • ブラウザ(内蔵 or 既存)でプロキシ設定完了
  • CA証明書をインポートしHTTPSが見られる
  • Intercept→編集→Forwardの一連ができた
  • HTTP historyからRepeaterに送り再送できた
  • Scopeで対象を限定した
  • 拡張(Authorize/Param Miner/JWT Editorなど)を1つ入れて試した

付録:ミニサンプル(Repeaterで見る視点)

PUT /api/user/123 HTTP/1.1
Host: example.test
Content-Type: application/json
Cookie: session=abc123

{"user_id":123,"email":"guest@example.test"}

本来は自分のIDのみ操作可能か? → 他IDに変更して認可エラーになるかを確認(検証環境限定)