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
Device Bound Session Credentials（DBSC）は、Cookie の盗難やセッションの不正使用からユーザー セッションを保護するために設計された新しいウェブ機能です。この機能は、Chrome 135 でオリジン トライアルとしてテストできるようになりました。 背景 Cookie は、最新のウェブ認証において重要な役割を果たしており、ユーザーがブラウジング セッション間でログインしたままにしておくことが可能です。しかし、攻撃者は盗まれた認証 Cookie を悪用してセッションを乗っ取り、多要素認証やその他のログイン セキュリティ メカニズムを回避するケースが増えています。 マルウェアの運営者は、侵害されたデバイスからセッション Cookie を抜き出し、ユーザー アカウントへの不正アクセスを可能にします。Cookie は署名なしトークンであるため、所有権の証明を必
Intro OWASP に Cookie Theft 対策の Cheat Sheet を提案し、マージされた。 Cookie Theft 2FA や Passkey の普及により、Password そのものを盗んだとしても、可能な攻撃は限られている。 一方、Session Cookie は、認証済みであることを示し(Proof of Authentication)、かつ持っているだけで効果を発揮する値(Bearer Token)であるため、Password 以上に盗む価値がある。 Session Cookie が盗まれれば、いかに Password を無くしていようが、Passkey をデプロイしていようが、何段階の認証にしようが、全ての努力は水の泡なのだ。 「Session Cookie を盗まれないようにする」のは、サービスにとってはもちろんだが、最近はむしろクライアントの方に攻撃が向
Intro Chrome チームより提案された Device Bound Session Credentials の実装が進み、Flag 付きで試すことができる。 この提案の背景と、解決する問題、現時点での挙動について解説する。 背景 2FA や Passkey の普及により、認証部分はかなりセキュアになってきた。インシデントによりパスワードが漏洩しても、それだけでなりすましを成立させるのも困難になっている。 そこで攻撃者の注目を集めているのが、Cookie の窃取(Cookie Theft)だ。 認証がいかに堅牢になっても、有効な Session Cookie を盗むことができれば、その値を Cookie フィールドに付与してリクエストするだけで、なりすましを成立させることができる。 いわゆる Session Cookie は、Proof of Authentication として実装さ
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。 筆者が公開情報を読んで解釈したものなので、内容は保証しない。 前提 iOS/iPadOS に入れられるブラウザには、WebKit を用いる必要があ
Intro このエントリは、3rd Party Cookie Advent Calendar の 27 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は、散々壊れるユースケースとして解説してきた「認証連携」をカバーする FedCM について解説する。 Federated Credential Management 認証連携 あるサイト(RP)の認証を別のサイト(IDP)の認証で行いたい場合、両者の連携は 3rd Party Cookie で行われてきた。 例えば、RP に IDP を <iframe> で埋め込み、IDP に対するログイン済みの Cookie があれば、その情報を JS で RP に
Intro このエントリは、3rd Party Cookie Advent Calendar の 26 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日からは、Privacy Sandbox の「広告」以外の API を解説していく。 同一組織の別ドメイン グローバル企業であれば、各国の ccTLD でローカライズされたサービスを提供するのは一般的な運用だ。 google.co.jp google.co.uk google.de google.fr etc 他にも、例えば用途ごとにドメインを分ける運用も一般的だろう。 google.com googleusercontent.com fonts.gst
Intro このエントリは、3rd Party Cookie Advent Calendar の 21 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Google が 3rd Party Cookie を Deprecate していく方針を発表してから、最初に始めたのが SameSite Lax by Default だった。 これが何のために行われたのかを解説する。 eTLD+1 とは SameSite とは「eTLD+1 が同じ」という説明になる。これを理解するには eTLD を理解する必要がある。 例として example.com ドメインを持ち、そこに以下のような Cookie を付与するところ
Intro このエントリは、3rd Party Cookie Advent Calendar の 19 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は Super Cookie の解説をする。迂回手段ゾーンとしては、最後に紹介する手法だ。 Super Cookie Super Cookie は、最初筆者も非常に驚いた、トラッカーの執念を感じる手法だ。 まず前提として、ブラウザのどこかに情報を保存でき、それがある程度の期間永続化され、かつ自動的に取得できるようなものであれば、トラッキングに応用が効く。 そこで目がつけられたのが HSTS (HTTP Strict Transport Security
Intro このエントリは、3rd Party Cookie Advent Calendar の 11 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は、各国で法律が整備されていった流れや、主な法律の特徴を解説した。 しかし、法律はあくまで法律であり仕様ではないため、「どう実装するべきか」は各サービスに委ねられている(ガイドラインなどはあるが)。 多くの場合、これを Web の実装に落とし込むと、いわゆる「Cookie バナー」相当になるわけだ。 今回は、実世界でどのようなバナーが提供されているのかを見ていく。 Cookie Banner "Cookie Banner", "Cookie Notic
Intro このエントリは、3rd Party Cookie Advent Calendar の 8 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、Cookie2 が失敗した後に、別のアプローチでこの課題に挑んだ P3P を解説する。 P3P (Platform for Privacy Preferences) P3P は W3C では 1997 年頃から作業が始まり、2002 年に 1.0 が Recommendation になっている。 The Platform for Privacy Preferences 1.0 (P3P1.0) Specification (w3.org) https
Intro このエントリは、3rd Party Cookie Advent Calendar の 7 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここからは第二幕、人類と 3rd Party Cookie の闘いの歴史を見ていく。 「歴史の話はいらない、早くコードを見せろ」と思っている読者の気持ちもわかるが、残念ながら背景がわかっていないとまともな闘いはできないだろう。 Cookie2 この話は、すでに別のエントリで詳細に書いたが、このアドベントカレンダーに合わせて要点のみを抜粋する。 Cookie2 とは何か | blog.jxck.io https://blog.jxck.io/entries/2
Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie 基本的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。 同期 API 最も深刻なのは、I/O を伴いながら、同期 API として定義されているところだ。 この API は古くから実装されているため、I/O は非同期 A
図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないためにおこる脆弱です。 たとえば会員の退会ページを https://example.com/mypage/delete/で用意し、 ボタン操作でsubmit=1が送信されて退会処理が実行される仕様の場合、 パラメータが誰でもわかるので、外部に用意された悪意のあるフォ
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionID
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
はじめまして、開発基盤部フロントエンドエキスパートチームの小林(@koba04)です。 チームメンバーがまだひとりなので、仲間を募集中です！ macOS High Sierra及びiOS11のSafariで導入されたIntelligent Tracking Preventionについて紹介します。 詳細は、下記のWebKitのブログに書かれていますが、Intelligent Tracking Preventionはクロスサイトトラッキングを制限することを目的とした機能です。 Intelligent Tracking Prevention クロスサイトトラッキングとは まず最初にクロスサイトトラッキングとは、複数サイト間でのユーザーの行動をトラッキングすることです。 クロスサイトトラッキングを行うには、トラッキングしたいサイトに、Cookieを設定した共通のリソースを埋め込みます。 これによ
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」（CSRF），「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー（cookie）の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く