パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • 金床氏の提案する対策(「正しい対策その1: ワンタイムトークンを正しく使用する方法」)は、主に次の二つから成ります。リクエスト1とかレスポンス1とかの意味は 金床さんのページ [jumperz.net]を参照してください。
    1. リクエスト1を POST にする(リクエスト1がGETだったらサーバーはエラー等を返すようにする)
    2. ワンタイムトークンを使用する。詳しくは、 (a) 処理1でワンタイムトークンを生成する。 (b) レスポンス1に含まれるフォームにトークンを hidden フィールドとして追加する。 (c) 処理2では本来の処理(日記にデータを追加する等)の前に、 cookie として送られてきたセッション ID と hidden フィ
    --
    鵜呑みにしてみる?
    • たぶん、同じセッションIDを含んでいる他のページをGETで取得できる場合、そのセッションIDは容易に類推可能なものになってしまうからじゃないでしょうか。

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

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

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

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

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

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

          • 別ACですが、
            その場合、ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか?正直に告白すると私はクッキーとhidden以外の方法でのセッション管理のやり方を知りません。
            Cookieオフのユーザでも使えるようにするなら、hiddenにセッションIDを入れます。何か問題がありますか?
            • > 何か問題がありますか?

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

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

              • このスレの流れは「ブラウザ側でクッキーが無効に設定されていたら、どうやってセッション管理するのでしょうか?」とおっしゃった話ではありませんでしたっけ?
                セッションIDを流用すると、すべての状態遷移をPOSTで実装しない限り、CSRF対策としては本来一致させる値を予測することは不可能な値を埋め込まなければ・・・・
                クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。
              • えーと、誰かも書いていたと思いますが、答えとしてすべてをPOSTで実装する(しなおす)、は現実的には無理かなと考えていました。

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

                ということであるなら

                CSRF対策にセッションIDを流用するために、すべての状態遷移をPOSTで実装する(しなおす)。
                というアプローチよりは、
                CSRF対策用にワンタイムトークンを生成して、操作完了後に消す
                というアプローチのほうが望ましいだろうというのが、「ワンタイムトークンは不要では」というコメントに対する私の意見です。

              • CSRF対策用にワンタイムトークンを生成して、操作完了後に消す
                というアプローチのほうが望ましいだろうというのが、「ワンタイムトークンは不要では」というコメントに対する私の意見です。
                は?
                セッション管理はどうしたんですか。セッション管理なしじゃ、動きもしないでしょうに。
              • 言葉足らずだったようで、すみません。

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

              • 後者のアプローチでは、セッション管理はセッションIDで行います。
                クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。
              • > クッキーが使われていない前提ですから、元々すべての状態遷移をPOSTで実装するしかありません。

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

                セッションIDとCSRF対策用の鍵が別になっているよう

              • by Anonymous Coward on 2006年04月04日 1時26分 (#914716)
                いやだからさ、クッキー無効の前提で、どうやってセッション管理するの?って言ってるでしょ。まずそれに答えてみなよ。そうすれば君がおかしな思考に陥っていることに気づくよ。
                親コメント
              • だからhiddenでって、、、あ。

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

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

                親コメント

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

処理中...