Cookieの仕様改定版、RFC6265bisの議論 - ASnoKaze blog
追記 10190510 関連して、このような動きもあります。 Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog Cookieの仕様と拡張仕様 HTTPのCookieの仕様は RFC 6265 - HTTP State Management Mechanism で定義されております。 2015年頃より、IETFのHTTPbisワーキンググループではCookieのセキュリティを向上させる目的で拡張仕様が3つほど議論されていました。 Cookie Prefixes 付与する属性をCookie名に含めることで、変更できなくする(Chrome51, Firefox50) Same-Site Cookies SameSite属性の追加。クロスサイトへのリクエスト時にはCookieヘッダを付けなくなる(Chrome 51) Deprecate mod
認証トークンをCookieに保存するのは卒業しよう - Qiita
Webアプリケーションの認証トークン（セッション）はCookieヘッダで送信するのが一般的だとは思いますが、 そろそろこのCookieに依存した方法は負の遺産ではないでしょうか？ 認証トークンの送信はRFC 7235で規定されているAuthorizationヘッダを使うと良いです。Basic認証とかDigest認証で使うやつですね。 実はBasicやDigestの他にRFC 6750でBearerというスキームが登録されています。単一の文字列を認証情報として送信するためのスキームで、トークンを送信するのにピッタリです。 参考: トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた その場合は、認証トークンはCookieではなくlocalStrage（またはsessionStorage）に保存することになると思います。
RadicalResearch HSTS Super Cookies
Websites could use a security feature of your iPad to track your browsing even if you clear the browser history or completely replace the device. Demonstration ... This is a unique value that was generated by JavaScript in this page. The page attempts to store this value in your web browser and read it again when you visit the page in the future. Different web browsers don't behave exactly the sam
POODLE攻撃の検知とJavaによる検証コード
はじめに SSLv3のパディングに注目した攻撃手法であるPOODLEは、以前こちらのブログのエントリで取り上げたことがあるBEASTとCRIMEに非常によく似た攻撃です。今回はこのPOODLEについて、一般的な視点とはやや異なる、筆者独自の意見を述べてみたいと思います。 必ずしもSSLv3を無効にする必要はない POODLEの対策として書かれている情報はそのほぼ全てが「SSLv3を無効にする」というものですが、個人的には技術的にもう少し踏み込んで考えてみても良いのではないかと感じます。私は以前のエントリで次のように指摘しています。 BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策（RC4にする/TLSをバージョンアップする）を行い、CRI
Ojktoto > Ada Togel Online Terbaik Di Situs Toto Terpercaya
Kalian bisa bernapas dengan lega sekarang, karena telah hadir situs toto terpercaya yang bernama Ojktoto. Koleksi togel online yang ditawarkannya sangatlah beragam dari togel hongkong, toto wuhan, togel sdy, toto macau, togel kamboja, toto sgp dan masih banyak lagi yang bisa dimainkan dengan minimal bet 100 perak. Hadiah toto 4d yang dikasih oleh bandar togel online terbaik ini juga sangatlah besa
ドメインあたりのクッキー数上限と上限に達した場合の挙動
BrowserStack にてそれぞれデフォルト設定のブラウザで調査。IE 中心に調べたので他のブラウザは網羅的ではない。あとから補完して別途公開したい。 サマリー 最も一般的な挙動は、追加日時 (おそらく最終更新日時) が古いものを一件削除し、新しいクッキーを受け入れるという、LRU 的なアルゴリズム。ここからブラウザやバージョンによってバリエーションがある。 Chrome は一件ではなく一度に三十件削除する その代わり受け入れるクッキー数は多め バックエンドを Chromium (Blink) に切り替えてからの Opera も同様 古い Opera は、追加しようとしたクッキーを受け入れ、その次に新しいもの一件を削除する。 Safari は単に追加順ではなく独自のソート順でクッキーを管理。その降順または昇順で一件を削除する。 バージョンによって動きがばらばらなので、詳しく調査したい。
Cookie(クッキー)の届く範囲 (あいまいモード)
Cookieが届く範囲を再確認 別のページでCookieについて解説しましたが、 実際Cookieを利用したプログラムを作ると疑問に思えることも出てきます。 その一つとして、Cookieが届く範囲は？というものがあります。 発行されたサーバー（ホスト）に返信されるというのが基本ですが、 Cookieの仕様には「domain」や「path」というのがあったのを覚えてますでしょうか？ （なにそれ？という方は下記のW3CのRFCか前回の解説をどうぞ、、、） Cookieの仕様は下のリンクをどうぞ・・・ W3C (RFC 2109)HTTP State Management Mechanism Netscape HTTP Cookies Cookieの詳細については上のリンクで確認していただくとしても、 実際にプログラムを書く場合にどうやって使うの？という場面も多いと思います。 自分もCookie
Nginx + mod_lua で認証フィルタを作ってみる
画像サーバーなどでログインチェックを Apache + mod_perl で実装していましたが、古代のクライアントへの対応はもう不要だろうということで、mod_perl やめたいし、もっとシンプルな実装にできそうだから nginx + mod_lua を試してみようとやってみました。 キャッシュとして memcached を使いたかったので https://github.com/agentzh/lua-resty-memcached も込で全部入れてくれる OpenResty をインストールしました。 OpenResty のインストール $ tar xvf ngx\_openresty-1.4.2.9.tar.gz $ cd ngx\_openresty-1.4.2.9 $ ./configure --prefix=/opt/ngx\_openresty-1.4.2.9 --with-lu
Authentication in Avatar
Legacy Java EE Home The Java EE project has been contributed to Eclipse Foundation and has been renamed to Jakarta EE. All active work is taking place at this new location https://projects.eclipse.org/projects/ee4j https://jakarta.ee/specifications The following legacy archives are available for anyone who wishes to browse the extensive history, prior to contribution to Eclipse. Key Java EE resour
How to implement RESTful authentication - Synopse
HTTP basic auth over HTTPS This first solution, based on the standard HTTPS protocol, is used by most web services. It's easy to implement, available by default on all browsers, but has some known draw-backs, like the awful authentication window displayed on the Browser, which will persist (there is no LogOut-like feature here), some server-side additional CPU consumption, and the fact that the us
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
「パーソナルデータ研究会報告書」に出てくるパーソナルデータの区分と取り扱いルールを表に整理してみた : 企業法務マンサバイバル
2013年06月13日08:00 「パーソナルデータ研究会報告書」に出てくるパーソナルデータの区分と取り扱いルールを表に整理してみた カテゴリ法務＿情報法務 businesslaw Comment(0)Trackback(0) 5月下旬にもちょっとだけ紹介した総務省のパーソナルデータ研究会の報告書が、パブコメを経て確定版として昨日リリースされました。 ▼「パーソナルデータの利用・流通に関する研究会」報告書の公表（総務省） 一言で言えば、語られている内容には目新しさはあまりないながらも、これまでの国内でのパーソナルデータに関する議論が過不足なくまとめ上げられた上で総務省のお墨付きがついた形となり、（国際的な目線に耐えうるのかはやや懸念を抱くものの、）昨年リリースされたスマートフォンプライバシーイニシアティブとあわせて、この文書が日本のネットビジネスにおける個人情報・パーソナルデータの考え方の
Firefox 22 で予定されていたサードパーティ Cookie のデフォルトブロックは延期
つい先日、5月 14日にFirefox 21 が正式にリリースされましたが、これと同時に Beta Channel に移行した、次バージョン、Firefox 22 （正式リリースは 2013年 6月 25日予定） で加えられる予定の大きな変更に、「サードパーティ Cookie のデフォルトブロック」 がありました。 Firefox 22 / 23 での変更点のうち気になる部分をまとめ しかし、この変更に対する影響が大きいことから、もう少しデータを収集し、解析するため、この変更が延期されたとのこと。 Firefox 22 サイト互換性情報 ： MDN C is for Cookie ： Brendan Eich 851606 - Disable bug 818340 for Beta until we're ready ： Bugzilla@Mozilla 経緯に関しては、現 Mozilla
HTTP Cookies: What's the difference between Max-age and Expires? - Peter Coles
24 October 2009 HTTP Cookies: What's the difference between Max-age and Expires? Quick Answer: Expires sets an expiry date for when a cookie gets deleted Max-age sets the time in seconds for when a cookie will be deleted (use this, it’s no longer 2009) Internet Explorer (ie6, ie7, and ie8) does not support “max-age”, while (mostly) all browsers support expires Max-age vs Expires, let’s dive in a l
Yummy cookies across domains
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
perf.fail - do, learn, fail forward. – Evite's Gallery: ads targeting gone wrong
marcfasel/SessionInCookie · GitHub - Sample code to demonstrate the Session In Cookie pattern
http://browsercookielimits.x64.me/