Skip to content

Instantly share code, notes, and snippets.

@azu

azu/README.md

Last active November 2, 2022 08:00
Show Gist options
  • Save azu/8e70827e3a83b3038a9ceb8d5e596ec6 to your computer and use it in GitHub Desktop.
Save azu/8e70827e3a83b3038a9ceb8d5e596ec6 to your computer and use it in GitHub Desktop.
Download ZIP
サブドメインをユーザーホスティングサイトに使うときのパターン(Same Origin/Cookie/Public Suffix List)
Raw
README.md

サブドメインをユーザーホスティングサイトに使うときのパターン

hoge.example.com でユーザが作成したサイトをホスティングして、任意のJavaScriptを実行できる状態にしたいケース。 サブドメインを分けることで、Fetch APIなどはSame Origin Policyを基本にするため、別のサブドメインや example.com に対するリクエストなどはできなくなる。

一方で、CookieはSame Origin Policyではない。 デフォルトでは、hoge.example.com から example.com に対するCookieが設定できる。 これを利用したDoS(Cookie Bomb)やこの挙動を組み合わせた別の脆弱性に利用できる場合がある。

📝 example.comがログイン機能などを持っているときにこの問題は起きやすい。セッションなどもないただのサイトの場合は、どこまで問題になるかの知見はない。

Patterns

次のパターンで、サブドメインを分けた方にホスティングを行なっているサービス(ここではexample.comの運営者が運用しているサービスのこと)への影響を回避できる。

  • サブドメインだけを使うパターン
    • hoge.example.com をクライアントサイト
    • example.com は使わない(別ドメインのLPなどへリダイレクト)
  • Public Suffix Listを使うパターン
    • hoge.example.com をクライアントサイト
    • example.com をLP
    • PSLにexample.comを登録する

サブドメインだけを使うパターンはexample.comは使わないで、ユーザーホスティングサイト専用のものとして扱うということ。 Public Suffix Listを使うパターンは、PSLに登録することでPSLを利用するブラウザが、サブドメインを別の"Site"として認識させる方法。

PSLは申請性でむやみに増やすと大変なので、ホスティング専用のドメインを使う方が良さそう。

Examples

関連

More

もっと詳しいケーススタディはコメント欄に書いてくれる

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment