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

正しいCSRF対策、してますか？ More

「正しい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]」での「簡潔な対策方法」はワンタイムトークンを使わないものでしたが、金床氏は、主要なブラウザであ
      --
      鵜呑みにしてみる？
      • とあるところで金床氏のページが残っているのを見つけたので読み返しました。すると、僕は根本的なところで金床氏のページを読み間違えていることがわかりました。
        • 金床氏は、ワンタイムトークンを使わずにセッション ID を使う方法の欠点を説明していた。
        • 金床氏は高木氏の対策でリクエスト1を POST にしたものについて言及しており、この方法で CSSXSS 問題には対策できている (ただし上の欠点があるため推奨しない) ことを述べていた。

        公開停止された文章なので引用しませんが、どちらも、「誤った対策その1: セッションIDをトークンとして使う」の最後2個の段落に書かれていました。

        この読み間違いの結果、#913853 [srad.jp]と

        --
        鵜呑みにしてみる？
        • 今回、
          ・技術的にすべきこと
          ・技術論
          の二つが語られていると思います。

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

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

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

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

          お仕事関係なのでACにさせてください。

吾輩はリファレンスである。名前はまだ無い -- perlの中の人