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

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

  • 金床氏の提案する対策(「正しい対策その1: ワンタイムトークンを正しく使用する方法」)は、主に次の二つから成ります。リクエスト1とかレスポンス1とかの意味は 金床さんのページ [jumperz.net]を参照してください。
    1. リクエスト1を POST にする(リクエスト1がGETだったらサーバーはエラー等を返すようにする)
    2. ワンタイムトークンを使用する。詳しくは、 (a) 処理1でワンタイムトークンを生成する。 (b) レスポンス1に含まれるフォームにトークンを hidden フィールドとして追加する。 (c) 処理2では本来の処理(日記にデータを追加する等)の前に、 cookie として送られてきたセッション ID と hidden フィ
    --
    鵜呑みにしてみる?
    • by Anonymous Coward on 2006年04月03日 2時07分 (#914010)
      > であれば、高木氏の提案する対策に加えてさらにリクエスト1を POST 専用にすれば、今問題になっている CSRF 攻撃対策と CSSXSS 問題対策はできているように思います。僕は何か見落としているんでしょうか。

      それで、CSRF と CSSXSS は防げます。
      ただし、対策を行わなかった場合には、Cookieに保存されている
      セッションIDはCookie以外には保存されることはありません。
      しかし、貴方の言うセキュリティ対策を行うと、
      HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。

      これが万が一漏洩したらセッションハイジャックの危険があります。
      (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)

      冷静に考えてみて下さい。
      SCRF対策、CSSXSS対策を行ったことにより、
      他のセキュリティホールが生じる可能性が高まる状況は好ましいと言えますか?

      親コメント
      • >しかし、貴方の言うセキュリティ対策を行うと、
        >HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。
        >(他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)

        他の脆弱性?それを言うなら、クッキーにセッションIDを入れる方がよっぽど危ないですから、hiddenにセッションIDを入れるべきです。

        「hiddenは漏れるがクッキーは漏れない」なんて脆弱性、CSSXSS以外に聞いたことがありませんし。
        • Cookieを使わずにPOSTメソッドのhiddenでセッション管理をしている会員制のWebサイトであれば、CSRF及びCSSXSSの影響は受けません。

          金床氏の提案する「正しい対策その1: ワンタイムトークンを正しく使用する方法」もCookieでセッション管理することを前提で書かれていました。

          「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、 後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。

          親コメント
          • 「セッションIDをCookieに入れる」のと「セッションIDをCookie及びhiddenに入れる」のでは、後者の方がセキュリティ上のリスクは高いのでは無いでしょうか。
            前提は何ですか?
            クライアント側に脆弱性がないなら、リスクは同じでしょう。
            • 前提条件が抜けていました。
              大変失礼しました。

              前提は、ブラウザの脆弱性、プロキシのキャッシュ、第三者のコンピュータの利用なども考えられる、現実社会の環境です。
              親コメント
              • 前提は、ブラウザの脆弱性、プロキシのキャッシュ、第三者のコンピュータの利用なども考えられる、現実社会の環境です。
                そのようなもののすべてを前提とするなら、どうやっても危険なので、リスクは同一ですね。(∞=∞)
      • (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
        プロキシサーバのキャッシュにはSet-Cookieも残りますよ。
        PCの共有でCookieが漏れないとでも?
        • >プロキシサーバのキャッシュにはSet-Cookieも残ります
          LANでシビアな情報をやり取りするのは、パケット傍受される危険性があるよレベルの話。
          ここでいうCSRF対策とは既に別次元の話だから、そういう可能性(他のブラウザ以下)
          は考慮しないで済むので問題ありません、という事では?

          話題がセキュリティ一般であるなら、考慮しないでよい理由は無いだろうけど。
          • しかし、貴方の言うセキュリティ対策を行うと、 HTML内のhiddenフィールドにセッションIDが埋め込まれることになるわけです。
            これが万が一漏洩したらセッションハイジャックの危険があります。 (他のブラウザのセキュリティホールやプロキシサーバのキャッシュ、PCの共有などが無ければ問題ありませんがね。)
            プロキシサーバのキャッシュにはSet-Cookieも残りますよ。
            LANでシビアな情報をやり取りするのは、パケット傍受される危険性があるよレベルの話。ここでいうCSRF対策とは既に別次元の話だから、そういう可能性(他のブラウザ以下) は考慮しないで済むので問題ありません、という事では?
            話がかみ合っていませんね。
            「Cookieは漏洩しないがhiddenフィールドは漏れる」という想定が間違いという話でしょう。
      • >それで、CSRF と CSSXSS は防げます。
        そうすると金床氏の「高木方式ではCSRF対策になっていない」という主張は間違いですよね。
        >これが万が一漏洩したらセッションハイジャックの危険が
        >あります。
        それは「CSRF対策・CSSXSS対策」とは別の話ですよね。 批判するにしても、あくまで別の話として批判するべきですよね。

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...