http-terminator – AIを活用したHTTPリクエストスマグリング発見ツール

http-terminatorは、PortSwiggerが公開した調査用パイプラインです。大規模言語モデル（LLM）にHTTP仕様を読み込ませ、リクエストスマグリング攻撃を見つけ出させます。このツールから生まれた研究成果とあわせて公開されており、製品ではなく、研究の参考資料という位置づけです。

筆者は、このツールについて書かれた解説記事ではなく、現在のリポジトリそのものを読みました。中身は4段階のパイプラインです。2つの段階は単体で完結しますが、残る2つはBurpが必要です。しかも最後の段階では、リポジトリに同梱されていないシミュレーターも要ります。

9月27日に確認した時点で、公開されているmainブランチには、2026年7月22日付のコミット874682cが1件だけありました。

前提となる知識

本サイトでは2017年にMicrosoftのAzure Webアプリケーションファイアウォールを取り上げました。その記事はWAFが防ぐ攻撃の一つとしてリクエストスマグリングに触れていますが、仕組みまでは説明していません。そこで、ここで簡単に説明しておきます。リクエストスマグリング（デシンクとも呼ばれます）は、あるHTTPリクエストがどこで終わり、次のリクエストがどこから始まるのかについて、2台のサーバーの解釈が食い違うことを突く攻撃です。

フロントエンドのプロキシをバックエンドサーバーの前段に置き、両者が異なる形で解釈するリクエストを送ったとします。すると、バックエンドは送り込まれた入力の一部を、別のリクエストの冒頭として扱うことがあります。レスポンスポイズニングと呼ばれる手法では、再利用されているバックエンド接続上で次のユーザーが送ったリクエストが、攻撃者の仕込んだプレフィックスの続きとして完結します。その結果、そのユーザーは自分のリクエストへの応答ではなく、攻撃者のリクエストへの応答を受け取ります。PortSwiggerの研究者James Kettle氏は、この攻撃に関する手法や研究を公開しています。

仕様書からテストケースへ

PortSwigger自身の「HTTP Request Smuggler」は、Burp Suiteから対象をテストするツールで、新しいデシンク手法を探るための研究モードも備えています。これに対してhttp-terminatorは、文書を起点とするアプローチをとります。Claudeが仕様書から攻撃ベクトルの候補を抽出し、その候補が、生成、検証、調査の各段階に引き継がれます。

4つの段階

パイプラインは次の4段階で動きます。

• seeker（Python）：文書やRFCを読み込み、Claudeを通じてデシンクのベクトル候補を抽出
• flamer（Java）：抽出されたベクトルを、不正な形式のHTTPテストケースに変換
• validator：Burp拡張機能。生成されたリクエストを対象に送信し、確認済みのデシンクと未確認の異常を報告
• investigator（Python、Claude Codeで駆動）：検出結果を再現して確認し、その後の影響を追跡して報告書にまとめる

実際に再現しようとすると、ドキュメントの記述がわかりにくくなります。seekerとflamerは単体で完結し、必要なのはPythonまたはJavaとAnthropicのAPIキーだけです。残りの2つは、そうはいきません。

validatorのドキュメントは、注意深く読む必要があります。ルートのREADMEは、実行に商用版のBurp Suiteが必要だと記載しています。一方、validator自身のREADMEは、テストスイートがBurp CommunityでもProfessionalでも動作し、Professional専用のテストはCommunityではスキップされると説明しています。両者が扱っているのは別のことで、片方は段階の実行、もう片方はそのテストです。リポジトリ内で実際に矛盾しているのはビルドに関する記述です。validatorのREADMEには、ビルドがbulkScan-all.jarに依存し、このjarはリポジトリに含まれていないと書かれています。ところが、実際にはvalidator/bulkScan-all.jarとしてコミットされており、ビルドファイルもそれを参照しています。investigatorはさらに、Claude Codeと稼働中の対象に加えて、外部のMCPシミュレーターとBurp Organizerも必要とします。

データが各段階を流れる様子

