##はじめに
この記事はプログラミング初学者による備忘録用の記事であり、また、少しでも他の初学者のお役に立てればと思い書いています。
今回は、Chromeの検証機能にてIndicate whether to send a cookie in a cross-site request by specifying its SameSite attributeというIssuesが発生しましたので、解決策及びIsuuesに関する情報を記録しておきたいと思います。
間違いなどがございましたら、ご指摘のほどよろしくお願い致します。
##Issuesの内容
Indicate whether to send a cookie in a cross-site request
by specifying its SameSite attribute
どうやら、クッキーのSameSite属性が設定されていないか無効であるため、設定してくれと警告されているようです。
SameSite属性を設定することで、クロスサイトのコンテキストでクッキーが設定されることを防ぎ、ユーザーデータが誤って第三者に漏れたり、クロスサイトリクエストフォージェリが発生したりするのを防ぐことができるとのこと。
さらにメッセージを読むと、
・クッキーがクロスサイト・コンテキストに設定されることを意図している場合は、SameSite=None or Secureを指定(Secure属性を使用できるのはHTTPS経由で送信されるCookieのみ)
・クロスサイト・リクエストでクッキーを設定しない場合は、SameSite=StrictまたはSameSite=Laxを指定
上記のようなルールに従ってCookieの属性を更新することで、Issuesは解決できるようです。
##SameSite属性とは
SameSite 属性により、サーバーがオリジン間リクエスト (ここでサイトは登録可能なドメインによって定義されます) と一緒にクッキーを送るべきではないことを要求することができます。これは、クロスサイトリクエストフォージェリ攻撃 (CSRF) に対していくらかの防御となります。
SameSite属性には、ユーザーが意図しない形でのCookieの送信を発生させないようにする特徴があると言えます。
引用:MDN HTTP Cookie の使用 (Cookie の送信先の定義)
使用例
例えば、https://example.com というページに、https://www.google.com/ へのリンクがあり、以前 https://www.google.com/ にアクセス済みでクッキーを受け取っていた場合、再度リンク先に送信するリクエストデータの中に、以前に受け取った期限切れではないクッキーデータが存在する場合登録されます。この動作はCSRFなどの脆弱性を生む原因になるので、その対策としてSameSite属性が存在しています。
重要なこと
セキュリティやプライバシーの観点で重要なことは、cross-siteからのリクエストであり、そのリクエストに Cookie を含めるかどうかを決めるのがSameSite属性の役割であるといえます。
##SameSite属性に指定できる値
指定できる値は Strict, Lax, None の3つです。
指定する値によって、Cookieの扱い方が異なるので下記の表にまとめておきます。
| SameSite属性の値 | 意味 |
|---|---|
| None | 全てのcross-siteなリクエストに対して Cookie が付与されます。つまり、Noneを使うことで、意図的に第三者のコンテキストでクッキーを送信してほしいことを明確に伝えることができます。 例えば、埋め込みコンテンツ、アフィリエイトプログラム、広告、複数のサイトへのサインインなど、他のサイトが利用するサービスを提供している場合は、Noneを使用して意図を明確にする必要があります。 |
| Strict | 他のドメインへのリクエストを送る際、クッキーはセットされず、same-siteに対するリクエストにのみCookieが付与されます。つまり、クッキーはファーストパーティのコンテキストでのみ送信されます。 例えば、Aサイトでログインしている状態で、Bサイト上にあるAサイトへのリンクをクリックした場合、リクエストにCookieが付与されないため未ログイン状態になり、再度ログイン処理や再読み込みが必要となります。 |
| Lax | トップレベルのナビゲーションで、尚且つメソッドがsafeであれば、他のドメインへのリクエストであってもクッキーをセットします。 POSTメソッドを使ったフォームのような、HTTPメソッドによるcross-siteなトップレベルのナビゲーションに対してはCookieが付与されません。従って、POSTメソッドなどを使ったフォームのサブミットに対するCSRF攻撃の対策として有効です。 |
注意:
StrictもLaxも、サイトのセキュリティを完全に解決するものではありません。クッキーはユーザーのリクエストの一部として送信されるので、他のユーザー入力と同じように扱う必要があります。つまり、入力をサニタイズし、検証するということです。サーバー側のパスワード等の漏洩厳禁なデータを保存するためにクッキーを使用してはいけません。
##LaravelでSameSite属性の設定方法
config/session.phpの'same_site' => null,を変更する。
/*
|--------------------------------------------------------------------------
| Same-Site Cookies
|--------------------------------------------------------------------------
|
| This option determines how your cookies behave when cross-site requests
| take place, and can be used to mitigate CSRF attacks. By default, we
| do not enable this as other CSRF protection services are in place.
|
| Supported: "lax", "strict", "none"
|
*/
'same_site' => null,
##補足
・safeなメソッドとは
RFC7231 4.2.1 Safe Methodsによると、
・GET
・HEAD
・POTIONS
・TRACE
の4つをsafeなメソッドとしており、POSTやDELETEより比較的に安全といえる。
・same-site と cross-siteの違いとは
簡単にいうと、ドメインが同じであればsame-siteであり、ドメインが異なればcross-siteです。
詳しい違いは下記リンク先を参考にしてください。とてもわかりやすい記事でした。
web.dev [Understanding "same-site" and "same-origin"]
・トップレベルナビゲーションとは
アドレスバーに表示されているURLのオリジンドメインをトップレベルナビゲーションとして、オリジンドメインAからオリジンドメインBに移るような画面遷移の場合、CSRFの対象にならないので安全であると判断してクッキーの付加が許可されているのだと思われます。
例:
http://sample.com/ にあるリンクを踏んでhttp://another.com/ に遷移した場合、アドレスバーにはhttp://another.com/ が表示されるので、これはトップレベルナビゲーションであるといえます。
##おわりに
米Googleは2020年4月に新型コロナウイルスの影響を受け、Google Chrome 80からの SameSite Cookieの仕様変更を一時的にロールバックすると発表がありました。
新型コロナウイルスが収まり次第、また発表がありそうですね。
##参考文献
MDN HTTP Cookie の使用 (Cookie の送信先の定義)
web.dev [SameSite cookies explained]
web.dev [Understanding "same-site" and "same-origin"]
draft-ietf-httpbis-rfc6265bis-06#section-5.2
rfc7231 - IETF Tools
SameSite 属性を使った Cookie のセキュアな運用を考える