鳩丸ぐろっさり (用語集)

当然ご覧になっていると思いますが、

クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法

http://takagi-hiromitsu.jp/diary/20050427.html#p01

という記事が出ていたので、用語の解説と見比べてみました。

> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

逆に言うとそこまでチェックしないと対策にならないわけですね。

> もう一つの方法は、攻撃者が知り得ない値をリクエストに含めておくというものです。

> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

>> この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。

>逆に言うとそこまでチェックしないと対策にならないわけですね。

　そういうことです。空の Referer を受け付けてしまうと対策にならないということです。

>> たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、

>セッションIDはまさにそのような性質を持った値である(はずだ)から車輪を再発明する必要はないということですね。

　ああ、この辺は語弊がありますね。

　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　この辺の説明は難しいですね。

>　通常は Cookie の値としてセッション ID が使われますが、その場合はターゲットのブラウザが自動的に Cookie: を再送してしまうので、攻撃者がこれを予測する必要はそもそもありません。

>　そうではなくて、input type="hidden" にランダムな値が入っているような場合は、攻撃者は罠にこの値も含めなくてはなりませんから、攻撃が困難になります。

　さらに補足すると、Cookie として使用している値と同じものを hidden 値に含めておき、そちらもチェックするという対策でも大丈夫なはずです (もちろん攻撃者が Cookie を盗めないという前提です。Cookie を盗めたら CSRF 以前の問題なので)。

　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

　ちょっと細かく書きなおしてみました。

　わかりやすくなったでしょうか?

>　そういう意味ではセッション ID とは異なる別のランダム値をあらためて用意する必要は無いので、車輪の再発明は必要ないともいえます。

というか最初からそういうつもりで書いた(高木さん【誰】が言っているように、セッションIDをそのままinput type="hidden"に含めればいいから別途定めるランダム値を生成する必要はないと言いたかった)のですが、圧倒的に舌足らずでした。ありがとうございます【謎】。

>というか最初からそういうつもりで書いた

　あうあう、読解力不足でした。

　すみません。

　まあ最終的には意図が汲めたということでひとつ。

> ※2006-04-02追記: 上記リンク先は閉鎖されたようです。現時点では該当のGoogleキャッシュ (72.14.203.104) で読むことが可能ですが、それもじき消滅するかと思われます。

復活してます。