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

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

  • 金床氏の提案する対策(「正しい対策その1: ワンタイムトークンを正しく使用する方法」)は、主に次の二つから成ります。リクエスト1とかレスポンス1とかの意味は 金床さんのページ [jumperz.net]を参照してください。
    1. リクエスト1を POST にする(リクエスト1がGETだったらサーバーはエラー等を返すようにする)
    2. ワンタイムトークンを使用する。詳しくは、 (a) 処理1でワンタイムトークンを生成する。 (b) レスポンス1に含まれるフォームにトークンを hidden フィールドとして追加する。 (c) 処理2では本来の処理(日記にデータを追加する等)の前に、 cookie として送られてきたセッション ID と hidden フィ
    --
    鵜呑みにしてみる?
    • 先の#913853 [srad.jp]を読み返して、どうも誤解の余地が大きいような気がしたので補足します。

      僕の主張は、ワンタイムトークンを使うこと一切が不要である、というものではありません。それを明確にするため、サブジェクトを変えました。

      セッション ID を使うよりワンタイムトークンを使う方が安全かもしれない要因はいろいろあると思います。ただ、それは元の話題とは別の話と考えています。

      高木氏の「クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 [takagi-hiromitsu.jp]」での「簡潔な対策方法」はワンタイムトークンを使わないものでしたが、金床氏は、主要なブラウザである IE に XSSCSS 問題があるためワンタイムトークンを使う必要がある、と主張していました。それに対して、僕は、金床氏の「正しい対策その1」での XSSCSS 対策はリクエスト1を POST にすることによってなされているのであって、ワンタイムトークンを使うというのは無関係じゃないの? ということを書いたつもりでした。

      そもそも高木氏がこのページを書かれた背景には、 CSRF 攻撃の脅威が増しているのに正しい対策方法はよく知られていないという背景がありました。そこで、高木氏は、なるべく少ないコード変更でできる CSRF 攻撃対策として、「今までワンタイムトークンを使っていないなら、ワンタイムトークンを生成するコードを新たに書かなくても、前から使っているはずのセッション ID を hidden フィールドにも入れて一致をチェックするだけで対策になるんですよ、ほら簡単でしょ、だからすぐ対策しましょう」ということを書かれたのだと理解しています。

      僕は、 hidden フィールドに入れるのは cookie に入れるのと同じセッション ID でもかまわないというのは重要なポイントだと思うので、そうではないとする金床氏の主張に#913853で反論しました。しかし、それは、ワンタイムトークンを使うのと比較してセッション ID を使う方が安全性の面で良いと主張する趣旨ではないし、ましてやワンタイムトークンの意味をすべて否定する趣旨でもありません。
      --
      鵜呑みにしてみる?
      親コメント
      • とあるところで金床氏のページが残っているのを見つけたので読み返しました。すると、僕は根本的なところで金床氏のページを読み間違えていることがわかりました。
        • 金床氏は、ワンタイムトークンを使わずにセッション ID を使う方法の欠点を説明していた。
        • 金床氏は高木氏の対策でリクエスト1を POST にしたものについて言及しており、この方法で CSSXSS 問題には対策できている (ただし上の欠点があるため推奨しない) ことを述べていた。
        公開停止された文章なので引用しませんが、どちらも、「誤った対策その1: セッションIDをトークンとして使う」の最後2個の段落に書かれていました。

        この読み間違いの結果、#913853 [srad.jp]と#914676 [srad.jp]にて、金床氏のページの内容について多くの誤りを書いてしまいました。金床氏に謝罪いたします。また、これらのコメントを読んでいただいた方にも、申し訳ありません。

        それで、現状はというと、僕は金床氏の主張が何であったか、よく理解できていない、ということになってしまいました。すみません。さらに、既に公開を停止された文章の主張が何であったかを今更検証することにあまり価値を見出せません。新バージョンを書かれるかもしれないとのことなので、それが公開された後で時間があったら、何かコメントするかもしれません。
        --
        鵜呑みにしてみる?
        親コメント
        • 今回、
          ・技術的にすべきこと
          ・技術論
          の二つが語られていると思います。

          セッションIDを使う技術屋としては
          ・A案が危険という人が提案したB案
          ・B案もA案も同じだ
          という二つの意見が合った場合、
          ・B案はむしろ危険
          ・B案は高コスト
          とかでない限り、B案をとりたいと思うのです。

          通常、ワンタイムトークンを作るなら言語に備え付けのセッションIDを用いて実装すると思うのですが、違うのでしょうか?
          なので、
          ・ログイン中変わらないセッションID
          ・作業ごとに変わるセッションID
          の二つを使用せよ、という事だと理解しているのですが。

          どうせひとつの手法では解決できない(パスワードの変更には旧パスワードを入れたり堅めに作る)ので、今技術屋さんは何をすべきなのか、というのを誰か教えてもらえないでしょうか?

          CSSXSSとCSRFを分けて考えるべきとかは、現場的な対応ではないかと。

          お仕事関係なのでACにさせてください。
          • 今更書いても、もう読んでいないかもしれませんが……。
            セッションIDを使う技術屋
            との表現から、ウェブサイトの開発に関わる技術者のかたと判断し、その前提で書きます。

            僕は開発経験がほとんどありませんし、その他の考察も足りないので、あなたの疑問には答えられません。

            ただ、興味深いと思ったのは、お仕事としてウェブサイトに関わっている人と、ウェブサイトの開発の経験がほとんどない僕のような者とでは、やっぱり問題意識というか興味の対象が違うのだなあ、という点です (当然といえば当然ですが)。

            僕の興味の対象はセキュリティの問題そのものであって、例えば今回の問題に関連する疑問は次のようになります。
            • CSSXSS 問題とはどういう問題であって、どういうセキュリティ上の影響があって、どういう対策ができるのか。
            • CSRF 攻撃の本質は何で、対策するには何が必要なのか。
            • 今回初めて考えた問題: CSSXSS 問題対策と CSRF 攻撃対策を別々に施せば両方の対策になるのか、それだけでは駄目なのか。
            で、今回一番重要なのはこの3番目だと思っているわけです。

            それに対し、
            CSSXSSとCSRFを分けて考えるべきとかは、現場的な対応ではないかと。
            というのは半分頷けます。

            上のような疑問に対して、調べたり考えたりして答えを見つけていっても、直接的に開発の現場の役には立たないかもしれません。結局のところ、金床氏の「正しい対策その1」が安全性の面でもそれ以外の面でも満足いくものなら (実際、このストーリーに対するコメントをざっと見たところでは、金床案の安全性に疑問を投げかけている人はいないようです)、「高木案+リクエスト1を POST に」が安全か危険かなんて検討する必要はないわけですし。

            (例えばの話、僕がウェブサイトの開発をどこかの会社に依頼したとして、ある問題に対して全面的に満足いく方法があるのに、「それ以外の方法でもいいかどうか」を延々と検討されたら、たぶん怒ります。)

            でも、上のような疑問について考えることは、安全な対処法を自分で考えたり、人が提案する対処法の安全性を検討したりするときに役に立つと思います。安全性について、開発の現場で自分で対処法を考えなければならない状況がどの程度あるかはわからないのですが、開発の現場でこういうことを考えることも、何かの役には立つのではないか、と期待するのですが。
            --
            鵜呑みにしてみる?
            親コメント
          • 現場的対応としてCSSXSSを防がないとなると、
            CSRF以前にCSSXSSの危険回避のために、
            見られてはまずいページは全部POSTにしないといけません。そこはオーケー?

            で、全部POSTにしたならCSRF対策用のキーは何でもよい
            わけです。漏れませんから。
            これでわかりましたか?

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

処理中...