まずseeker/で作業します。必要なのはPython 3.11以降、AnthropicのAPIキー、ネットワーク接続です。READMEでは、このディレクトリからパッケージをインストールします。

これでseekerのコマンドラインツールが入ります。次のコマンドは、ユーザーが作成するURLリスト（処理対象の文書URLを並べたテキストファイル）を読み込みます。そして文書を取得し、抽出したセクションをseeker.dbに保存します。試すだけなら、リポジトリ同梱のサンプルリストseeker/fixtures/urls.txtを指定することもできます。

マニフェストにはこの実行の記録が残ります。SQLiteデータベースに保存されたセクションは、seekerのqueryコマンドで確認できます。

このコマンドは、抽出されたデシンクベクトルのセクションを選び出します。flamerがリクエストを生成した後は、seekerでリクエストIDから元のセクションをたどれます。

山括弧の部分は、flamerのデータベースにあるIDに置き換えてください。traceを使えば、生成されたリクエストと、その元になったseekerのセクションを結び付けられます。

続いてflamer/で作業します。必要なのはJava 21、Gradle、AnthropicのAPIキーです。デフォルトの実行では、../seeker/seeker.dbにある未処理のセクションを読み込みます。生成したリクエストは、flamer自身のproduction.dbに書き込みます。

Claudeを使うにはAPIキーが必須です。flamerのREADMEには、生成したリクエストを保存しない実行方法も載っています。

flamerのデータベースに保存済みのリクエストを表示するには、ドキュメントにあるdumpオプションを使います。

flamerのGradleタスクは、生成したデータベースをvalidatorのディレクトリにコピーします。

validator/では、READMEの手順に従ってBurp拡張機能のjarをビルドします。

ドキュメントによると、出力はbuild/libs/validator.jarです。BurpのExtensions > Installed > Addからこのファイルを選んで読み込みます。

この拡張機能を手動で読み込む作業は、validatorのlivetestingスイートとは別物です。後者はBurp CommunityでもProfessionalでも使えます。Communityではプロフェッショナル専用のテストがスキップされ、Professionalでは実行されます。ルートのREADMEが求める商用版Burpは、検証段階を実行するための要件であり、このテストスイートのためのものではありません。

investigatorのREADMEには、そのままコピーして使えるコマンドがありません。必要なのは、Claude CodeとAnthropicのAPIキー、turbo-simulatorのMCPツールを公開する外部シミュレーター、Burp Suite、Burp Organizer形式の検出結果ソースです。加えて、テストを許可されている対象も要ります。これらの外部コンポーネントは、リポジトリには付属していません。

seekerは、リストに挙げた文書を取得してClaudeを呼び出します。flamerもClaudeを呼び出しますが、アップロード用フラグを自分で有効にしない限り、データベースはローカルにとどまります。この2つの段階では、生成されたリクエストが対象に送信されることはありません。Burpと対象へのテスト許可が必要になるのは、検証段階からです。

すべてを動かせなくても価値はあるか

このリポジトリが示しているのは、設計そのものです。ツリーには、seekerが仕様書から攻撃ベクトルの候補を引き出すためのプロンプトと、flamerがそのベクトルをテストケースに変換するコードが収められています。PentestGPTは現在、Claude CodeやCodexで駆動する形で、テストのパイプライン自体を実行します。これに対してhttp-terminatorは、仕様書を出発点として、特定の種類のバグに絞ってモデルを向けています。

そう捉えるなら、このリポジトリは、言語モデルに仕様書を読ませてデシンクのテストケースを生成させるための、実際に動く設計例であり、中身を検証できる資料です。ただし、読んだだけでは、それが機能すると確認したことにはなりません。確認するには、許可を得た対象に対してパイプラインを実行する必要があります。本記事ではそれを行っていないため、このアプローチの性能を測った結果は、ここには含まれていません。

筆者は2026年9月16日に、2026年7月22日付のmainコミット874682cの時点で、リポジトリとそのREADMEを読みました。上記の内容はすべて、リポジトリとそのGitHubページから読み取ったものです。パイプラインは実行していません。

http-terminatorは次のURLで入手できます：https://github.com/PortSwigger/http-terminator