Hello there, ('ω')ノ
記事
「Finding My First Bug: HTTP Request Smuggling」 AMAN SINGH (2021年1月)
ねらい
この記事は、筆者が初めてバグバウンティで有効なバグを報告し、\$200を獲得した体験談です。 対象はHTTPリクエストスマグリング（HRS）。 自分のリコン作業 → バージョン特定 → 攻撃リクエスト作成 → 内部リソースアクセス成功という流れを丁寧にまとめています。
ストーリーと実践手順
1) リコン：サブドメインを調査
- 操作：見つけた全てのサブドメインを訪問。
- 観察：あるサブドメインは 403 Forbidden を返し、レスポンスヘッダーにWebサーバのバージョン情報が露出。
- なぜ：古いバージョンが使われていれば既知の脆弱性が狙える。
2) Burpのパッシブスキャンでヒントを得る
- 操作：BurpSuiteのパッシブスキャナがサーババージョンを検出。
- 観察：該当バージョンはHRSに脆弱と報告される。
- なぜ：ツールのヒントは攻撃対象を絞り込む材料になる。
3) HRSの原因を確認
- サーバ構成：Nginxベースの拡張Webサーバ（古いバージョン）。
問題点：フロントとバックエンドで異なるHTTPヘッダ解釈をしていた。
- フロント：Content-Length を採用
- バックエンド：Transfer-Encoding を採用
- なぜ：この不一致がデシンク攻撃を可能にする。
4) 攻撃リクエストを作成
送信リクエスト例：
POST /i HTTP/1.1 Host: ... Connection: keep-alive Content-Length: 55 Transfer-Encoding: chunked 0 GET /publicDocs/ HTTP/1.1 Host: ... foo: x
意図：
- フロントは「Content-Length: 55」を読み、リクエストが終了していないと判断。
- バックエンドは「chunkedエンコーディング」を採用し、残りを次のリクエストと解釈。
- 結果：
GET /publicDocs/が密輸リクエストとして処理される。
5) 観察された影響
- 本来403 Forbiddenになるリソースが、200 OKで表示。
- スタッフ専用ログインページや内部文書が参照可能に。
- なぜ：HRSによりフロントエンドのアクセス制御をすり抜けたため。
学びと攻撃者の視点
- 小さな情報（サーババージョン露出）から突破口を見つける。
- Burpのアラートはきっかけにすぎない → 自分で検証して有効性を確認することが大事。
- HRSは「解釈のズレ」を突く攻撃 → 特に古いリバースプロキシ環境は要注意。
防御策（開発者・運用者目線）
- 最新バージョンのWebサーバを使用
- Content-Length と Transfer-Encoding の併用を禁止
- リバースプロキシとバックエンドのHTTP実装を統一
- セキュリティテストでリクエストスマグリングを定期チェック
まとめ
攻撃者の流れはこうでした：
- サブドメイン調査 → 古いWebサーバを発見
- Burpのヒントで HRS脆弱性を疑う
- CL + TEヘッダの競合リクエストを送信
- 内部ページへの不正アクセス成功
- レポート提出で\$200報奨金獲得
つまり、「小さなバージョン情報の漏洩」から大きな突破口を得られるという好例です。
Best regards, (^^ゞ
