プロキシに疲れたら — AI-Intruder という選択肢
プロキシをブラウザの中に移し、飽きることのないアナリストを同席させました。タブを離れずに反射型XSSとSQLインジェクションを見つけるまでの記録です。

私のWeb診断はたいてい同じ流れで始まります。ブラウザで対象を触り、プロキシのタブに移って リクエストを読み、また戻る。ひとつひとつは難しい作業ではありません。ただ、とにかく遅い。 そしてその遅さは積み重なります。20回目の画面切り替えのころには、もうアプリケーションのことを 考えていません。ツールのことを考えてしまっています。
そこで、いま見ている場所でそのまま通信をキャプチャして解析するブラウザ拡張機能を作りました。 繰り返しの作業はモデルに任せます。この記事では、誰もが最初に学ぶ2つの脆弱性 — 反射型XSS と SQLインジェクション — を題材に、短い診断の流れを紹介します。
⚠️ 以下はすべて、自分のローカル環境で動かしている意図的に脆弱なアプリ VulnShop に対する 検証です。この種のツールを向けてよいのは、自分が所有するシステムか、書面で許可を得た対象だけです。 これは免責文ではなく、この仕事の前提そのものです。
準備
検証用アプリを起動します。
php -S 127.0.0.1:8000
拡張機能側では Scope を対象ホストに設定し、Capture をオンにして、 あとは普通の利用者としてサイトを触っていくだけです。設定も、証明書のインストール作業も、 別ウィンドウも必要ありません。

反射型XSS
検索ページでは、こちらが何かを試す前にパッシブスキャナが 反射しているパラメータ を検出しました。
q の値がそのままレスポンスに返っており、どの位置に出力されているかまで示してくれます。


ここまで分かれば話は早い。素直に試します。
/search.php?q=<script>alert(1)</script>
アプリはエスケープせずに出力し、アラートが表示されました。リクエスト1回で反射型XSSを確認。 自分の入力がどこに出てきたかを手作業で探す必要はありませんでした。

SQLインジェクション
ログインフォームが怪しかったので Intruder に送り、ユーザー名を挿入位置に指定して、 組み込みのSQLインジェクション用ペイロードを読み込みます。レート制限をかけた短い試行のあと、 結果テーブルがひとつのペイロードを強調表示しました。レスポンス長が大きく変化し、かつ エラーシグネチャに一致している — アプリがデータベースのエラーを漏らしていました。

典型的な認証バイパスも通ります。
username: ' OR '1'='1' --
password: 何でもよい
管理者としてログインできました。AIトリアージ をクリックすれば、モデルが試行全体を読み返し、 どのペイロードが意味を持ち、どれがノイズで、なぜそう言えるのかを説明してくれます。
この記事の要点
どちらの脆弱性も特別なものではありません。モデルが見つけたものは、自分でも見つけられたはずです。 その点ははっきりさせておきたいと思います。ここで主張したいのは、もっと小さなことだからです。
変わったのは、「気づく」から「理解する」までの距離 でした。パッシブスキャナは、 私が見ようと思う前に反射箇所を指し示していました。ファザーは100件のレスポンスを採点し、 意味のある1件だけを手渡してくれました。すでに開いていたタブから一度も離れず、 リクエストを別のツールに貼り付けることもありませんでした。
言いたいのはそれだけです。プロキシがなくなったわけではありません。 ブラウザの中に移動し、そして「飽きることのないアナリスト」を連れてきたのです。
この記事は Medium にも掲載しています · Medium
