WebSocket Turbo Intruder：WebSocketの“盲点”を掘り起こす高速ファジングの発想

本記事は、PortSwigger Research の「WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine」を元ソースとして、その主張と関連する公式情報（PortSwigger上の補足ソース）に基づき要点をまとめます。

概要

Webアプリ診断では、HTTPからWebSocketへプロトコルが“アップグレード”した瞬間に、多くのテスターやツールが追従できず、分析が浅くなりがちだ——という指摘が元ソースの出発点です。結果として、Broken Access Controls（アクセス制御の不備）やRace conditions（レースコンディション）など、本来は通信の継続性や双方向性の中で露出しやすい不具合が見落とされる「大きな盲点」になり得る、という問題意識が提示されています。

この盲点を突く文脈で登場するのが「WebSocket Turbo Intruder」です。これはBurp Suite向けの拡張として、WebSocketメッセージを対象に、カスタムPythonコードによるファジングを行えること、さらにHTTPを介してWebSocket接続へ干渉するための“ミドルウェア・プロキシ”を用いることが説明されています。WebSocketを「ブラウザ内の特殊な通信」として隔離せず、テスト可能なインターフェースに引き戻す発想が核だといえます。

詳細

元ソースが強調するのは、WebSocketに切り替わっただけでテスト観点や道具立てが急に弱くなる現実です。WebSocketは単発リクエストではなく、接続が継続し、その上で多数のメッセージが往復します。ここに権限境界のほころびや、並行処理・順序依存の欠陥が潜みやすいにもかかわらず、一般的なスキャナや手作業の手順が「アップグレードの壁」で止まり、深掘りが難しくなる、という構図が示されています。

ではWebSocket Turbo Intruderは何を“できるようにする”のか。BApp Storeの説明によれば、WebSocketメッセージをカスタムPythonコードでファズでき、さらにHTTP経由でWebSocket接続とやり取りするためのミドルウェア・プロキシを使う、とされています。ポイントは、単にメッセージを投げるだけではなく、テストの自動化・反復・変異（mutation）といったファジングの土台をWebSocketへ持ち込むことにあります。これにより、例えば認可チェックの抜け（誰がどのメッセージを送れるべきか）や、競合状態の再現（タイミングや順序の揺らぎで壊れる条件）といった、WebSocketで顕在化しやすいクラスの不具合を、より体系的に探れる可能性が広がります。

また、PortSwiggerにはTurbo Intruderそのものに関する研究発表もあり、速度を重視して“膨大なリクエスト”を扱う研究グレードの拡張として位置づけられています。WebSocket Turbo Intruderは、この「高速・大量試行」という思想を、WebSocketのメッセージングへ寄せた取り組みとして読むと理解しやすいでしょう。さらに、PortSwigger上の研究者プロフィール情報では、Zakhar Fedotkinによる関連研究として本記事が挙げられており、公開日として2025年9月17日が示されています。つまり、これは単発のTipsではなく、WebSocket診断を“従来のHTTP中心のワークフローから取りこぼさない”ための、継続的な研究の流れの中にある提案だと位置づけられます。

実務的には、「WebSocketだから難しい」で止めず、どのメッセージがどの状態で送信され、どの応答が返るかを“入力と出力”として捉え直すことが重要になります。そのうえで、ファジング可能な形に落とし込む（スクリプト化できる形にする、反復可能にする、HTTPなど既存の介入手段と接続する）という設計が、WebSocketの盲点を“金脈”に変える、というのが元ソースの主張の骨子です。