Hello there, ('ω')ノ
1. きっかけは“なんとなく”の調査
研究者は特に大がかりな準備をしていたわけではなく、Slackのサブドメイン（slackb.com）を確認中に「もしかして…」と気軽に試したのが始まりでした。
👉 ハッカー的思考ポイント 「大手サービスでも古い脆弱性は残っているかもしれない」という直感を持ち、深く掘らずともまずは試してみることが重要です。
2. CL.TE型リクエスト・スマグリングの実行
彼が投げたリクエストはシンプルでした：
POST / HTTP/1.1 Host: slackb.com Content-Length: 13 Transfer-Encoding: chunked 0 GET /some/endpoint HTTP/1.1 X-Test: value
- Akamai（フロントのリバースプロキシ） →
Content-Lengthを信じて処理 - Slackバックエンド →
Transfer-Encodingを信じて「次のリクエスト」を待つ
結果：フロントとバックの解釈がずれて、次のユーザーのリクエストが「密輸」されたGETリクエストと一緒に処理される状況に。
3. どうやって影響を確認するのか？
攻撃者が最初に見るのは レスポンスの変化 です。
- 通常なら200や404を返すはずが、意図せぬ応答が返る
- レスポンスに「自分が仕込んだヘッダ」が混ざっている
- 他ユーザーのセッションデータが見える
👉 これらは「境界ズレに成功した証拠」になります。
実際、Slackのケースではセッションクッキーを盗み出せる可能性が確認されました。これは即ち、他人のSlackアカウントを乗っ取れるということです。
4. もし攻撃を拡張したら？
単なるセッション乗っ取りにとどまらず、スマグリングはさらに危険な攻撃の基盤になります。
- キャッシュポイズニング：レスポンスを汚染し、多数のユーザーに悪意あるコンテンツを配布
- XSS挿入：レスポンスにJavaScriptを混ぜ、全ユーザーのブラウザを制御
- CSRF強化：セッション混線を利用して、他人のアカウントで操作を実行
Slackのケースでは即座に修正されましたが、もし攻撃者が悪用していたら「大規模アカウント乗っ取り」に発展する可能性がありました。
5. 報告と修正
Slackのセキュリティチームは脆弱性を確認後、迅速に修正。バグハンターには \$6,500 の報酬が支払われました。
研究者自身も「こんな古いバグがSlackに残っているとは思わなかった」と語り、発見をピザで祝ったそうです。
6. 学べること
古典的脆弱性でも侮れない HTTPスマグリングは2005年に発見されましたが、2020年代でも依然として大手サービスに残っている。
試してみる精神が重要 高度な自動化や複雑なファジングよりも、シンプルな「試行」が決定打になることもある。
入力→解釈→影響の流れを意識 攻撃者は常に「入力（ヘッダ）」「解釈（フロント/バックの食い違い）」「結果（他人のレスポンス）」を追って弱点を探す。
まとめ
Slackのケースは、「古くて単純な脆弱性がいかに強力か」を示す好例です。 攻撃者視点で言えば、わずかなヘッダの矛盾が世界的サービスを突破する突破口になり得る。
防御側は、フロントとバックのリクエスト処理の一貫性を保証し、不正なヘッダは即座に拒否する設計が欠かせません。
Best regards, (^^ゞ
