Hello there, ('ω')ノ
✅ 目的
WebSocket関連の脆弱性の中には、実際の通信メッセージ（JSONなど）を改ざんするだけでは見つからない設計ミスが存在します。 これらは、接続開始時の「ハンドシェイク」HTTPリクエストを改ざんすることで初めて発見・悪用可能です。
🧠 ハンドシェイクとは？
WebSocket接続は以下のようなHTTPリクエストで始まります：
GET /ws/chat HTTP/1.1 Host: vulnerable-website.com Upgrade: websocket Connection: Upgrade Cookie: session=xyz123 X-Forwarded-For: 127.0.0.1
このリクエストは、HTTPの形をしていますが、接続が確立されるとHTTPではなく双方向WebSocket通信に切り替わります。
🕳️ 典型的な設計ミスと脆弱性
| 脆弱性の種類 | 内容 |
|---|---|
| X-Forwarded-Forの信頼 | 攻撃者がIPアドレスを偽装できると、アクセス制限を回避できる |
| セッション管理の誤解 | Cookieを除いたトークンやヘッダーでセッションを判定してしまうと、偽装が可能になる |
| カスタムヘッダーの過信 | アプリ独自のヘッダー（例：X-User-Role: admin）が検証されずに信頼される |
🛠 Burpでの攻撃手順（ハンドシェイクの改変）
- Burpの「Proxy」→「HTTP history」で、WebSocket接続の
Upgrade: websocketリクエストを探す - 右クリック→「Send to Repeater」
- 鉛筆アイコン（✏️）をクリックしてWebSocketハンドシェイク編集モードへ
- 以下のような改変を試す：
X-Forwarded-For: 127.0.0.1 X-User-Role: admin Authorization: Bearer forged-token
- 「Connect」で接続を試み、成功すれば不正な権限でWebSocket通信が可能に
✅ 攻撃の一例：X-Forwarded-For偽装
サーバー側がIPアドレスでアクセス制限をしている場合：
X-Forwarded-For: 127.0.0.1
このように偽装することで「ローカルホストからのアクセス」と誤認させて管理者専用の機能を呼び出せるケースがあります。
✅ まとめ
WebSocketのセキュリティ検査では「接続開始時のHTTPリクエスト」＝ハンドシェイクも重要な攻撃対象です。
| 攻撃観点 | 検証ポイント |
|---|---|
| ヘッダー偽装 | X-Forwarded-For, X-User-*, Authorization など |
| セッショントークン操作 | Cookie以外のセッション要素があるか |
| 信頼境界の曖昧さ | サーバー側がどの情報を信用しているか調査 |
Best regards, (^^ゞ
