タグ

関連タグで絞り込む (29)

タグの絞り込みを解除

cookieに関するigrepのブックマーク (21)

  • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io


    Intro CSRF という古の攻撃がある。この攻撃を﹁古(いにしえ)﹂のものにすることができたプラットフォームの進化の背景を、﹁Cookie が SameSite Lax by Default になったからだ﹂という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、﹁CSRF がどうして成立していたのか﹂を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での﹁ベース﹂(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
    igrep
    igrep 2024/04/26
    「副作用があるエンドポイントをどう実装すべきか」 POST にする、Origin を確認する、SameSite Lax/Strict を明示する、Fetch Metadata も確認する
    リンク

  • Apple によるブラウザエンジン規制の緩和 | blog.jxck.io


    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 を用いる必要が
    Apple によるブラウザエンジン規制の緩和 | blog.jxck.io

  • 3PCA 27 日目: FedCM | blog.jxck.io


    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でR
    3PCA 27 日目: FedCM | blog.jxck.io

  • 3PCA 26 日目: Related Website Sets | blog.jxck.io


    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.gs
    3PCA 26 日目: Related Website Sets | blog.jxck.io

  • 3PCA 21 日目: SameSite Cookie | blog.jxck.io


    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 を付与するとこ
    3PCA 21 日目: SameSite Cookie | blog.jxck.io
    igrep
    igrep 2023/12/23
    "ちなみに 3rd Party Cookie とは離れるが、 Same Site Cookie を最大限使いこなすには read/write を分離するのがベストプラクティス ... つまり、 API への Read 権限を Lax にし、 Write 権限を Strict にする"
    リンク

  • 3PCA 19 日目: Super Cookie | blog.jxck.io


    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 Securit
    3PCA 19 日目: Super Cookie | blog.jxck.io
    igrep
    igrep 2023/12/23
     Super Cookie、名前しか知らなかった。たくさんサブドメインを用意して、それぞれについてHSTSでhttpsにアップグレードする/しないのパターンでユーザーを識別する、と。よく考えるなぁ  

    ●cookie
      
    リンク

  • 3PCA 11 日目: Cookie Banner | blog.jxck.io


    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
    3PCA 11 日目: Cookie Banner | blog.jxck.io

  • 3PCA 8 日目: P3P | blog.jxck.io


    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
    3PCA 8 日目: P3P | blog.jxck.io

  • 3PCA 7 日目: Cookie2 | blog.jxck.io


    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/20
    3PCA 7 日目: Cookie2 | blog.jxck.io
    igrep
    igrep 2023/12/07
    "もし 3rd Party Cookie が無効になれば、広告会社は同じことを達成するために別の仕組みを使うでしょう、そしてそれは Cookie よりももっと認識/制御することが難しいメカニズムになりえます"
    リンク

  • Cookie Store API による document.cookie の改善 | blog.jxck.io


    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 は非同期
    Cookie Store API による document.cookie の改善 | blog.jxck.io

  • Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita


    Chrome79以下や他ブラウザのデフォルト値。 Chrome80からこの値を設定する場合、Secure属性も必須となる。Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 ︻追記︼なおChrome80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
    Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita
    igrep
    igrep 2020/02/12
    “こういった外部サービスとの連携処理がエラーになります。 ECサイトであれば注文ができないことになるので損失が出る可能性が”
    リンク

  • Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io


    Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSiteCookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same SiteCookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
    Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
    igrep
    igrep 2018/10/27
     結構複雑なんだな。。。  

    ●cookie
    ●security
      
    リンク

  • どうして JWT をセッションに使っちゃうわけ？ - co3k.org

    備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ

  • Safari 11 Intelligent Tracking Preventionについて - Cybozu Inside Out | サイボウズエンジニアのブログ


    はじめまして、開発基盤部フロントエンドエキスパートチームの小林(@koba04)です。 チームメンバーがまだひとりなので、仲間を募集中です！ macOS High Sierra及びiOS11のSafariで導入されたIntelligent Tracking Preventionについて紹介します。 詳細は、下記のWebKitのブログに書かれていますが、Intelligent Tracking Preventionはクロスサイトトラッキングを制限することを目的とした機能です。 Intelligent Tracking Prevention クロスサイトトラッキングとは まず最初にクロスサイトトラッキングとは、複数サイト間でのユーザーの行動をトラッキングすることです。 クロスサイトトラッキングを行うには、トラッキングしたいサイトに、Cookieを設定した共通のリソースを埋め込みます。 これによ
    Safari 11 Intelligent Tracking Preventionについて - Cybozu Inside Out | サイボウズエンジニアのブログ

  • HTTPSを使ってもCookieの改変は防げないことを実験で試してみた


    寺田さんのブログエントリ﹁他人のCookieを操作する﹂には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP︵アクセスポイント︶があるケースを題材として、﹁HTTPSを使ってもCookieの改変は防げない﹂ことを説明します︵Secure属性使うと盗聴は防げますが、改変は防げません︶。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
    HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
    igrep
    igrep 2013/11/15
    “通信路上に攻撃者がいる場合でも、SSLの正しい利用により通信路上でのHTTPメッセージの盗聴・改ざんを防ぐことができますが、Cookieに関して言えば ... 改ざん（強制・改変）については防御できない”
    リンク

  • 第1回　まずは「クッキー」を理解すべし


    Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には﹁クロスサイト・リクエスト・フォージェリ﹂︵CSRF︶，﹁セッション・フィクセーション﹂などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー︵cookie︶の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
    第1回　まずは「クッキー」を理解すべし

  • Secure属性つきのCookieが読めなくても、書くことはできる | 水無月ばけらのえび日記

    公開: 2013年11月10日19時50分頃 とある調査をしていて、CookieのSecure属性について確認したのでメモ。 RFC6265の4.1.2.5にSecure属性についての記述があるのですが、そこにはこんな注意書きがあります。 Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more

  • 簡単ログインの終焉 x ガラケーとCookie x そしてFlashLite - latest log

    ガラケー(FP:フィーチャーフォン)周りの整理整頓と、ソーシャルカードゲーム界隈はいつまで FlashLite1.1 縛りなのかな? 調べ。 2009年当時は、FlashLite1.1 での開発がデファクト Flash Lite入門講座　第1回　日本のFlash Liteの仕様 | デベロッパーセンター (ε・◇・)з もう3年たってるし… そろそろ次にすすめるんじゃないの? を探るのがこのエントリの目的。 FP や FlashLite を取り巻く幾つかの流れ FlashLite は Adobe のロードマップから(かなり以前に)完全消滅 2012-03-31 で mova停波, 過去3年で 600万回線が FOMA へ移行 506i シリーズで mova は打ち止め。端末は2007年末に製造停止 2012-04-30 で Google が簡単ログインを廃止 Google のサービスを使い

    簡単ログインの終焉 x ガラケーとCookie x そしてFlashLite - latest log
    igrep
    igrep 2012/03/19
    "(ε・◇・)з 時既にお寿司やね"
    リンク

  • GoogleがSafariの設定を迂回してトラッキングしていたとされる件について - 最速転職研究会

    ※この記事の完成度は85%ぐらいなので後で追記します。 http://webpolicy.org/2012/02/17/safari-trackers/ http://online.wsj.com/article/SB10001424052970204880404577225380456599176.html http://blogs.wsj.com/digits/2012/02/16/how-google-tracked-safari-users/ 合わせて読みたい。 http://trac.webkit.org/changeset/92142 https://bugs.webkit.org/show_bug.cgi?id=35824 一番上のJonathan Mayer氏の記事については純粋に技術的なレポートなので、特におかしなことは書かれていない。元はといえばSafariのCooki

    GoogleがSafariの設定を迂回してトラッキングしていたとされる件について - 最速転職研究会
    igrep
    igrep 2012/02/21
    マスコミが好きそうな煽り方だよね。
    リンク

  • サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会


    前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾
    サードパーティCookieの歴史と現状 Part2 Webアプリケーションにおける利用とその問題 - 最速転職研究会
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.