3PCA 31 日目: 3rd Party Cookie 廃止の廃止 | blog.jxck.io
Intro このエントリは、2023 年の 3rd Party Cookie Advent Calendar の 31 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie このエントリもいよいよ終わりに近づいてきたようだ。 振り返り ここまでの Chrome の動きを振り返る。 2020/01: 3rd Party Cookie を 2022 年には廃止する計画を発表 https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html 2021/06: 2023 年後半に延期 https://blog.google/pro
クッキーとセッションを雰囲気で使っているエンジニアが、違いを説明できるようになる記事
どうもお疲れ様です。MESIです。 Web系のエンジニアをやっていると普段からクッキーやらセッションやらを使うことになると思います。 皆さんの職場でも、こんな言葉を耳にするのではないでしょうか。 「クッキーに保存しよう」 「クッキー削除しよう」 「セッションに保存しよう」 「セッションが切れた」 そこで私のようなよわよわエンジニアはこう思うのです。 「クッキーとセッションの違い is 何？」 今回はそんな私のようなエンジニア向きにクッキーとセッションを説明していきます。 そもそもなぜクッキーやらセッションが必要なのか そもそもなぜクッキーやセッションは必要なのでしょうか。 それはHTTPはステートレスなプロトコルだからです。 ステートレスって？ ステートレスは、その名の通り「状態を保持しない」ことを指します。 HTTPはサーバーがクライアントの状態を覚えず、毎回新たなリクエストとして処理さ
ChromeアドオンGet cookies.txtが外部にCookieを送信している - Qiita
Get cookies.txtというChromeアドオンがあります。 名前のとおりCookieをテキストに出力してくれる便利な拡張機能であり、Googleおすすめマークも付いています。 さて、この拡張機能に問題が見つかりました。 ⚠️⚠️【注意喚起】⚠️⚠️ 今 Chrome に Get cookies.txt という拡張機能を入れている方、”””今すぐ”””アンインストールしてください！！ ページ遷移すると Cookie からアクセスした URL から何からすべて外部サーバーに送られる凶悪スパイウェアになってます 怖過ぎる…😇😱 🔽https://t.co/BjqyruuU3u pic.twitter.com/rVZJpGKwhc — Torishima (@izutorishima) February 28, 2023 結論から言うと、この変更は作者が意図して行ったものであり、ス
TokenでもCookieでもBearer vs Sender-Constrained の概念を覚えよう｜ritou
こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife Bearer Token : 第1回で説明した地下鉄の切符のようなトークン。所持していれば使えるので、他の人が拾っても使えます。 Sender Constrained Token : 利用者を制限するトークン。飛行機の搭乗券のように、利用者が指定されている、制限されているもの。 概念はこんな感じですが、実装方法は色々なものが
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - GMO Flatt Security Blog
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
Cookie vs Local Storage マルウェア耐性等に差はあるか？Google Chromeによる保存時の暗号化を検証する - Flatt Security Blog
はじめに こんにちは。セキュリティエンジニアの@okazu_dmです。 皆さんはブラウザにおいてLocal StorageやCookieに格納されている値が暗号化されているかどうかを考えたことはあるでしょうか。これらWebサービスの認証・認可において使われるデータが、XSSのようなアプリケーションの脆弱性への耐性に差があるかどうかは頻繁に議論されるところです。 しかし、ブラウザに保存されたデータが暗号化されているかどうかはまた別の攻撃経路への耐性の話であり、馴染みがないのではないでしょうか。 これは、基礎知識としてLocal StorageとCookieの仕組み/挙動の紹介と比較をしつつ、Google Chromeにおけるそれらの暗号化の実装上の違いを検証する記事です。 なお、保存先のストレージとAuth0のアクセストークンのXSS耐性との関連は過去に別の記事で検証しています。興味がある方
なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
Cookieの新しい属性、SameParty属性について - ASnoKaze blog
ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る 現
【現在は対応不要】Chrome80以降でALBの認証を使っているとcookieが4096バイトを超えて認証できないことがあり、社内サービスではcookie名を縮めて対応した - hitode909の日記
2020/2/18追記 サポートに問い合わせたところ、ALBの不具合はロールバック済みで、cookie名を縮める対応は不要、とのことでした。試してみたところ、たしかにcookie名の指定をやめても問題なく認証できました。 AWSのApplication Load Balancerの認証機能を使って、スタッフからのアクセスのみ許可する社内向けウェブサービスを運用しているのだけど、昨日くらいからGoogle Chromeで認証が通らなないという声を聞くようになった。 現象としてはリダイレクトループが発生していて、コンソールを見るとSet-Cookie headerが長すぎるというエラーが出ていた。 Set-Cookie header is ignored in response from url: https://****/oauth2/idpresponse?code=e51b4cf0-8b
Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita
図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないためにおこる脆弱です。 たとえば会員の退会ページを https://example.com/mypage/delete/で用意し、 ボタン操作でsubmit=1が送信されて退会処理が実行される仕様の場合、 パラメータが誰でもわかるので、外部に用意された悪意のあるフォ
ITP2.1の影響と対策方法のまとめ、JavaScript生成cookie7日間問題 | marketechlabo
ITPの仕様 次々と新しいバージョンがリリースされるITP。微妙にアップデートされ、仕様がわかりにくくなっているので現時点で最新のものを解説する。 ITPの目的と概要 われわれウェブサイト運用者は cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、 それらのデータを必要に応じてツール間で連携する ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、 この3つのケースにおいて cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる） リファラが使い物にならなくなる 可能性があるということである。その結果 コンバージョントラッキングができない リマーケティング広告が配信で
Chromeにおいて非セキュアなHTTPで送信されたCookieの有効期限を短くする議論 - ASnoKaze blog
暗号化してないHTTPで送信されたCookieの有効期限を短くしたいという議論は、Mozillaでも以前から行われてきました。「Intent to ship: Treat cookies set over non-secure HTTP as session cookies」。 もちろん、IETFでもMozillaのMartin Thomson氏らによって同様の提案がされています。 asnokaze.hatenablog.com それに続く形で、Chromeでも非セキュアなHTTPで送信されたCookieの有効期限を短くするかという議論が行われています。 Intent to Deprecate: Nonsecurely delivered cookies. Intent to Deprecate: Nonsecurely delivered cookies この議論は、Webのセキュリティ
safariのcookieポリシー変更により、Criteoの株価が約300億円吹き飛ぶ - adworld’s diary
safari のdesktop browserの規約変更をappleがアナウンスしたことでCriteo(Nasdaq)は300億円ほど、株価が下がった。 これは直近55USDから45USDと約10%株価を落としたことにより、6/13時点で約30億ドルとすると3億USD = 約327億円失ったことになる。 adexchanger.com この理由として、考えれているのが、WWDC 2017で発表されたIntelligent Tracking Prevention（ITP）という機能。 www.gizmodo.jp 要するに 3rd party cookie は1日以内しか保持されない。 1st party Cookie自体は30日以内しか保持されない。また会わせて自動再生動画広告もブロックすることになる。 appleの記事より索引 これにより、 計測および、リターゲティング用cookieが保
認証トークンをCookieに保存するのは卒業しよう - Qiita
Webアプリケーションの認証トークン（セッション）はCookieヘッダで送信するのが一般的だとは思いますが、 そろそろこのCookieに依存した方法は負の遺産ではないでしょうか？ 認証トークンの送信はRFC 7235で規定されているAuthorizationヘッダを使うと良いです。Basic認証とかDigest認証で使うやつですね。 実はBasicやDigestの他にRFC 6750でBearerというスキームが登録されています。単一の文字列を認証情報として送信するためのスキームで、トークンを送信するのにピッタリです。 参考: トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた その場合は、認証トークンはCookieではなくlocalStrage（またはsessionStorage）に保存することになると思います。
社内勉強会でCookieの仕様とセキュリティについて話しました - Opt Technologies Magazine
(from http://www.irasutoya.com/2012/11/blog-post_27.html ) 先日行った社内勉強会で、cookieの仕様（主にRFC6265）やセキュリティ（主にCSRF）について話したので、その内容をまとめました。 1st party/3rd party cookieについてや、CORS時のpre flightについても記述しています。 はじめに 但し書き cookieの仕様 cookieの概要 cookieの属性 cookieのブラウザ毎の差異 Path 属性 domain 属性 1st party cookieと3rd party cookie 動作確認 動作準備 3rd-partyの場合 1st-partyの場合 セキュリティ Ambient 権限 pre flightの仕組み 動作サンプル pre flightが飛ばない場合 pre fli
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Google Chrome」のサードパーティCookie廃止は延期 ～2024年内の非推奨化を断念／来年へ持ち越しへ
サブドメインをユーザーホスティングサイトに使うときのパターン(Same Origin/Cookie/Public Suffix List)
https://jp.techcrunch.com/2021/06/02/2021-05-30-europes-cookie-consent-reckoning-is-coming/
