exploiting-http-request-smuggling

exploiting-http-request-smuggling skill の概要

exploiting-http-request-smuggling skill でできること

exploiting-http-request-smuggling skill は、Content-Length と Transfer-Encoding をめぐるフロントエンドとバックエンドの解釈不一致によって起きる HTTP request smuggling を検出・評価するための skill です。複数層の Web アプリ、リバースプロキシ、ロードバランサー、CDN を対象に、実務で使えるワークフローを求める権限のあるテスターに向いています。

どんな人がインストールすべきか

リクエストが複数の HTTP プロセッサを通過するアーキテクチャで Security Audit を行っているなら、exploiting-http-request-smuggling skill をインストールする価値があります。特に、すでに HTTP desync を疑っている、影響範囲を確かめたい、あるいは通常のブラウザベースの確認では見落とすケースを再現性のある方法でテストしたい場合に有効です。

何が違うのか

この skill は単なる汎用プロンプトではなく、検出ワークフロー、raw request のプロービング、アーキテクチャのフィンガープリントを前提に作られています。そのため、高レベルな解説よりも実際の評価に向いていますが、同時に、権限のある対象、到達可能なターゲット、そして安全にテストできるだけの文脈があることを前提としています。

exploiting-http-request-smuggling skill の使い方

インストールして、見るべきファイルを把握する

まずは skills manager から exploiting-http-request-smuggling install のフローでインストールし、最初に SKILL.md を読みます。実際のセットアップの文脈をつかむには、references/api-reference.md と scripts/agent.py も確認してください。これらのファイルには、想定されているプローブの順序、CLI の形、そして skill で使われる具体的な helper functions が示されています。

あいまいな目的を、使えるプロンプトに変える

exploiting-http-request-smuggling usage に入れる情報としては、ターゲット URL、アプリが proxy や CDN の背後にあるかどうか、スタックについて既知の情報、そして成功条件が挙げられます。たとえば、「https://app.example.com を CL.TE と TE.CL の smuggling について評価してください。Burp Suite は利用可能とします。結果、確信度、安全な次の一手を返してください。」のように書くとよいでしょう。「このサイトを調べて」よりも、こうした依頼のほうが skill にテストの枠組みを与えられます。

リポジトリが実際にサポートしているワークフローに沿う

まずはアーキテクチャのフィンガープリントから始め、次に起こりやすい parsing mismatch の種類をテストし、最後に timing や desync の挙動を比較します。リポジトリの参考資料は identify_architecture、test_clte_detection、test_tecl_detection、test_te_te_detection を中心に構成されているため、あらゆる攻撃バリアントを一度に求めるのではなく、適切なプローブ経路を選べる証拠を skill に与えてください。

安全性と出力の制約をはっきり指定する

この skill は、何をしないかを明示すると最も効果を発揮します。破壊的な payload は避ける、ノイズの多い反復テストはしない、承認された時間枠の中で進める、といった条件を伝えてください。Security Audit にそのまま使える出力がほしいなら、技術的なテスト手順に加えて、短い評価計画、想定される指標、簡潔な報告フォーマットも求めると実用性が上がります。

exploiting-http-request-smuggling skill の FAQ

これは上級者専用ですか？

いいえ、ただし「クリックしてすぐ使える」初心者向けの skill でもありません。exploiting-http-request-smuggling skill は、proxy、request header、そしてフロントエンドとバックエンドの不一致がなぜリスクになるのかを理解している人に最も向いています。

使わないほうがいい場面は？

明示的な許可がないシステム、付随的な影響を許容できない本番環境、あるいは中継の HTTP parsing layer を持たない単一サーバーのアプリには使わないでください。proxy chain が存在しないなら、exploiting-http-request-smuggling の価値はすぐに下がります。

通常のプロンプトと何が違いますか？

通常のプロンプトでも request smuggling の一般論は説明できますが、この skill はインストール時の利用、テスト順序、helper artifacts を中心に組み立てられています。そのため、理論から評価ワークフローへ移る必要がある場面では、exploiting-http-request-smuggling guide のほうが有用です。

Burp Suite やスクリプトベースのテストに向いていますか？

はい。リポジトリは手動テストとスクリプト支援テストの両方を示しているため、Burp Suite ベースのワークフローにも Python 駆動のチェックにも適しています。環境が raw socket テストをブロックする、またはパッシブ評価しか許可しないなら、この skill はおそらくインストール対象として適していません。

exploiting-http-request-smuggling skill を改善するには

ターゲットの文脈を、より具体的に伝える

最も大きく品質が上がるのは、HTTP chain の構成を明示することです。CDN、reverse proxy、WAF、アプリサーバー、そして既知の header normalization の挙動を含めて説明してください。exploiting-http-request-smuggling for Security Audit の用途では、response headers、redirects、timeout のパターンで何を観測したかも添えると、skill はよりありそうな parser mismatch に集中できます。

URL だけでなく、適切な証拠を共有する

exploiting-http-request-smuggling からより強い出力を引き出したいなら、サンプル request、注目すべき response の差分、遅延が片方の path だけで起きるのか、片方の host だけで起きるのかを含めてください。skill は、単なるドメイン名よりも、header の挙動や timing の手がかりからずっとよく推論できます。

1 回目の結果をもとに絞り込む

最初の実行では、起こりそうな smuggling の種類を絞り込みます。そのうえで、より鋭い 2 回目の依頼を出してください。たとえば、「これらの headers と 5 秒の delay を前提に、CL.TE のみのテスト計画に絞り込んでください。」のようにすると、exploiting-http-request-smuggling usage はより精密になり、反復監査でのノイズも減ります。

よくある失敗パターンに注意する

典型的な失敗は、アーキテクチャ確認をせずに過剰にテストしてしまい、false positive と時間の浪費を招くことです。もう 1 つは、検出の確信度、安全な検証、報告可能な証拠を求めずに、いきなり exploitation へ進ませようとすることです。よりよい exploiting-http-request-smuggling skill のプロンプトは、こうしたチェックポイントを明示的に求めます。