2005年04月25日(Mon) HT Xeon 2発ぶん回し [長年日記]
● gperfとIRAFがload averagを1.5ずつくらい分けてる。そういうわけで人間はちょっとだけ暇
● [tDiary] ワンタイムトークンの実装方法を考えてみる
セキュリティ関連の実装はよーく考えてから始めたいのでつらつらと考えてみる。
- 目的
- CSRF対策 - 日記の文章やコメントが送付された時に、それが自分自身でそのクライアントのために作ったフォームによるものであることを確認する
- 制限事項
- 携帯電話から投稿される可能性もあるのでリファラは使えない
- 実装方法 - ワンタイムトークン
- フォームの隠しフィールドにヒミツの値を設定しておき、その値が真正のものであることを確認する
さて。ここでヒミツの値をどうやって作るのか、が問題なわけだ。クライアントそれぞれに固有の値で、適当な頻度で変更されないといけない。
例えば、クライアントのIPアドレスとエージェント名と固定されたヒミツの文字を適当に混ぜて一方向ハッシュ関数をかけてそれをクライアントに渡すのかな…。これだけだと「適当な頻度で変更されないといけない」という条件に合わない。フィールドをもうひとつ設けて、saltをフォーム側に記録しておくのはどうだろうか…。
サーバー側でも作った値を保存しておいて確認する必要があるだろうか。セッションIDのように乱数で作った値をフォームに記録しておいてサーバー側の記録と比較することもできるけれど、それで十分なのだろうか。
むずかしー。
(追記)高木さんの日記にクロスサイトリクエストフォージェリ(CSRF)の正しい対策方法が記されている。tDiaryの場合はBasic認証(あるいはDigest認証)されたページへのCSRFを防ぐ必要があるのだけれど、それは「続く」となっている。期待。いっぽう、ツッコミ(ログインする必要がない)については、「(セッションIDやワンタイムトークンは)Session Fixation攻撃によって回避される」とある。あり。
ちょっとだけ検索してみたところ、Session Fixation攻撃(セッション固定攻撃)とは、鳩丸ぐろっさりによれば閲覧者側がログイン前にセッションIDを指定できてしまう脆弱性のようだ。上に書いたように、ツッコミフォームを生成する時点でヒミツの値を割りあてればこの脆弱性は無いように思えるけれど違うのかな。もうちょっと考えてみないと。
最近のツッコまれどころ