Cookieのセキュリティを改善する Scheming Cookiesについて

HTTP cookie internet-draft

Chromeが「Cookie の SameSite=Lax をデフォルト化」を進めたことは記憶に新しい。
asnokaze.hatenablog.com

Cookieの改善は引き続き議論されており、Cookieの扱いでスキーム（http://やhttps://）を考慮に入れることが検討されている。

Incrementally Better Cookies

Cookieのセキュリティ改善を精力的に行っているGoogleのMike West氏は、Secure属性の利用が30%、"__Secure-"プレフィックスの利用が0.18%ほどにとどまっていると述べており(リンク)、セキュリティ改善のためにCookieの扱いを段階的に変更していくことを考えている。

同氏がIETFに提出している「Incrementally Better Cookies」では、Cookieを次のように段階的に改善することを提案している。

  1. 「SameSite = Lax」をデフォルトにする
  2. 「SameSite = None」にするにはHTTPSから配信される必要がある
  3. same-siteはスキームを考慮にいれるようにする (Schemeful Same-Site)
  4. Cookieはスキームを尊重する必要がある (Scheming Cookies)
  5. 非セキュアなスキームのCookieは、セッションの最後に削除する
  6. セッションの定義を厳しくする

すでに、最初の2つは実施されている。これに続く、Schemeful Same-Siteや、Scheming Cookiesなどについて簡単に書いていく。

ただし、同氏がBlink-devで「Reducing web compatibility risk.」述べているように、昨今の状況を鑑みてWebの互換性を壊しうる変更はすぐにブラウザには入らないだろう。

Schemeful Same-Site

Same-Site の判定は、eTLD+1である。

例えば下記はsame-siteである。

また、https:// と http:// は考慮に入らないが、Schemeful Same-Siteではスキームを考慮にいれるという変更である。

Same-site Cookieの場合は、https://example.comでセットされたcookieは.http://www.example.com へのリクエストでは付加されません。逆もそうなります。

Scheming Cookies

(same-site属性なしでも) スキームを考慮するようにします。Scheme-Bound Cookies とも呼ばれます。

ブラウザがCookieを保存する際に、スキーム情報も保存します。ブラウザは今までの条件に加えスキームも一致している場合のみ、Cookieを送信します。

非セキュアなCookieの失効

次の段階として、非セキュアなスキームでセットされたCookieをセッション終了時に失効することも検討されている。