開発者の為の正しいCSRF対策

自称HTTPオタクで、Guardian@JUMPERZ.NET を開発・提供している金床さんが、渾身の力を込めてCSRF対策を発表。

なんかリンク着てたんで気がつきました。ぺこり>金床さん。

上の金床さんの文書は生きている文書です。死んだ文書ではなく、訂正がばんばんはいるかもです。そのために、MLまで立ち上げていますね、凄いや。名前の由来は…うししし。

Sea Surfers ML
http://www.freeml.com/ctrl/html/MLInfoForm/seasurfers@freeml.com

Gmailでも加入できるんだろうか…このML…

主な内容は以下に
  • あらゆる機能がターゲットとなりうる
  • ひとつの機能は2画面で構成される
  • CSRF以前の問題」については考えない
  • CSSXSS脆弱性を無視しない
  • 正しいCSRF対策
  • 正しい対策その1: ワンタイムトークンを正しく使用する方法
  • 正しい対策その2: パスワードの再入力を求める方法
  • 正しい対策その3: CAPTCHAを正しく使用する方法
  • Basic認証の場合
  • リファラーについて
  • SSLについて
  • 誤ったCSRF対策
  • 誤った対策その1: セッションIDをトークンとして使う
  • 誤った対策その2: 誤ったワンタイムトークン方式
  • 誤った対策その3: リクエスト2をPOSTにする
  • 誤った対策その4: 確認画面を挟む
  • 誤った対策その5: セッションIDを細かく変更する

反論:開発者の為の正しいCSRF対策

大岩 寛さんが、さっそく反論です。

おおいわのこめんと (2006-03-30)
http://www.oiwa.jp/~yutaka/tdiary/20060330.html#p01

この脆弱性の存在を根拠に「いわゆる高木方式は良くない、安全な他の方式にすべきである」という議論がよくあります。いつも反論してるのですが、割と議論が噛み合わないのは、ひょっとしたら僕が「いや、高木方式で安全なんだ」と主張しているように思われているのかなぁ、とふと感じました。

実はそうじゃないんですよね。僕の主張は、「いや、その状態ならパスワード毎回入力以外はどんな対策をやったって無駄だ」なんです。

まぁだから攻撃の複雑さという意味ではちょっとだけ難しくなるのは事実だけれども、所詮は鍵を植木鉢の下に隠すかポストの中に隠すか位の違いでしかなくて、鍵を泥棒の手の届かないところに管理するというレベルではないんで、別方式を提案・推奨する時にその辺りちゃんと議論せずに「こっちの水は甘いぞ」ってのは、個人的にはちょっと無責任だと思うけどなー。

茫漠としているのかCSRF対策

茫漠としているのは私の頭です。いきなりオチですが。

ブラウザに欠陥が無いとき、あるとき、色々考えられますし、現に今、いわゆるCSSXSSもあることですし、いわゆるCSSXSSが封鎖されたとしても、今後も考えていかなくてはいかない時期が再び来るかもしれません。なお,XSS脆弱性があるときにはそもそもCSRF対策は無意味ですのでここでは考えません。

核ミサイル発射装置は、バラバラに保管され、それぞれ別の責任者が管理している2個の鍵を用意しないとオン出来ないと聞いたことがあります。フェイルセーフなんですね。1個の鍵だけ盗まれてもなんともならない、そういう安全性の為です。

ブラウザの脆弱性に備え、Webアプリケーションのセッションのっとりを防ぐには、互いに独立した鍵を2重に用意して、悪人が両方共に盗み出しにくい仕組みにしてあげれば良いのかなぁと漠然と思うのです。具体的にはhiddenフィールドとcookieと2重に独立した鍵を用意しちゃう。で、悪人が片方だけ盗み出すことが出来ても両方の鍵がないかぎりセッション乗っ取りを許さない。

いわゆるCSSXSSのようなブラウザ実装の欠陥では、hiddenフィールドの内容を盗み出される蓋然性がありますが、cookieは原理的に盗み出されえません。互いに独立した乱数を2個用意、その乱数をセッションIDとしてサーバー側でダブルでセッション管理を行い、かたやcookieを通じて、かたやhiddenフィールドを通じて、セッションの継続性を判断出来れば一番良いことではないのでしょうか。CSSXSS脆弱性をついた攻撃は、上記の「仮称」ダブルセッション管理を打ち破ることは出来ません。また、今後cookieを盗み出すことが可能な脆弱性が発見されたとしても、その脆弱性だけではダブルセッション管理は打ち破れません。

セッションIDを従来のようなスカラーで持つのではなく、2次元のベクトルとしてサーバー側で管理し、ブラウザ側には、hiddenフィールドでx軸、cookieでy軸のセッション継続性を診断するような感じです。ひとつのブラウザの欠陥がこの両者の漏洩を許すことは今までもたぶんなかっただろうし今後もないと期待できます。

ラーメンのスープで言えば魚介系と動物系とのダブルスープ。これウマイ♪

植木鉢の下にも鍵を隠しますし、ポストの中にも隠します。泥棒さんが両方を一度に入手することが極めて難しければ良い訳です。

以上、茫漠とした感想です。金床さんが始めた今回のプロジェクトの本質を見極める能力が私にも欲しいです。背伸びしすぎかな。

この私見、茫漠としているだけでなく、全然勘違い、間違っているのですがね♪ええと、はてなダイアリーではCookieがメインなんでしたっけ?で、ひもついたものがhiddenフィールドに? 独立していないはずでしたよね、確か。そんなことも知らないでしゃべっているのですから真剣味が足りません、反省しる>自分。

Firefoxの為のメモ(後で見る→自分)

金床さんのところでみかけていたのを思い出しました。

<script\"src

<script\"\"src を入力,
<script\\\"\\\"src が返って来る。