From 867dceef95eb77a8003d17ab904c88ce0f1e922f Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Mon, 12 May 2025 15:11:44 +0900 Subject: [PATCH 01/10] =?UTF-8?q?CSRF=E3=81=AE=E3=83=89=E3=82=AD=E3=83=A5?= =?UTF-8?q?=E3=83=A1=E3=83=B3=E3=83=88=E3=82=92=E8=BF=BD=E5=8A=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 122 ++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 content/docs/csrf/_index.md diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md new file mode 100644 index 0000000..63b5c3e --- /dev/null +++ b/content/docs/csrf/_index.md @@ -0,0 +1,122 @@ +# CSRF +## 概要 +CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Cookieを配布したサイトとは異なるクロスサイトリクエストへのCookieの送信を制御する属性です。Strict/Lax/Noneの3つが存在し、設定された値により制御が異なります。基本的には、StrictやLaxが設定されている場合、CSRFに対する防御として機能します。しかし、注意するべき事項としてSameSite属性は、各ブラウザによりデフォルトの挙動が変わってきます。そのため、ここでは各ブラウザでの挙動の違いを整理していきます。 + +## 影響 +各種ブラウザの挙動におけるSameSite属性の挙動ついて整理していきます。 +### Google Chrome +Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。 +そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 + +>Chromeに関する動作 +>"新しい SameSite=None; Secure Cookie 設定への対応準備"、Google検索セントラル +>https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja +>"SameSite Update"、The Chromium Projects +>https://www.chromium.org/updates/same-site/ + +この仕様は、2024年12月に確認したバージョン(131.0.6778.109)でも同様です。ただし、ChromeやEdgeにおいては、デフォルトの設定では注意が必要な点があります。それは、Cookieが生成されてから2分間はクロスサイトでCookieが送信される2分間ルールがあることです。2分間の間はクロスサイトでCookieを送信することができます。実際に下記のバージョンのブラウザで確認した所、現在も2分間ルールは顕在しているようです。 + +| ブラウザ | バージョン | 挙動 | +| :------------- | :------------- | :----------------------------------------------------- | +| Google Chrome | 131.0.6778.109 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | +| MicroSoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | + +また、Chromeでは下記のブログから2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。 + +> Anthony Chavez、Next steps for Privacy Sandbox and tracking protections in Chrome、https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings + +### Microsoft Edge +ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。そのため、SameSite属性のデフォルトはLaxに変更されています。 +また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様です。 +これは2024年12月に確認したバージョン(1310.2903.112)でも確認されています。その他にもこちらでも2分間ルールが存在しています。 + +>Microsoft　Edgeに関する動作 +>"Cookie とローカル ストレージ"、Microsoft Learn +https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update + +また、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されます。 + +### FireFox +FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。 +しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。 + +> FireFoxの挙動に関する確認資料 +> 徳丸浩、"2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか"、徳丸浩の日記 +https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html +>坂本、"CookieのSameSite属性と4つの勘違い(2022-10版)"、セキュアスカイプラス +https://securesky-plus.com/engineerblog/1809/ + +実際に2024年のバージョン(129.0.1)においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。 + +> 包括的Cookie保護に関する資料 +> "標準モードでの包括的 Cookie 保護の導入"、Support moz://a +> https://support.mozilla.org/ja/kb/introducing-total-cookie-protection-standard-mode + +包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要となります。また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。 + +> Chris Mills、Saying goodbye to third-party cookies in 2024 +> https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/ + +### Safari +SafariではSameSite属性はデフォルトの設定では「-」と表示され、Noneとなります。しかし、こちらもブラウザの機能によりCookieは送信されません。また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはブラウザの設定のプライバシーからWebサイトによるトラッキングを無効にする必要があります。この機能によりSafariではNoneを設定した場合にはCookieが送信されないようになっています。 + +> Safariの挙動に関する確認資料 +>John Wilander、"Full Third-Party Cookie Blocking and More"、WebKit +https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ + +### 各種ブラウザの挙動のまとめ +各種ブラウザのSameSite属性の挙動 + +| ブラウザ | デフォルト | デフォルトの挙動 | None時の挙動 | サードパーティCookieに関する扱い | 備考 | +| :------------- | :--------- | :----------------------------------------------------------- | :--------------------------------------------------- | :------------------------------- | :----------------------------------------------------------- | +| Google Chrome | Lax | LaxなのでCookieは送信されない(条件あり) | Secure属性付与時にCookieは送信される | Noneの場合、デフォルトは送信 | デフォルトの挙動だと2分間ルールが存在する。 | +| MicroSoft Edge | Lax | LaxなのでCookie送信されない(条件あり) | Secure属性付与時にCookieは送信される | Noneの場合、デフォルトは送信 | デフォルトの挙動だと2分間ルールが存在する。 | +| FireFox | None | NoneなのでCookieは送信されるが、ブラウザの機能により一部制限されている | ブラウザの機能によりCookieの送信は一部制限されている | Noneでもデフォルトは送信されない | 包括的Cookie保護により防御されているのでいくつかのケースではNoneであっても送信されない。 | +| Safari | None | Noneだが、ブラウザの機能によりCookieは送信されない | ブラウザの機能によりCookieは送信されない | Noneでもデフォルトは送信されない | Webサイトによるトラッキングを有効にしないと送信されない。 | + +## 診断観点 +現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの意向やユーザの設定変更により挙動が変化することになります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 + +1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか？ +2. GETリクエストを状態更新APIで利用していないか？ + +1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動が変わってきます。ユーザ側のブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定することが必要です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても排除できます。ただ、注意するべき事項としてSameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあります。具体的なケースはGMO Flatt Securityの@okazu_dm さんが記載しているブログが参照してみてください。本ブログで示されているようにHSTS(HTTP Strict Transport Security)を有効にして、HTTPSによる有効化により回避されないようにすることを提案しています。 + +> SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする +> https://blog.flatt.tech/entry/samesite_csrf_hsts + +2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。なので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 + + +## SameSite属性による各種挙動における攻撃事例を示したサイト +小山凌弥、CSRF、この罠いける？いけない？クイズ +https://www.mbsd.jp/research/20250414/csrf/ + +Bypassing SameSite cookie restrictions、PortSwigger +https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions + +## 対策 +デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策をしてください。 + +* SameSite属性を明示的にLaxやStrictにする +* データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する +* リクエストヘッダーを用いた確認を行う。(OriginヘッダーやFetch metadata) +* CSRFトークンを付与して、チェックする。 + +ヘッダーによる確認としては、OriginヘッダーやFetch metadataがある。Originヘッダーはどこからきたリクエストであるかを確認することができます。これによりリクエストサイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではよりリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。 + +Sec-Fetch-Sites +https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site + + +そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの設定に加えてoriginやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことはCSRFの対策となります。また、加えてHSTSヘッダーによりHTTPSを強制したり、トークンによる防御機構を合わせて持つとよりカバーされる領域が増えていきます。セキュリティではデフォルトの挙動にだけ依存せず、複数の防御機構を加えて対策を行うことが大切です。 + + +## 参考 + +* YAMAOKA Hiroyuki、CSRF対策のやり方、そろそろアップデートしませんか、https://speakerdeck.com/hiro_y/update-your-knowledge-of-csrf-protection?slide=37 +* 小林、Cookie の SameSite 属性について、https://blog.cybozu.io/entry/2020/05/07/080000 +* jxck、令和時代の API 実装のベースプラクティスと CSRF 対策、https://blog.jxck.io/entries/2024-04-26/csrf.html +* Anthony Chavez、Next steps for Privacy Sandbox and tracking protections in Chrome、https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings +* Chris Mills、Saying goodbye to third-party cookies in 2024、https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/ +* Strict-Transport-Security、https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security From c5d6a22f10cf98237c1bbdccd01b9bb07c38ceac Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 20 May 2025 15:50:19 +0900 Subject: [PATCH 02/10] =?UTF-8?q?=E6=96=87=E8=A8=80=E3=81=AE=E4=BF=AE?= =?UTF-8?q?=E6=AD=A3=E3=81=A8=E5=BD=A2=E5=BC=8F=E3=81=AE=E7=B5=B1=E4=B8=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 133 +++++++++++++++--------------------- 1 file changed, 56 insertions(+), 77 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 63b5c3e..bf04232 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -1,69 +1,34 @@ # CSRF ## 概要 -CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Cookieを配布したサイトとは異なるクロスサイトリクエストへのCookieの送信を制御する属性です。Strict/Lax/Noneの3つが存在し、設定された値により制御が異なります。基本的には、StrictやLaxが設定されている場合、CSRFに対する防御として機能します。しかし、注意するべき事項としてSameSite属性は、各ブラウザによりデフォルトの挙動が変わってきます。そのため、ここでは各ブラウザでの挙動の違いを整理していきます。 +CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Cookieを配布したサイトとは異なるクロスサイトリクエストへのCookieの送信を制御する属性です。Strict、Lax、Noneの3つが存在し、設定された値により制御が異なります。基本的には、StrictやLaxが設定されている場合、CSRFに対する防御として機能します。しかし、注意するべき点としてSameSite属性は、各ブラウザによりデフォルトの挙動が変わってきます。そのため、ここでは各ブラウザでの挙動の違いを整理していきます。 ## 影響 各種ブラウザの挙動におけるSameSite属性の挙動ついて整理していきます。 ### Google Chrome -Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。 -そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 +Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 ->Chromeに関する動作 ->"新しい SameSite=None; Secure Cookie 設定への対応準備"、Google検索セントラル ->https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja ->"SameSite Update"、The Chromium Projects ->https://www.chromium.org/updates/same-site/ - -この仕様は、2024年12月に確認したバージョン(131.0.6778.109)でも同様です。ただし、ChromeやEdgeにおいては、デフォルトの設定では注意が必要な点があります。それは、Cookieが生成されてから2分間はクロスサイトでCookieが送信される2分間ルールがあることです。2分間の間はクロスサイトでCookieを送信することができます。実際に下記のバージョンのブラウザで確認した所、現在も2分間ルールは顕在しているようです。 +この仕様は、2024年12月の確認バージョン（131.0.6778.109）でも同様でした。ただし、ChromeやEdgeにおいては、デフォルトの挙動で注意が必要な点があります。それは、Cookieが生成されてから2分間はクロスサイトでCookieが送信される2分間ルールが存在する点です。あります。実際に下記のバージョンのブラウザで確認した所、2分間ルールは顕在しているようです。 | ブラウザ | バージョン | 挙動 | | :------------- | :------------- | :----------------------------------------------------- | | Google Chrome | 131.0.6778.109 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | | MicroSoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | -また、Chromeでは下記のブログから2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。 +また、Chromeでは下記の記事によると2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。 -> Anthony Chavez、Next steps for Privacy Sandbox and tracking protections in Chrome、https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings +・[Next steps for Privacy Sandbox and tracking protections in Chrome](https://privacysandbox.com/news/privacy-sandbox-next-steps/) ### Microsoft Edge -ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。そのため、SameSite属性のデフォルトはLaxに変更されています。 -また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様です。 -これは2024年12月に確認したバージョン(1310.2903.112)でも確認されています。その他にもこちらでも2分間ルールが存在しています。 - ->Microsoft　Edgeに関する動作 ->"Cookie とローカル ストレージ"、Microsoft Learn -https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update - -また、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されます。 +ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様となります。これは2024年12月に確認したバージョン（1310.2903.112）でも同様の動作を確認しています。また、こちらでも2分間ルールが存在しています。そして、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されるようです。 ### FireFox -FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。 -しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。 - -> FireFoxの挙動に関する確認資料 -> 徳丸浩、"2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか"、徳丸浩の日記 -https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html ->坂本、"CookieのSameSite属性と4つの勘違い(2022-10版)"、セキュアスカイプラス -https://securesky-plus.com/engineerblog/1809/ - -実際に2024年のバージョン(129.0.1)においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。 - -> 包括的Cookie保護に関する資料 -> "標準モードでの包括的 Cookie 保護の導入"、Support moz://a -> https://support.mozilla.org/ja/kb/introducing-total-cookie-protection-standard-mode +FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。 包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要となります。また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。 -> Chris Mills、Saying goodbye to third-party cookies in 2024 -> https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/ - ### Safari SafariではSameSite属性はデフォルトの設定では「-」と表示され、Noneとなります。しかし、こちらもブラウザの機能によりCookieは送信されません。また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはブラウザの設定のプライバシーからWebサイトによるトラッキングを無効にする必要があります。この機能によりSafariではNoneを設定した場合にはCookieが送信されないようになっています。 -> Safariの挙動に関する確認資料 ->John Wilander、"Full Third-Party Cookie Blocking and More"、WebKit -https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ - ### 各種ブラウザの挙動のまとめ 各種ブラウザのSameSite属性の挙動 @@ -75,48 +40,62 @@ https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ | Safari | None | Noneだが、ブラウザの機能によりCookieは送信されない | ブラウザの機能によりCookieは送信されない | Noneでもデフォルトは送信されない | Webサイトによるトラッキングを有効にしないと送信されない。 | ## 診断観点 -現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの意向やユーザの設定変更により挙動が変化することになります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 +現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの意向やユーザの設定変更により動作が変わります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか？ -2. GETリクエストを状態更新APIで利用していないか？ +2. GETリクエストを状態更新に関わるAPIで利用していないか？ -1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動が変わってきます。ユーザ側のブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定することが必要です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても排除できます。ただ、注意するべき事項としてSameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあります。具体的なケースはGMO Flatt Securityの@okazu_dm さんが記載しているブログが参照してみてください。本ブログで示されているようにHSTS(HTTP Strict Transport Security)を有効にして、HTTPSによる有効化により回避されないようにすることを提案しています。 - -> SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする -> https://blog.flatt.tech/entry/samesite_csrf_hsts +1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動に依存します。ユーザのブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。このケースの具体的なケースや対策は参考文献9の記事で詳しく紹介されています。 2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。なので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 - -## SameSite属性による各種挙動における攻撃事例を示したサイト -小山凌弥、CSRF、この罠いける？いけない？クイズ -https://www.mbsd.jp/research/20250414/csrf/ - -Bypassing SameSite cookie restrictions、PortSwigger -https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions - ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策をしてください。 +デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応してください。 * SameSite属性を明示的にLaxやStrictにする * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する -* リクエストヘッダーを用いた確認を行う。(OriginヘッダーやFetch metadata) -* CSRFトークンを付与して、チェックする。 - -ヘッダーによる確認としては、OriginヘッダーやFetch metadataがある。Originヘッダーはどこからきたリクエストであるかを確認することができます。これによりリクエストサイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではよりリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。 - -Sec-Fetch-Sites -https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site - - -そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの設定に加えてoriginやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことはCSRFの対策となります。また、加えてHSTSヘッダーによりHTTPSを強制したり、トークンによる防御機構を合わせて持つとよりカバーされる領域が増えていきます。セキュリティではデフォルトの挙動にだけ依存せず、複数の防御機構を加えて対策を行うことが大切です。 - - -## 参考 - -* YAMAOKA Hiroyuki、CSRF対策のやり方、そろそろアップデートしませんか、https://speakerdeck.com/hiro_y/update-your-knowledge-of-csrf-protection?slide=37 -* 小林、Cookie の SameSite 属性について、https://blog.cybozu.io/entry/2020/05/07/080000 -* jxck、令和時代の API 実装のベースプラクティスと CSRF 対策、https://blog.jxck.io/entries/2024-04-26/csrf.html -* Anthony Chavez、Next steps for Privacy Sandbox and tracking protections in Chrome、https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings -* Chris Mills、Saying goodbye to third-party cookies in 2024、https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/ -* Strict-Transport-Security、https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security +* リクエストヘッダーを用いた確認を行う（OriginヘッダーやFetch metadataに関するヘッダー） +* CSRFトークンを付与して、チェックする + +ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 + +## 参考文献 + +1. [新しい SameSite=None; Secure Cookie 設定への対応準備](https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja) + +2. [SameSite Update]( + https://www.chromium.org/updates/same-site/) +3. [Cookie とローカル ストレージ]( + https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update) +4. ["2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか"]( + https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html) +5. [CookieのSameSite属性と4つの勘違い(2022-10版)]( + https://securesky-plus.com/engineerblog/1809/) +6. [標準モードでの包括的 Cookie 保護の導入]( + https://support.mozilla.org/ja/kb/introducing-total-cookie-protection-standard-mode) +7. [Saying goodbye to third-party cookies in 2024]( + https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/) +8. [Full Third-Party Cookie Blocking and More](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) +9. [SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする](https://blog.flatt.tech/entry/samesite_csrf_hsts) + +10. [CSRF対策のやり方、そろそろアップデートしませんか]( + https://speakerdeck.com/hiro_y/update-your-knowledge-of-csrf-protection?slide=37) +11. [Cookie の SameSite 属性について]( + https://blog.cybozu.io/entry/2020/05/07/080000) + +12. [令和時代の API 実装のベースプラクティスと CSRF 対策]( + https://blog.jxck.io/entries/2024-04-26/csrf.html) + +13. [Next steps for Privacy Sandbox and tracking protections in Chrome]( + https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings) + +14. [Saying goodbye to third-party cookies in 2024]( + https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/) + +15. [Strict-Transport-Security]( + https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) +16. [CSRF、この罠いける？いけない？クイズ](https://www.mbsd.jp/research/20250414/csrf/) + +17. [Bypassing SameSite cookie restrictions]( + https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) +18. [Sec-Fetch-Sites](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site) From c422244961c4cd89e423db0a04bede20e27e971f Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 20 May 2025 15:51:46 +0900 Subject: [PATCH 03/10] =?UTF-8?q?=E5=BD=A2=E5=BC=8F=E3=81=AE=E7=B5=B1?= =?UTF-8?q?=E4=B8=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index bf04232..06b5db2 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -67,7 +67,7 @@ SafariではSameSite属性はデフォルトの設定では「-」と表示さ https://www.chromium.org/updates/same-site/) 3. [Cookie とローカル ストレージ]( https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update) -4. ["2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか"]( +4. [2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか]( https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html) 5. [CookieのSameSite属性と4つの勘違い(2022-10版)]( https://securesky-plus.com/engineerblog/1809/) From de793d07b06756341e9531d2d1267429b3c7b5e7 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 20 May 2025 16:20:27 +0900 Subject: [PATCH 04/10] =?UTF-8?q?=E6=96=87=E7=8C=AE=E3=81=AE=E6=95=B4?= =?UTF-8?q?=E7=90=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 69 ++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 40 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 06b5db2..11f8789 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -5,7 +5,7 @@ CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Co ## 影響 各種ブラウザの挙動におけるSameSite属性の挙動ついて整理していきます。 ### Google Chrome -Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 +Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。（※1）そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 この仕様は、2024年12月の確認バージョン（131.0.6778.109）でも同様でした。ただし、ChromeやEdgeにおいては、デフォルトの挙動で注意が必要な点があります。それは、Cookieが生成されてから2分間はクロスサイトでCookieが送信される2分間ルールが存在する点です。あります。実際に下記のバージョンのブラウザで確認した所、2分間ルールは顕在しているようです。 @@ -14,20 +14,18 @@ Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォル | Google Chrome | 131.0.6778.109 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | | MicroSoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | -また、Chromeでは下記の記事によると2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。 - -・[Next steps for Privacy Sandbox and tracking protections in Chrome](https://privacysandbox.com/news/privacy-sandbox-next-steps/) +また、Chromeでは2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。（※3） ### Microsoft Edge -ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様となります。これは2024年12月に確認したバージョン（1310.2903.112）でも同様の動作を確認しています。また、こちらでも2分間ルールが存在しています。そして、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されるようです。 +ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。（※4）そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様となります。これは2024年12月に確認したバージョン（1310.2903.112）でも同様の動作を確認しています。また、こちらでも2分間ルールが存在しています。そして、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されるようです。 ### FireFox -FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。 +FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6）実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） -包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要となります。また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。 +包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要となります。また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8） ### Safari -SafariではSameSite属性はデフォルトの設定では「-」と表示され、Noneとなります。しかし、こちらもブラウザの機能によりCookieは送信されません。また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはブラウザの設定のプライバシーからWebサイトによるトラッキングを無効にする必要があります。この機能によりSafariではNoneを設定した場合にはCookieが送信されないようになっています。 +SafariではSameSite属性はデフォルトの設定では「-」と表示され、Noneとなります。しかし、こちらもブラウザの機能によりCookieは送信されません。また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはブラウザの設定のプライバシーからWebサイトによるトラッキングを無効にする必要があります。この機能によりSafariではNoneを設定した場合にはCookieが送信されないようになっています。（※9） ### 各種ブラウザの挙動のまとめ 各種ブラウザのSameSite属性の挙動 @@ -45,19 +43,19 @@ SafariではSameSite属性はデフォルトの設定では「-」と表示さ 1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか？ 2. GETリクエストを状態更新に関わるAPIで利用していないか？ -1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動に依存します。ユーザのブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。このケースの具体的なケースや対策は参考文献9の記事で詳しく紹介されています。 +1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動に依存します。ユーザのブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。（※13） 2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。なので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応してください。 +デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 -* SameSite属性を明示的にLaxやStrictにする +* SameSite属性に明示的にLaxやStrictを設定する * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する -* リクエストヘッダーを用いた確認を行う（OriginヘッダーやFetch metadataに関するヘッダー） -* CSRFトークンを付与して、チェックする +* リクエストヘッダーを用いて確認を行う（OriginヘッダーやFetch metadataを用いた確認） +* 従来通りCSRFトークンを付与して、チェックする -ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 +ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。（※14）そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 ## 参考文献 @@ -65,37 +63,28 @@ SafariではSameSite属性はデフォルトの設定では「-」と表示さ 2. [SameSite Update]( https://www.chromium.org/updates/same-site/) -3. [Cookie とローカル ストレージ]( +3. [Next steps for Privacy Sandbox and tracking protections in Chrome](https://privacysandbox.com/news/privacy-sandbox-next-steps/) +4. [Cookie とローカル ストレージ]( https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update) -4. [2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか]( +5. [2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか]( https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html) -5. [CookieのSameSite属性と4つの勘違い(2022-10版)]( +6. [CookieのSameSite属性と4つの勘違い(2022-10版)]( https://securesky-plus.com/engineerblog/1809/) -6. [標準モードでの包括的 Cookie 保護の導入]( +7. [標準モードでの包括的 Cookie 保護の導入]( https://support.mozilla.org/ja/kb/introducing-total-cookie-protection-standard-mode) -7. [Saying goodbye to third-party cookies in 2024]( +8. [Saying goodbye to third-party cookies in 2024]( https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/) -8. [Full Third-Party Cookie Blocking and More](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) -9. [SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする](https://blog.flatt.tech/entry/samesite_csrf_hsts) - -10. [CSRF対策のやり方、そろそろアップデートしませんか]( - https://speakerdeck.com/hiro_y/update-your-knowledge-of-csrf-protection?slide=37) -11. [Cookie の SameSite 属性について]( +9. [Full Third-Party Cookie Blocking and More](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) +10. [Cookie の SameSite 属性について]( https://blog.cybozu.io/entry/2020/05/07/080000) - -12. [令和時代の API 実装のベースプラクティスと CSRF 対策]( - https://blog.jxck.io/entries/2024-04-26/csrf.html) - -13. [Next steps for Privacy Sandbox and tracking protections in Chrome]( - https://privacysandbox.com/news/privacy-sandbox-next-steps/#:~:text=emerged%2C%20and%20the%20regulatory%20landscape,Chrome%E2%80%99s%20Privacy%20and%20Security%20Settings) - -14. [Saying goodbye to third-party cookies in 2024]( +11. [Bypassing SameSite cookie restrictions]( + https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) +12. [Saying goodbye to third-party cookies in 2024]( https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/) - -15. [Strict-Transport-Security]( - https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) +13. [SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする](https://blog.flatt.tech/entry/samesite_csrf_hsts) +14. [Sec-Fetch-Sites](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site) +15. [CSRF対策のやり方、そろそろアップデートしませんか]( + https://speakerdeck.com/hiro_y/update-your-knowledge-of-csrf-protection) 16. [CSRF、この罠いける？いけない？クイズ](https://www.mbsd.jp/research/20250414/csrf/) - -17. [Bypassing SameSite cookie restrictions]( - https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) -18. [Sec-Fetch-Sites](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site) +17. [令和時代の API 実装のベースプラクティスと CSRF 対策]( + https://blog.jxck.io/entries/2024-04-26/csrf.html) From 4042e52f0fee629037202699db735c973dc4fa31 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 11:29:30 +0900 Subject: [PATCH 05/10] =?UTF-8?q?=E3=83=AC=E3=83=93=E3=83=A5=E3=83=BC?= =?UTF-8?q?=E5=BE=8C=E4=BF=AE=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 66 ++++++++++++++++++++++++------------- 1 file changed, 43 insertions(+), 23 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 11f8789..55b4620 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -1,61 +1,81 @@ +``` +title: CSRF +weight: 999 +``` + # CSRF + ## 概要 -CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Cookieを配布したサイトとは異なるクロスサイトリクエストへのCookieの送信を制御する属性です。Strict、Lax、Noneの3つが存在し、設定された値により制御が異なります。基本的には、StrictやLaxが設定されている場合、CSRFに対する防御として機能します。しかし、注意するべき点としてSameSite属性は、各ブラウザによりデフォルトの挙動が変わってきます。そのため、ここでは各ブラウザでの挙動の違いを整理していきます。 +CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Cookieを配布したサイトとは異なるクロスサイトリクエストへのCookieの送信を制御する属性です。Strict、Lax、Noneの3つが存在し、設定された値により制御が異なります。基本的には、StrictやLaxが設定されている場合、CSRFに対する防御として機能します。しかし、注意するべき点としてSameSite属性は、各ブラウザによりデフォルトの挙動が変わってきます。そのため、ここでは各ブラウザにおけるSameSite属性の挙動について整理していきます。 -## 影響 -各種ブラウザの挙動におけるSameSite属性の挙動ついて整理していきます。 +## SameSite属性の挙動比較 ### Google Chrome -Google Chromeでは2020年2月にChrome80以降でSameSite属性はデフォルトでLaxに変更されています。（※1）そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。 +Google Chromeでは2020年2月にGoogle Chrome80以降でSameSite属性はデフォルトでLaxに変更されています。（※1）そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。この仕様は、2024年12月バージョン（131.0.6778.109）でも同様の挙動であることを確認しています。 + +また、Google Chromeでは2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようです。（※3） + +### Microsoft Edge +Google ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。（※4）そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様です。これは2024年12月のバージョン（1310.2903.112）でも同様の挙動であることを確認しています。 + +また、Microsoft EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されるようです。 -この仕様は、2024年12月の確認バージョン（131.0.6778.109）でも同様でした。ただし、ChromeやEdgeにおいては、デフォルトの挙動で注意が必要な点があります。それは、Cookieが生成されてから2分間はクロスサイトでCookieが送信される2分間ルールが存在する点です。あります。実際に下記のバージョンのブラウザで確認した所、2分間ルールは顕在しているようです。 +### [コラム]Google ChromeとMicrosoft Edgeで発生する2分間ルールについて + +Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限り、発行から2分間はクロスサイトリクエストでもCookieが送信される挙動が存在します。この挙動は、2分間ルールと呼ばれます。実際に下記のブラウザのバージョンで確認した所、2分間ルールは現在も発生することが確認できました。 | ブラウザ | バージョン | 挙動 | | :------------- | :------------- | :----------------------------------------------------- | | Google Chrome | 131.0.6778.109 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | -| MicroSoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | - -また、Chromeでは2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようになっているようです。（※3） +| Microsoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | -### Microsoft Edge -ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。（※4）そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様となります。これは2024年12月に確認したバージョン（1310.2903.112）でも同様の動作を確認しています。また、こちらでも2分間ルールが存在しています。そして、EdgeでもGoogle Chromeと同様にサードパーティCookieはNoneが設定されている場合は、送信されるようです。 +### Firefox +Firefoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、Firefox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6）実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieが送信される可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） -### FireFox -FireFoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、FireFox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6）実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されています。そのため、デフォルトだとCookieを送信してしまいます。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） +包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要です。 -包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要となります。また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8） +また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8） ### Safari -SafariではSameSite属性はデフォルトの設定では「-」と表示され、Noneとなります。しかし、こちらもブラウザの機能によりCookieは送信されません。また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはブラウザの設定のプライバシーからWebサイトによるトラッキングを無効にする必要があります。この機能によりSafariではNoneを設定した場合にはCookieが送信されないようになっています。（※9） +SafariではSameSite属性はデフォルトの設定ではNone相当で扱われます。そのため、Firefoxと同様にブラウザの機能によりCookieは送信されません。ただし、Safariの開発者ツール上では「None」ではなく、「-」と表示されます。 -### 各種ブラウザの挙動のまとめ -各種ブラウザのSameSite属性の挙動 +また、Safariでは全面的にクロスサイトでのサードパーティCookieをブロックしています。本機能をITP（Intelligent Tracking Prevention）と言います。サードパーティCookieを受け取るようにするにはSafariのプライバシー設定でWebサイトによるトラッキングを無効にする必要があります。この機能により、SameSite属性が未設定、またはNoneを設定した場合にはCookieが送信されないようになっています。（※9） + +### 各ブラウザにおける挙動のまとめ +各ブラウザにおけるSameSite属性やサードパーティCookieの扱いに関しては下記の表のようになります。 | ブラウザ | デフォルト | デフォルトの挙動 | None時の挙動 | サードパーティCookieに関する扱い | 備考 | | :------------- | :--------- | :----------------------------------------------------------- | :--------------------------------------------------- | :------------------------------- | :----------------------------------------------------------- | | Google Chrome | Lax | LaxなのでCookieは送信されない(条件あり) | Secure属性付与時にCookieは送信される | Noneの場合、デフォルトは送信 | デフォルトの挙動だと2分間ルールが存在する。 | -| MicroSoft Edge | Lax | LaxなのでCookie送信されない(条件あり) | Secure属性付与時にCookieは送信される | Noneの場合、デフォルトは送信 | デフォルトの挙動だと2分間ルールが存在する。 | -| FireFox | None | NoneなのでCookieは送信されるが、ブラウザの機能により一部制限されている | ブラウザの機能によりCookieの送信は一部制限されている | Noneでもデフォルトは送信されない | 包括的Cookie保護により防御されているのでいくつかのケースではNoneであっても送信されない。 | +| Microsoft Edge | Lax | LaxなのでCookie送信されない(条件あり) | Secure属性付与時にCookieは送信される | Noneの場合、デフォルトは送信 | デフォルトの挙動だと2分間ルールが存在する。 | +| Firefox | None | NoneなのでCookieは送信されるが、ブラウザの機能により一部制限されている | ブラウザの機能によりCookieの送信は一部制限されている | Noneでもデフォルトは送信されない | 包括的Cookie保護により防御されているのでいくつかのケースではNoneであっても送信されない。 | | Safari | None | Noneだが、ブラウザの機能によりCookieは送信されない | ブラウザの機能によりCookieは送信されない | Noneでもデフォルトは送信されない | Webサイトによるトラッキングを有効にしないと送信されない。 | ## 診断観点 -現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの意向やユーザの設定変更により動作が変わります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 +現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの仕様変更やユーザの設定により動作が変わります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか？ 2. GETリクエストを状態更新に関わるAPIで利用していないか？ -1は、SameSite属性を指定しない場合、ユーザが利用するブラウザによりデフォルトの挙動に依存します。ユーザのブラウザの種類やバージョンや設定をコンテンツ提供者側が制御することはできません。そのため、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、ChromeやEdgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieを送信してしまいます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。（※13） +1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御することができないためです。その結果、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、Google ChromeやMicrosoft Edgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieが送信されます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。（※13） 2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。なので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはあるが明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 +デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 * SameSite属性に明示的にLaxやStrictを設定する * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する * リクエストヘッダーを用いて確認を行う（OriginヘッダーやFetch metadataを用いた確認） * 従来通りCSRFトークンを付与して、チェックする -ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataではSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Destの4つが存在しますが、CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。（※14）そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。なので、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 +ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataでは下記の4つがあります。 + +* Sec-Fetch-Site +* Sec-Fetch-Mode +* Sec-Fetch-User +* Sec-Fetch-Dest + +CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。（※14）そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。そのため、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 ## 参考文献 @@ -63,7 +83,7 @@ SafariではSameSite属性はデフォルトの設定では「-」と表示さ 2. [SameSite Update]( https://www.chromium.org/updates/same-site/) -3. [Next steps for Privacy Sandbox and tracking protections in Chrome](https://privacysandbox.com/news/privacy-sandbox-next-steps/) +3. [Next steps for Privacy Sandbox and tracking protections in Google Chrome](https://privacysandbox.com/news/privacy-sandbox-next-steps/) 4. [Cookie とローカル ストレージ]( https://learn.microsoft.com/ja-jp/microsoftteams/platform/resources/samesite-cookie-update) 5. [2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか]( From 83178ba1d94eca315e6e905062e1b2efd1665020 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 11:34:36 +0900 Subject: [PATCH 06/10] =?UTF-8?q?=E3=83=98=E3=83=83=E3=83=80=E3=83=BC?= =?UTF-8?q?=E3=82=92=E8=BF=BD=E8=A8=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 55b4620..89254d2 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -1,8 +1,8 @@ -``` +--- title: CSRF weight: 999 -``` +--- # CSRF ## 概要 From c70f26ad5565a0da78bdf259f27501f9e8af75bc Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 12:04:59 +0900 Subject: [PATCH 07/10] =?UTF-8?q?lint=E3=82=92=E4=BF=AE=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 89254d2..e57b18b 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -12,7 +12,7 @@ CSRFの対策の1つにSameSite属性が存在します。SameSite属性は、Co ### Google Chrome Google Chromeでは2020年2月にGoogle Chrome80以降でSameSite属性はデフォルトでLaxに変更されています。（※1）そのため、デフォルトではクロスサイトに対してCookieは送信されません。また、Noneの場合でもSecure属性が明示的に設定されていない場合は送信されないようになっています。この仕様は、2024年12月バージョン（131.0.6778.109）でも同様の挙動であることを確認しています。 -また、Google Chromeでは2025年現在では、SameSite属性がNoneの場合、サードパーティCookieは送信されるようです。（※3） +また、2025年現在Google ChromeではSameSite属性がNoneの場合、サードパーティCookieは送信されるようです。（※3） ### Microsoft Edge Google ChromeベースであるMicrosoft Edgeに関してもビルド17672以降のWindows 10で導入されたバージョンはGoogle Chromeと同様の挙動に変更されています。（※4）そのため、SameSite属性のデフォルトはLaxに変更されています。また、NoneかつSecure属性が付与されていないとCookieが送信されない挙動もGoogle Chromeと同様です。これは2024年12月のバージョン（1310.2903.112）でも同様の挙動であることを確認しています。 @@ -21,7 +21,7 @@ Google ChromeベースであるMicrosoft Edgeに関してもビルド17672以降 ### [コラム]Google ChromeとMicrosoft Edgeで発生する2分間ルールについて -Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限り、発行から2分間はクロスサイトリクエストでもCookieが送信される挙動が存在します。この挙動は、2分間ルールと呼ばれます。実際に下記のブラウザのバージョンで確認した所、2分間ルールは現在も発生することが確認できました。 +Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限り、発行から2分間はクロスサイトリクエストでもCookieを送信する挙動が存在します。この挙動は、2分間ルールと呼ばれます。実際に下記のブラウザのバージョンで確認した所、2分間ルールは現在も発生することが確認できました。 | ブラウザ | バージョン | 挙動 | | :------------- | :------------- | :----------------------------------------------------- | @@ -29,9 +29,11 @@ Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限 | Microsoft Edge | 1310.2903.112 | 2分間は送信可能、2分間を超えるとCookieは付与されない。 | ### Firefox -Firefoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、Firefox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6）実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieが送信される可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） +Firefoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、Firefox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6） -包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、ユーザ操作が入るようなformによる操作などの場合はCookieは送信されてしまうので注意が必要です。 +実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieが送信される可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） + +包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、formによる操作などユーザによる操作が発生する場合は、Cookieが送信されてしまうので注意してください。 また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8） @@ -51,31 +53,31 @@ SafariではSameSite属性はデフォルトの設定ではNone相当で扱わ | Safari | None | Noneだが、ブラウザの機能によりCookieは送信されない | ブラウザの機能によりCookieは送信されない | Noneでもデフォルトは送信されない | Webサイトによるトラッキングを有効にしないと送信されない。 | ## 診断観点 -現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られているケースがあることがわかりました。しかし、SameSite属性はブラウザの仕様変更やユーザの設定により動作が変わります。そのため、SameSite属性による設定を事前に開発側が行なっておく必要があります。具体的には下記の観点で確認が必要です。 +現在のブラウザではSameSite属性がLaxに設定されていたり、Noneになっていてもブラウザの別の機能によりある程度は守られることがわかりました。しかし、SameSite属性はブラウザの仕様変更やユーザの設定により動作が変わります。そのため、SameSite属性による設定を事前に開発側が行っておく必要があります。具体的には下記の観点で確認が必要です。 -1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか？ -2. GETリクエストを状態更新に関わるAPIで利用していないか？ +1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか +2. GETリクエストを状態更新に関わるAPIで利用していないか -1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御することができないためです。その結果、状況によってはCSRFが発生してしまう可能性があります。なので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。また、Google ChromeやMicrosoft Edgeのデフォルトの設定ではCookieが発行されて2分間はトップレベルのリクエストであればCookieが送信されます。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようです。（※13） +1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御できないためです。その結果、状況によってはCSRFが発生してしまう可能性があります。ですので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。特にGoogle ChromeやMicrosoft Edgeでは、明示的にSameSite属性を指定しないと発行されてから2分間はCookieが送信されるため注意が必要です。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようため注意してください。（※13） -2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。なので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 +2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。ですので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行なっていく必要があるように思います。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 +デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行なっていく必要があります。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 * SameSite属性に明示的にLaxやStrictを設定する * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する -* リクエストヘッダーを用いて確認を行う（OriginヘッダーやFetch metadataを用いた確認） +* リクエストヘッダを用いて確認する（OriginヘッダやFetch metadataを用いた確認） * 従来通りCSRFトークンを付与して、チェックする -ヘッダーによる確認としては、OriginヘッダーやFetch metadataがあります。Originヘッダーを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataでは下記の4つがあります。 +ヘッダによる確認としては、OriginヘッダやFetch metadataがあります。Originヘッダを用いることでどこから送信されたリクエストであるかを確認できます。これによりリクエストの送信元サイトが同一サイトからのリクエストであるかを確認する手段として用いることができます。また、最近ではさらに詳細なリクエスト元の情報を追加できるFetch metadataが存在しています。Fetch metadataでは下記の4つがあります。 * Sec-Fetch-Site * Sec-Fetch-Mode * Sec-Fetch-User * Sec-Fetch-Dest -CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。（※14）そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。そのため、SameSiteの明示的な設定に加えてOriginヘッダーやSec-Fetch-Siteヘッダーに対するチェックを合わせて行うことでCSRFの対策となります。 +CSRFの対策として利用できるのはSec-Fetch-Siteです。Sec-Fetch-Siteでは、送信元と送信先で同一オリジンなのかクロスサイトなのかについてブラウザ側が設定してくれます。（※14）そのため、Sec-Fetch-Siteの値がsame-siteもしくはsame-originであるかをチェックすることで正規のサイトからのリクエストであるかを確認できます。そのため、SameSiteの明示的な設定に加えてOriginヘッダやSec-Fetch-Siteヘッダに対するチェックを合わせて行うことでCSRFの対策となります。 ## 参考文献 From fda7056a5d304912e53191ad5126a4fb61025923 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 12:08:59 +0900 Subject: [PATCH 08/10] =?UTF-8?q?lint=E3=82=92=E8=BF=BD=E5=8A=A0=E3=81=A7?= =?UTF-8?q?=E4=BF=AE=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index e57b18b..7561b39 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -31,9 +31,9 @@ Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限 ### Firefox Firefoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、Firefox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6） -実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieが送信される可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） +実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieを送信する可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） -包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御を行っています。ただし、formによる操作などユーザによる操作が発生する場合は、Cookieが送信されてしまうので注意してください。 +包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御しています。ただし、formによる操作などユーザによる操作が発生する場合は、Cookieが送信されてしまうので注意してください。 また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8） @@ -58,12 +58,12 @@ SafariではSameSite属性はデフォルトの設定ではNone相当で扱わ 1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか 2. GETリクエストを状態更新に関わるAPIで利用していないか -1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御できないためです。その結果、状況によってはCSRFが発生してしまう可能性があります。ですので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。特にGoogle ChromeやMicrosoft Edgeでは、明示的にSameSite属性を指定しないと発行されてから2分間はCookieが送信されるため注意が必要です。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようため注意してください。（※13） +1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御できないためです。その結果、状況によってはCSRFが発生してしまいます。ですので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。特にGoogle ChromeやMicrosoft Edgeでは、明示的にSameSite属性を指定しないと発行されてから2分間はCookieが送信されるため注意が必要です。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようため注意してください。（※13） 2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。ですので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行なっていく必要があります。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 +デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行っていく必要があります。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 * SameSite属性に明示的にLaxやStrictを設定する * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する From 32218833d58ab3f771d47e4a25b6783e320cea94 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 12:28:04 +0900 Subject: [PATCH 09/10] =?UTF-8?q?lint=E3=82=92=E8=BF=BD=E5=8A=A0=E3=81=A7?= =?UTF-8?q?=E4=BF=AE=E6=AD=A3=EF=BC=88=E7=B6=9A=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 7561b39..5153e70 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -58,12 +58,12 @@ SafariではSameSite属性はデフォルトの設定ではNone相当で扱わ 1. 明示的にSameSite属性を指定しており、LaxやStrictを付与しているか 2. GETリクエストを状態更新に関わるAPIで利用していないか -1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御できないためです。その結果、状況によってはCSRFが発生してしまいます。ですので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。特にGoogle ChromeやMicrosoft Edgeでは、明示的にSameSite属性を指定しないと発行されてから2分間はCookieが送信されるため注意が必要です。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようため注意してください。（※13） +1を確認する理由は、SameSite属性を指定しない場合、その挙動は利用者のブラウザの種類やバージョン、設定に依存し、コンテンツ提供側で制御できないためです。その結果、状況によってはCSRFが発生してしまいます。ですので、明示的にSameSite属性でLaxやStrictを設定されているかを確認するのが大切です。特にGoogle ChromeやMicrosoft Edgeでは、明示的にSameSite属性を指定しないと発行されてから2分間はCookieが送信される点に注意してください。2分間という制約があり現実での悪用は難しいですが、この懸念についても明示的に設定することで排除できます。また、SameSite属性が有効な場合でもサブドメインに脆弱性があるケースや中間者攻撃ができる場合には回避されるケースがあるようため注意してください。（※13） 2は、SameSite属性でLaxを利用している場合に問題となり得ます。LaxではGETリクエストかつトップレベルナビゲーションのリクエストの際にはCookieを送信します。そのため、GETによりデータを更新するような実装がされている場合には、CSRFが発生します。ですので、GETリクエストを利用して状態更新をするようなAPIが実装されていないかについて確認する必要があります。 ## 対策 -デフォルトのブラウザの挙動によりCSRFから守られるケースはありますが、明示的に対策を行っていく必要があります。具体的には下記のような対策を組み合わせて対応する必要がありそうです。 +ブラウザのデフォルトの機能によりCSRFから守られるケースはありますが、利用しているブラウザやユーザの設定状況によっては被害が発生する可能性もあります。そのため、アプリケーション側で対策をしておくことが大切です。具体的には下記のような対策を組み合わせて対応する必要があります。 * SameSite属性に明示的にLaxやStrictを設定する * データの変更に関わるリクエスト操作ではGETを使わずPOSTを利用する From d277ae61ec31a17dc5cafaae070f0dc999565197 Mon Sep 17 00:00:00 2001 From: KotatuBot Date: Tue, 22 Jul 2025 12:39:51 +0900 Subject: [PATCH 10/10] =?UTF-8?q?=E8=A1=8C=E9=96=93=E3=81=AE=E4=BF=AE?= =?UTF-8?q?=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/csrf/_index.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/docs/csrf/_index.md b/content/docs/csrf/_index.md index 5153e70..f3df816 100644 --- a/content/docs/csrf/_index.md +++ b/content/docs/csrf/_index.md @@ -31,9 +31,7 @@ Google ChromeとMicrosoft Edgeには、SameSite属性が未指定の場合に限 ### Firefox Firefoxは2022年1月11日にGoogle Chromeと同様にSameSite属性のデフォルトの挙動をLaxに変更しました。しかし、Firefox 96.0.3以降においてSameSite属性のデフォルトの挙動は従来の仕様であるNoneに戻されたようです。（※5、※6） -実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieを送信する可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7） - -包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御しています。ただし、formによる操作などユーザによる操作が発生する場合は、Cookieが送信されてしまうので注意してください。 +実際に2024年のバージョン（129.0.1）においてもSameSite属性を指定しない場合にはNoneが設定されており、クロスサイトリクエストでもCookieを送信する可能性があります。しかし、いくつかのケースではCookieは保護されており実際に影響のあるものは送信されないようになっています。これは、Firefoxで包括的Cookie保護によるブラウザ機能がデフォルトで有効になっているためです。（※7）包括的Cookie保護では、各サイトごとに個別に管理するCookieを分離することで防御しています。ただし、formによる操作などユーザによる操作が発生する場合は、Cookieが送信されてしまうので注意してください。 また、Firefoxではブラウザのデフォルトの設定によりSameSite属性がNoneでもサードパーティCookieは送信されません。（※8）