immedioテックブログPublicationへの投稿
🛡️

tokyo.jpでわかるCookieの防波堤：Public Suffix List

yamatai12
に公開
Security
cookie
Public Suffix List
psl
クッキーモンスターバグ
tech

株式会社immedioのimmedioチームでエンジニアをしています。

背景

弊社では脆弱性診断や、ISMS認証に向けた取り組みをしています。
セキュリティに関する知識をつけたいなと思っていると、最近読んだ本で「クッキーモンスターバグ」、「Public Suffix List(PSL)」というcookieに関するセキュリティの話がありました。

https://gihyo.jp/book/2024/978-4-297-14571-2

クッキーモンスターバグとは

cookieのdomain属性は、cookieを受信することができるサーバーを指定します。
https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Cookies

サイト onlyone.tokyo.jpがあるとします。
cookieのdomain属性に本来指定できないtokyo.jpをバグにより指定できるとします。

Set-Cookie: session=abc123; Domain=tokyo.jp; Path=/; Secure; HttpOnly

その際、他のサイト（例：other.tokyo.jp）からも上のサイトで作成したcookieを上書きできてしまうという事象のことです。

実際過去にIE(Internet Explorer)の不具合でこのバグが起こっていたそうです。

https://blog.tokumaru.org/2017/11/ie-cookie-monster-bug-fixed-on-windows-10.html

Public Suffix List(PSL) とは

https://github.com/publicsuffix/list

jpやcomなどのTop Level Domain（TLD）と、co.jpやmeguro.tokyo.jpのような実質的にTLDのように振る舞うことが期待されるeffective Top Level Domain （eTLD）を管理しているリストのこと
引用

現在は GitHub で管理されています。
これはもともと Mozilla が管理を始めたものですが、今となってはこのファイルが多くのブラウザで使われています。

Public Suffix Listについて以下の記事で詳しく書かれていましたので紹介します。
こちらの記事ではこのリストのメンテナンスが重要でありながらボランティアベースとなっていることの問題やその他問題についても触れられています。

https://blog.jxck.io/entries/2021-04-21/public-suffix-list.html

tokyo.jpが確かにリストに登録されていました。
https://github.com/publicsuffix/list/blob/main/public_suffix_list.dat#L2028

本当にtokyo.jpをcookieのドメイン属性に指定できないのか検証

以下の都道府県型JPドメインtokyo.jpを持つサイトを見つけたので試しにcookieを作成します。
以下サイトは安全です。都道府県型JPドメインによる偽サイトの警告用のサイトです。

https://www.vill.mikurashima.tokyo.jp/

domain属性がmikurashima.tokyo.jpのcookieをchromedevtoolのconsoleで作成しました。

document.cookie = "test=test; Path=/; Domain=vill.mikurashima.tokyo.jp; SameSite=None; Secure";

getリクエストを見るとcookieが送信されています。

次にdomain属性がtokyo.jpのcookieを作成します。

このcookieは作成できませんでした。
tokyo.jpはPSLに登録されているため、主要ブラウザ実装ではDomain=tokyo.jpが拒否され、cookieは作成されません。

タイトルに記載のようにでPSLは防波堤ということなので対策が必要です。
次のように意図しないcookieの上書きはできてしまうことがあります。

重要なcookieにはdomain属性を指定しない

同一 eTLD+1（例：example.com）内での Domain=.example.com Cookieは、サブドメイン間で上書き可能です。
例）
foo.example.jpでdomain属性example.jpのcookieを発行する。
foo.example.jpにアクセスすると作成したcookieが送信される。
bar.example.jpにアクセスすると作成したcookieが送信される。

cookieの接頭辞による防御

https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Cookies#:~:text=扱われます。-,Cookie の接頭辞,-Cookie の仕組み

__Host-
cookie名にこの接頭辞がついている場合はSet-Cookieヘッダーが受け入れられるのはSecure属性で指定されており、安全なオリジンから送信されており、Domain属性を含んでおらず、Path属性が/に設定されている場合のみです。

実際に__Host-でcookieを作成してみます。

まずはdomain属性を指定したcookieを作成できないことを確認します。

次に__Host-を接頭辞に持つcookieを作成する為の条件を満たしたcookieを作成します。

確かにGetリクエストにcookieがあることを確認できました。

今後さらに知識を深めたいこと

cookieに関する攻撃

こちらで紹介されていました

https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers

  • cookie bomb
  • cookie tossing

Path属性の安全性について

以下の記事でPath属性の安全性についてまとめられていたので理解したいです。

https://qiita.com/HAYASHI-Masayuki/items/88a2b784bde1be9580a8

https://qiita.com/ockeghem/items/6590b2e18af1d062e780

最後に

  • クッキーモンスターバグ、PSLを理解することができました
  • cookieはPSLに加えてdomain属性を使用しなかったり、cookieの接頭辞に__Host-を使用するなど自分たちで防御する必要があります
  • PSLのメンテナンスには問題があることがわかりました
  • 偽サイトは今は簡単に作ることができるので気をつける必要があります
  • 都道府県型JPドメインを容易に取得できるのは知らなかったです

参考

immedioテックブログ
immedioテックブログPublication

リモートワーク、フレックスな環境でGoやReact、もしくはRemixでのFullStack-TS開発に興味のある方はぜひ一緒に働きましょう！

Discussion