「正しい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]

GETで取得できるページにはセッションIDを含めなければいいだけのことです。というかCSSXSSを想定してるなら含めてはいけません。
逆にセッションIDを(もしくはワンタイムトークンなら何であれ)含める必要があるページは、POSTで生成しなければどうセッションIDと無関係なランダム値にしても意味ありません。

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

[hsk18317 (30467)]

> GETで取得できるページにはセッションIDを含めなければいいだけのことです。

その場合、ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか？正直に告白すると私はクッキーとhidden以外の方法でのセッション管理のやり方を知りません。URL埋め込みというのは却下でお願いします。 [aist.go.jp]

金床さんの提案手法は、CSSXSSで仮にセッションIDが盗まれたとしても有効な対策と理解していたのですが、勘違い？

ついでに書いておくと、今回の件でセッションID

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

[Anonymous Coward]

別ACですが、

その場合、ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか？正直に告白すると私はクッキーとhidden以外の方法でのセッション管理のやり方を知りません。

Cookieオフのユーザでも使えるようにするなら、hiddenにセッションIDを入れます。何か問題がありますか？

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

[hsk18317 (30467)]

> 何か問題がありますか？

セッションIDを流用すると、すべての状態遷移をPOSTで実装しない限り、CSRF対策としては本来一致させる値を予測することは不可能な値を埋め込まなければならないのに、特定することが可能になってしまう(セッションIDと一緒)という、#914151で指摘した問題に戻ってしまいます。

で、ワンタイムトークンを都度生成すれば、類推不可能という点においてはより望ましいのではないかという理解です。

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

[Anonymous Coward]

このスレの流れは「ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか？」とおっしゃった話ではありませんでしたっけ？

セッションIDを流用すると、すべての状態遷移をPOSTで実装しない限り、CSRF対策としては本来一致させる値を予測することは不可能な値を埋め込まなければ・・・・

クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。

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

[hsk18317 (30467)]

えーと、誰かも書いていたと思いますが、答えとしてすべてをPOSTで実装する（しなおす）、は現実的には無理かなと考えていました。

で、
> クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。

ということであるなら

CSRF対策にセッションIDを流用するために、すべての状態遷移をPOSTで実装する(しなおす)。

というアプローチよりは、

CSRF対策用にワンタイムトークンを生成して、操作完了後に消す

というアプローチのほうが望ましいだろうというのが、「ワンタイムトークンは不要では｣というコメントに対する私の意見です。

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

[Anonymous Coward]

CSRF対策用にワンタイムトークンを生成して、操作完了後に消す
というアプローチのほうが望ましいだろうというのが、「ワンタイムトークンは不要では｣というコメントに対する私の意見です。

は？
セッション管理はどうしたんですか。セッション管理なしじゃ、動きもしないでしょうに。

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

[hsk18317 (30467)]

言葉足らずだったようで、すみません。

後者のアプローチでは、セッション管理はセッションIDで行います。セッションIDとは別に、CSRF対策用のワンタイムトークンを生成して利用すると言うことです。そうすればPOSTで実装する必要が出てくるのは、ワンタイムトークンが利用される場面だけで済むんじゃないでしょうか。

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

[Anonymous Coward]

後者のアプローチでは、セッション管理はセッションIDで行います。

クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。

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

[hsk18317 (30467)]

> クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。

議論が食い違っていますね。私の考えるCSSXSSでセッションIDが漏洩するとまずい理由は、セッションIDをCSRF対策に「流用」した結果、本来予測可能であってはならないCSRF対策用の鍵(トークンの方が正しい用語？)が特定可能になってしまうからです。セッションIDとは異なるワンタイムトークンを使えば、セッションIDからのCSRF対策用の鍵の特定はできなくなります。ここまでは良いでしょうか。

セッションIDとCSRF対策用の鍵が別になっているような実装であれば、セッションIDをhiddenに入れた事によって(実はクッキーでも一緒なんですが)それが漏洩したとしても、対CSRF対策において、セッションID漏洩の結果もたらされる危険性は0となり、すべての状態遷移をPOSTで実装する必要はなくなります。もちろんハイジャック等の他の危険性には配慮する必要がありますが、そこはhidden、クッキーに関わらず「セッションIDが漏洩する」という事への対策の話となるので、CSRFの話とは別（の大事な）議論になると思っています。

もしかすると、セッションIDについて、「漏れてはならないもの」と考えているか、「漏れるのはしょうがないもの」と考えているかの違いでしょうか。私は後者の立場で、セッションIDが漏れた場合でも、金床さんの提案したPOSTを使ってワンタイムトークンを新たに生成するという手法は、セキュリティを確保できる有効な対策になっており、また、「すべての状態遷移をPOSTで実装するしかありません。」という制限が生じるのは、セッションIDをクリティカルな場面に流用しようとしたがために導かれる、間違った結論だと思います。

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

[Anonymous Coward]

いやだからさ、クッキー無効の前提で、どうやってセッション管理するの？って言ってるでしょ。まずそれに答えてみなよ。そうすれば君がおかしな思考に陥っていることに気づくよ。

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

[hsk18317 (30467)]

だからhiddenでって、、、あ。

長々とすみませんでした。恥ずかしながらようやく理解できました。

<form method="get" ...> + hidden があるじゃんというまさしく馬鹿な思い込みをしていたのですが、私が自ら却下したURL埋め込みと等価なんだから当然だめですね。失礼しました。あわせて、こんな私にお付き合いいただいてありがとうございました。