We just added a new updated article that covers the same topic. You can find it here: Cookies vs Tokens: The definitive guide. Introduction There are basically two different ways of implementing server side authentication for apps with a frontend and an API: The most adopted one, is Cookie-Based Authentication (you can find an example here) that uses server side cookies to authenticate the user on
今日 @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では署名付ける代
Ruby on Railsの「CookieStore」では、ユーザーのセッションハッシュが暗号化されない状態でクライアントサイドのcookieに保存されていた。 オープンソースのWebアプリケーション開発フレームワーク「Ruby on Rails」にユーザーのcookie保存に関する脆弱性が指摘され、大手サイトを含む2000あまりのWebサイトで問題が放置されているという。セキュリティ企業Kaspersky Labのニュースサービス「Threatpost」が11月26日に伝えた。 この脆弱性はセキュリティ研究者のG・S・マクナマラ氏が9月に指摘したもので、Ruby on Railsのデフォルトのcookie保存メカニズム「CookieStore」の問題に起因する。4.0以前のバージョンでは、各ユーザーのセッションハッシュが暗号化されない状態でクライアントサイドのcookieに保存され、各c
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
http://d.hatena.ne.jp/mala/20120220/1329751480 の続き。書くべきことは大体既に書いてあったので、補足だけ書く。 Googleは制裁金2250万ドルを支払うことでFTCと和解した http://jp.techcrunch.com/archives/20120809google-settles-with-ftc-agrees-to-pay-22-5m-penalty-for-bypassing-safari-privacy-settings/ まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。 2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。 問題の記述 http://obam
October 11, 2010: Reported on the front page of the New York Times Find the latest details, code, and implementations on github @ https://github.com/samyk/evercookie DESCRIPTION evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs),
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
はてなブログでは、ブラウザの設定などでサードパーティCookie（クッキー）を拒否している場合でも、記事にはてなスターやコメントを付けたり、ブログの購読などができるようにしました。また、ヘッダの共通メニューから管理画面にも移動できます。 なお、多くのブラウザは初期設定でサードパーティCookieを許可しており、そのままご利用いただいてる方には、今回の変更による影響はとくにありません。 プライバシーへの懸念などからサードパーティCookieを拒否している方には、次のように動作が改善されます。どうぞご利用ください。 サードパーティCookieを拒否している場合の動作改善 ヘッダメニュー サードパーティCookieを拒否している際には、ヘッダに「管理」メニューを追加しました。ここからブログの管理画面に移動できます。 ヘッダメニューに「管理」が追加される ヘッダメニューは、サードパーティCooki
トップ コラムGoogleAnalyticsのCookieは、なぜサードパーティCookieではなく、ファーストパーティCookieなのか？ ブログをご覧頂いている皆さん、こんにちはニコライです。Nexalではテクニカルエンジニアとして勤めています。技術的な観点から、皆さんの業務にお役立て頂けそうな情報を更新して参ります。今後とも宜しくお願いします。 初投稿のお題は、GoogleAnalyticsのCookieについてです。 公式ヘルプによると、GoogleAnalyticsではアクセス解析の仕組みとしてCookieを利用しており、且つそれはファーストパーティCookieであると謳われています。ただ、これには合点がいかない方も多くおられるようです。「Googleのサーバと通信しているのだから、サードパティではないのか？なぜファーストパーティ？」という疑念があるからです。以下が公式ヘルプの一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
