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サイトがユーザー本人の意図した動作であることを検証していないため
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
CORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点 - Qiita
クレデンシャルの送信 クロスオリジンのAJAXリクエストでクレデンシャル（クッキーの送信またはBASIC認証）を必要とする場合は、それを許可するオプションをフロント側Javascriptで付けておく必要があります。デフォルトではCORSリクエストでクッキーは送信されませんし、BASIC認証は送れません。 Fetch API の場合 fetch(url, { mode: 'cors', //クロスオリジンリクエストをするのでCORSモードにする credentials: 'include' //クレデンシャルを含める指定 })
署名付き Cookie を使用する - Amazon CloudFront
CloudFront 署名付き Cookie を使用すると、現在の URL を変更したくない場合や、複数の制限付きファイル (ウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合に、誰がコンテンツにアクセスできるかを制御できます。このトピックでは、署名付き Cookie を使用する際の考慮事項と、既定ポリシーとカスタムポリシーを使用するように署名付き Cookie を設定する方法について説明します。 署名付き Cookie に既定ポリシーを使用するか、カスタムポリシーを使用するかを決定する 署名付き Cookie を作成する場合、Cookie の有効期間など、署名付き Cookie で制限を指定する JSON 形式のポリシーステートメントを作成します。既定ポリシーまたはカスタムポリシーを使用できます。次の表では、既定ポリシーとカスタムポリシーを比較しています。
Rack::Session::Abstract::IDのsecureオプションをリクエストごとに変えられるようにしてみた
a2ikm/rack-dynamic_session_secure RailsのセッションストアではRack::Session::Abstract::IDに渡される:secureオプションの値によってCookieのsecure属性を付けたり外したりできるんだけど、基本的にベタの値*1しか受け付けていない。 これをリクエストによって切り替えられると嬉しい場面が出てきたので、Procを渡して動的に評価されるよう書いてみた。Railsだとこんな感じ: # Gemfile gem 'rack-dynamic_session_secure', github: 'a2ikm/rack-dynamic_session_secure' # config/initializers/session_store.rb secure = ->(env) { !!(Rack::Request.new(env).pa
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
Rails で (Rack の) セッション情報を Cookie に保存する仕組み - Qiita
Rails では特に (config/initializers/session_store.rb などで) 設定しない場合、セッションの情報をクライアントの Cookie に直接、(事実上) 平文で保存する。 実際に見てみよう。 $ rails new todo $ cd todo $ rails g scaffold tasks name $ rake db:migrate $ rails s # app/controllers/application_controller.rb class ApplicationController < ActionController::Base protect_from_forgery before_filter do # アクセスした日時を session に保存 session[:last_accessed_at] = Time.now end
Cookie Clicker
Slow connection? If not, please make sure your javascript is enabled, then refresh. If problems persist, this might be on our side - wait a few minutes, then hit ctrl+f5! Your browser may not be recent enough to run Cookie Clicker. You might want to update, or switch to a more modern browser such as Chrome or Firefox.
Rails で "cannot parse Cookie header: invalid %-encoding" に対処する - Qiita
tl;dr Rails で "cannot parse Cookie header: invalid %-encoding" ってエラーが頻発したら、 morenocarullo/rack-cleancookies を使って不正な cookie を無視するようにすると解決します。 試してみよう おもむろにブラウザであなたの Rails アプリを開き、コンソールから と入力して、ページをリロードしてみましょう。 500 が出ましたか？ エラー出た？ はい、cookie に "%" という文字列が入ると Rack が 500 を返します。 この挙動に関する議論は "invalid %-encoding" error leaves rack.request.cookie_hash == nil · Issue #225 · rack/rack bad diagnostics for malfor
お菓子の城でドット絵マリオクッキーを焼いてきた（マリオクッキーの作り方） - 全ての道は任天堂へ通ず - Lylat.com
上手に焼けました～！ ★とかハートとかお花とかキティちゃんとか、色々な形のクッキーが焼けました。 かわいいでしょ(*＾-＾*) ・・・。 いいや、そんな生ぬるいものを作るわけが・・・！ いいこと思いついた。お前その生地でドット絵作ってみろ 型抜きクッキーだけではありきたりなので、ドット絵マりオクッキーを作ってきました。最初の写真はむしろオマケ、マリオの余り生地で作ったものです。 「あー！マリオだー！」と、周囲のお子様達＆保護者の方々に好評でした。小さい子も知ってるんだねー。「どこまで出来た？」と度々覗きに来てくれたので、嬉しい反面ちょっと恥ずかしかったです。 生地が「プレーン」と「ココア」の2種類だったので、白色はプレーン生地、黒色はココア生地、薄い茶色は2つの生地を混ぜました。（マーブルになってしまって見栄えが悪いですね・・・） マリオクッキーの作り方 1.マリオクッキーチートシートをダ
Cookie(クッキー)の届く範囲 (あいまいモード)
Cookieが届く範囲を再確認 別のページでCookieについて解説しましたが、 実際Cookieを利用したプログラムを作ると疑問に思えることも出てきます。 その一つとして、Cookieが届く範囲は？というものがあります。 発行されたサーバー（ホスト）に返信されるというのが基本ですが、 Cookieの仕様には「domain」や「path」というのがあったのを覚えてますでしょうか？ （なにそれ？という方は下記のW3CのRFCか前回の解説をどうぞ、、、） Cookieの仕様は下のリンクをどうぞ・・・ W3C (RFC 2109)HTTP State Management Mechanism Netscape HTTP Cookies Cookieの詳細については上のリンクで確認していただくとしても、 実際にプログラムを書く場合にどうやって使うの？という場面も多いと思います。 自分もCookie
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
SSL で暗号化しても Cookie で secure 属性を指定しないと盗聴される可能性があるかもしれない
堅牢なお問い合わせフォームを作ることになり、規定書に Cookie には secure 属性を指定してねとありました。secure 属性なんて初めて聞いたので、ちょっと調べてみたところ、secure 属性以外にも expires 属性とかいろいろありますけど、知ってるやと思ったらこれも危険に繋がるみたい。 secure 属性って何 これを指定すると HTTPS の通信時のみクッキーを送信します。逆に指定しなければ HTTPS の時に作った Cookie が HTTP の時に見ることができてしまい、盗聴されることに繋がりますね。 expires 属性って何 クッキーの有効期限を指定するものなんですが、指定しなければブラウザを閉じたときは Cookie は破棄になるんですが、有効期限を指定した場合に危険があるみたいです。 この属性が指定されていなければ，ブラウザを起動していないユーザーが被害に
ke-tai.org > Blog Archive > ドコモのクッキー対応端末（iモードブラウザ2.0）のシェアは現状どれくらいなのかを調べてみました
ドコモのクッキー対応端末（iモードブラウザ2.0）のシェアは現状どれくらいなのかを調べてみました Tweet 2010/10/28 木曜日 matsui Posted in DoCoMo | 1 Comment » 先日からモバイル界隈をざわつかせていた、ヤマト運輸のかんたんログイン脆弱性問題で気になったので、ドコモのクッキー対応端末（iモードブラウザ2.0）のシェアを調べてみました。 まずヤマト運輸の問題について知らないという方はこちら。 → ヤマト運輸の携帯Webサイトに「かんたんログイン」関連の脆弱性があったようです [ke-tai.org] → ヤマト運輸ケータイサイトに脆弱性があった問題の続報 [ke-tai.org] 今回の問題に対する一番の対策は、端末IDを使った認証（いわゆる「かんたんログイン」）を使わずに、通常のPC向けサイトと同じようにクッキーでログイン情報を管理するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails 6.0.2.2で生成したauthenticity_tokenは5.2.4.3で利用できるのか