※本記事にはプロモーションが含まれています。
SameSite属性を設定しているから、CSRF対策は万全。
そう考えていませんか。
確かにSameSiteは有効な防御手段ですが、サイトの構成によっては簡単に回避されるケースがあります。
この記事では、Web Security Academyのラボ「SameSite Strict bypass via sibling domain」をもとに、
- SameSite StrictでもCSRFが成立する理由
- サブドメインが持つリスク
- WordPressで実際に起こり得る構成ミス
を整理して解説します。
ラボ概要│SameSite Strictでも成立する攻撃とは
このラボでは、ライブチャット機能にWebSocketの脆弱性があり、クロスサイトWebSocketハイジャック（CSWSH）が成立します。
攻撃者は、同一サイト内の別サブドメインに存在するXSSを利用し、被害者のチャット履歴を取得します。
その結果、チャット内に含まれていたログイン情報が漏洩し、アカウントが乗っ取られるという流れです。
攻撃の流れ：サブドメイン経由で情報を抜き取る手順
- サイト内のサブドメイン（cms）を特定
- cmsのログインフォームに存在するXSSを利用
- XSS経由でWebSocket接続を開始
- チャット履歴を取得
- ログイン情報を抽出
- 被害者アカウントにログイン
なぜ攻撃が成立するのか：SameSiteの仕様と限界
SameSiteは同一サイトでは無効にならない
SameSiteはクロスサイトリクエストを制限する仕組みですが、以下のような構成は同一サイトとして扱われます。
- example.com
- cms.example.com
この場合、サブドメイン間の通信ではCookieが送信されます。
つまり、SameSite Strictであっても、サブドメイン経由の攻撃は防げません。
サブドメインの脆弱性が全体に波及する
今回のラボでは、
- cmsドメインにXSSが存在
- same-site扱いのためCookie付き通信が可能
- WebSocketもそのまま利用できる
結果として、CSRF対策が実質的に無効化されています。
WebSocketもCSRFと同じ問題を抱える
WebSocket接続時にはCookieが送信されます。
そのため、
- 認証済みセッションがそのまま使われる
- 外部から接続を誘導できる
という性質があります。
これがクロスサイトWebSocketハイジャック（CSWSH）です。
CSRFの基本的な仕組みについては、以下の記事でも解説しています。
攻撃者視点で見るポイント
攻撃者が確認するポイントはシンプルです。
- サブドメインに脆弱性があるか
- Cookieがsame-siteで共有されているか
この2つが揃えば、メインサイトの防御を回避できます。
WordPressで起こり得る実装ミス
放置されたサブドメイン
- old.example.com（旧サイト）
- dev.example.com（開発環境）
- blog.example.com（別WordPress）
これらに脆弱性があると、メインサイトに影響します。
プラグインやフォームの不備
- 出力エスケープ不足
- 入力値の未検証
こうした問題によりXSSが発生することがあります。
管理されていない機能
- チャット機能
- REST API
- WebSocket
見落とされやすい箇所です。
WordPressでは、ユーザー情報の露出や設定ミスも攻撃の起点になることがあります。
▶ wp-json/wp/v2/usersにアクセスされる理由｜WordPressユーザー列挙の仕組みと対策
対策：サブドメインとXSSを前提にした防御
サブドメインも含めて一元管理する
- 不要なサブドメインは削除
- 開発環境は公開しない
XSS対策を徹底する
- 出力時のエスケープ
- 入力値の検証
WebSocketの認証設計を見直す
- Cookie依存を避ける
- トークンベースの認証を検討する
SameSiteを過信しない
SameSiteは補助的な対策です。
単体では防げない攻撃が存在します。
実際に、企業サイトでも管理されていないサブドメインや不完全な公開状態が見られることがあります。
▶ URLがIPアドレスのまま公開されている企業サイトの実態
▶ 営業リスト作成で見えた企業サイトの実態│仮ドメインのまま公開されているサイトとセキュリティの話
セキュリティ診断でのチェックポイント
- サブドメインの洗い出し
- 公開されている旧環境の有無
- XSSの有無
- WebSocketの利用状況
- Cookieのスコープ設定
まとめ：一番弱いサブドメインが全体を崩す
SameSite Strictを設定していても、サブドメインに脆弱性があればCSRFは成立します。
重要なのは、個別の対策ではなく、サイト全体の構成を含めたセキュリティ設計です。