Webセキュリティ研究を自動化する「カスタムスキャナ」開発の考え方（Burpのカスタムスキャンチェックを例に）

概要

本記事は、PortSwigger Research が公開した「How to build custom scanners for web security research automation」を元ソースとして、Webセキュリティ研究を前に進めるための“自作スキャナ（カスタムスキャナ）”の作り方を、日本語で要点整理したものです。とくに、既存の一般的な脆弱性診断ツールがカバーしきれない（あるいは優先度が上がりにくい）攻撃クラスに対して、研究者が自分の仮説を形にし、反復的に検証できる自動化をどう組み立てるかに焦点を当てます。

この文脈で有用なのが、Burp Suite の Burp Scanner を拡張できる「Custom scan checks」です。これは、既存スキャナの枠組みに自分の検出ロジックを追加して、WebアプリやAPIのスキャンで動かせる仕組みで、研究の“再現性”と“スケール”を両立しやすくします（手動検証だけでは追いつかない範囲を、同じ観点で何度でも走査できるためです）。

詳細

1) 研究用カスタムスキャナが必要になる場面

セキュリティ研究では、「実害が大きいのに体系化されていない攻撃」や「条件が揃ったときだけ成立する挙動」など、既存ツールが“汎用のルール”として持ち込みにくい検出対象に頻繁に遭遇します。たとえば、特定の入力経路とサーバ側の状態遷移が噛み合ったときにだけ露呈する欠陥は、単発のPoCを作って終わりにすると、同種の欠陥を別環境へ横展開して調べるのが難しくなります。

そこで、研究の中心を「仮説 → 観測可能な兆候（シグナル） → 検証手順 → 自動化 → 反復」に置き直し、仮説の検証手順を“スキャナのチェック”として実装します。こうすると、(a) 別ターゲットで同じ検出観点を再利用でき、(b) 偽陽性・偽陰性を潰す改善サイクルを回しやすく、(c) チーム内で検証手順が共有されやすくなります。元ソースが目指す「過小評価されがちな攻撃クラスの研究を自動化で押し広げる」という狙いは、まさにこの反復可能性にあります。

2) Burpの「Custom scan checks」を“研究の実験装置”として使う

Burp Scanner の Custom scan checks は、Scanner に独自の検出ロジックを追加できる拡張点です。重要なのは、これを単なる「便利な拡張機能」ではなく、研究の実験装置として扱うことです。

具体的には、チェックがやるべき仕事を次のように切り分けます。

• 観測の入口（入力の選別）: どのリクエスト／レスポンスの組を対象にするか。全トラフィックを対象にするとノイズが増えやすいため、研究対象の特徴（特定のエンドポイント種別、パラメータ形、レスポンスの兆候など）で絞り込める設計が有利です。
• 刺激（プローブ）の生成: 仮説を確かめるために、どんな差分リクエストを追加で投げるか。研究では「同じ条件で差分だけ変える」ことが多いので、元のメッセージを基点に“最小限の変更”を作れると検証が安定します。
• 判定（シグナルの抽出）: 成否の判断を何に置くか。HTTPステータスや本文の断片のような単純な観測だけでなく、「反応の一貫性」や「差分の再現性」を重視することで、偶然の揺らぎを偽陽性として拾いにくくできます。
• 報告（研究ログの構造化）: 何を根拠に“ヒット”としたかが後から追える形で、結果を残すこと。研究用途では、単にアラートを出すだけでなく、再検証に必要なメッセージや差分条件を辿れることが価値になります。

Burpのドキュメントでは、Custom scan checks を作成してScannerを拡張できること、そしてそれをスキャンに組み込んでWebアプリやAPIのスキャンで利用できることが明示されています。研究目的では、この「既存スキャンのパイプラインに載せる」性質が特に効きます。つまり、探索（クロールや基礎的なスキャン）で面を押さえつつ、研究対象の“尖った検出”だけを後付けで重ねられるからです。

3) 作成・組み込み・テストまでを一連で設計する

研究用の自動化は、実装した瞬間が完成ではなく、テストと改善で価値が決まります。Burp側にも、カスタムチェックを編集・管理し、任意のHTTPメッセージを選んでテストする導線が用意されています。これにより、「まずは狭い入力で期待通りの反応を得る → その後スキャンへ統合して広い面で回す」という段階的な検証が可能になります。

ここでの実務上のコツは、最初から“万能検出”を狙わないことです。研究初期は、

• 対象を絞った条件で確実に当てる（再現性を最優先）
• 観測できるシグナルを増やす（根拠を強める）
• 偽陽性が出たケースをテスト素材として蓄積する（改善の燃料にする）

という順番が堅実です。Burpのカスタムチェックは「Burp Scannerが標準では検知しない脆弱性を、独自ロジックで検知できる」前提で設計されているため、まさにこの改善サイクルを回す土台になります。

4) “自動化”を過信せず、研究の品質を上げるために使う

最後に強調したいのは、自動化は発見を置き換えるのではなく、発見の確度と速度を上げるための補助輪だという点です。カスタムスキャナは、研究で得た洞察（どんな前提条件が必要で、どの挙動が兆候になり、何をもって成立とみなすか）を、再利用可能な形へ落とし込む器です。これができると、研究成果は「個人の手元の知見」から「検証可能な手順」へと格上げされ、同種調査や追試、回帰検証にも耐えるようになります。

元ソースが掲げる“過小評価されがちな攻撃クラスを押し広げる”ためには、まさにこの器が必要になります。Burpの Custom scan checks を例にすると、作成（ロジック化）→ スキャンに統合（運用へ載せる）→ テスト（品質を上げる）を一体として回すことで、研究のスピードと品質を同時に引き上げられます。