「正しいCSRF対策、してますか？」記事へのコメント

ワンタイムトークンは不要では

[tix (7637)]

金床氏の提案する対策(「正しい対策その1: ワンタイムトークンを正しく使用する方法」)は、主に次の二つから成ります。リクエスト1とかレスポンス1とかの意味は 金床さんのページ [jumperz.net]を参照してください。

1. リクエスト1を POST にする(リクエスト1がGETだったらサーバーはエラー等を返すようにする)
2. ワンタイムトークンを使用する。詳しくは、 (a) 処理1でワンタイムトークンを生成する。 (b) レスポンス1に含まれるフォームにトークンを hidden フィールドとして追加する。 (c) 処理2では本来の処理(日記にデータを追加する等)の前に、 cookie として送られてきたセッション ID と hidden フィ

--
鵜呑みにしてみる？

Re:ワンタイムトークンは不要では

[hsk18317 (30467)]

たぶん、同じセッションIDを含んでいる他のページをGETで取得できる場合、そのセッションIDは容易に類推可能なものになってしまうからじゃないでしょうか。

高木さんの対策は本質的には正しいのですが、「一致させる値を予測することは不能であるはずなので」という前提が崩れてしまったということだと思います。

# あ、不能→不可能のTypo発見(^^;。

Re:ワンタイムトークンは不要では

[Anonymous Coward]

だからそれは、ブラウザーに脆弱性がある場合の話では？

ブラウザーに脆弱性があっても大丈夫なようにウェブアプリを作ることなんて不可能でしょ！

Re:ワンタイムトークンは不要では

[hsk18317 (30467)]

> ブラウザーに脆弱性があっても大丈夫なようにウェブアプリを作ることなんて不可能でしょ！

一般論としてはその通りだと思います。

今回のケースは、言ってしまえば（ある特定のブラウザの）影響の大きい深刻なバグが放置されており、その対処法が発表されただけとも解釈できるんですが、私があの手法を評価しているのは、今後同様のバグが発見された場合でも、この手法をとっていれば回避可能であると思える点です。

あの文書の隠れた肝は、ログインからログアウトまでという比較的長い時間保持されるような情報を鍵として流用することの危険性を指摘し、ある特定のクリティカルな操作のためだけに鍵を準備して、事が済んだら即座に消す、という手法の提案を行ったという所にあるんじゃないかなあと思っているんですが、どうでしょう。