[B! cookie] koba04のブックマーク

CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org

CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。たとえば『安全なウェブサイトの作り方』改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、

koba04 2014/02/17

リンク

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では署名付ける代

koba04 2013/11/28

リンク

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

寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe

koba04 2013/09/30

リンク

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

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