「Google Chrome」のサードパーティCookie廃止は延期 ～2024年内の非推奨化を断念／来年へ持ち越しへ
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の基礎知識からブラウザごとのエッジケースまでおさらいする - 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
Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
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
Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
Railsを本番稼働させるときはnginxとsession storeの設定に注意 - Qiita
それぞれ上限値を越えてしまったために、出たエラーです。 回避する設定は以下。 ※追記（2014/04/15 21:00） そもそもnginxでheaderがデカイって怒られている原因はcookieに一杯値が入っていただけで、その原因はsessionに値をたくさん突っ込むようなことをしていたからなので、そもそもその時点で問題があります。 今回は一度nginxのエラーを解消しなければcookieの問題も気が付かなかったのですが、session storeをcookie以外にした時点でnginxのproxy bufferの設定は不要かなと思いました。 ということで、nginxの設定については蛇足ですね。 nginxのproxy bufferの設定 参考 参考URLの用にnginx.confのhttp{}の中に以下の設定を追加するだけで直りました。 デフォルトのproxy bufferのサイズを超
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サブドメインをユーザーホスティングサイトに使うときのパターン(Same Origin/Cookie/Public Suffix List)
TechCrunch
TechCrunch | Startup and Technology News