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

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

  • by Anonymous Coward on 2006年04月03日 11時19分 (#914146)
    CSS脆弱性界隈の人たちはどうして定量的なリスク評価しないんでしょうか。算出は損害額×確率で、相対値でもいいからさ。量は間違っていても、少なくとも量の正当性について意味ある議論ができる。
    定性的な話だと、声の大きい方、小難しいクラック法より分かりやすい方が勝っちゃいます。そして反論は人格攻撃で却下される(つーか名誉毀損ちらつかされてる。なんて未熟な業界だ)。

    特に金床氏はセッション鍵を hidden に入れる潜在的リスクを言いたいようだから、CSSXSS なんて出さずともそういう攻め方でできるはずなのに。

    CSRF によるリスクは、単一アクションを実行されちゃうくらいで、最悪でもアカウント消される程度。ただし実行は手軽で発生可能性は高い。1円×100%としましょうか。

    対して hidden にセッションを入れることによる潜在的リスクは、セッションを乗っ取られること。現実的に金銭的被害が起こりうる。ただし(CSSXSS以前なら)発生可能性は未知のバグ利用なので低い。100万円×0.1%くらいか。

    hidden にセッション鍵を入れるような対策は間違っていると言えるはず。
    • by Anonymous Coward
      CSRF によるリスクは、単一アクションを実行されちゃうくらいで、最悪でもアカウント消される程度。
      CSRF で金銭被害を出せるサイトもありますよ。その場合は 100万円×100% ですね。
      hidden にセッション鍵を入れるような対策は間違っていると言えるはず。
      とりあえずこんなずさんな理論では言えませんね。
      • by Anonymous Coward
        > CSRF で金銭被害を出せるサイトもありますよ。
        また定性的な反論。
        セッション乗っ取られて金銭的被害が出るサイトと同じくらいあるのかどうかを言わない。

        >> hidden にセッション鍵を入れるような対策は間違っていると言えるはず。
        >とりあえずこんなずさんな理論では言えませんね。

        そうですね。杜撰であることは認めます。
        でも言いたいのは定量的な話をしようということですよ。そこスルーしないでね。

        • by Anonymous Coward
          > > CSRF で金銭被害を出せるサイトもありますよ。
          > また定性的な反論。
          > セッション乗っ取られて金銭的被害が出るサイトと同じ
          > くらいあるのかどうかを言わない。

          よく考えてみると同じですね。
          セッションハイジャックで金銭被害が出る画面のすべては、
          CSRFによっても同じ被害が出せる。(必要なCSRF対策が無効な状態になっているとき)
    • by Anonymous Coward
      被害額を出すと難しくなるので、こうしてはどうでしょうか。

      Cookieが漏洩する確率 (A)
      hiddenパラメータが漏洩する確率 (B)

      両者がほぼ同じか、A > B ならば、「hidden にセッション鍵を入れるような対策は間違っている」は間違いだと結論付けられます。
      • by grep (21372) on 2006年04月03日 13時34分 (#914252) 日記
        hiddenは見られるのが当たり前な情報だと思います。
        A>Bになることなんてあるんでしょうか?
        親コメント
        • まず、大元のコメントについてですが、hiddenにセッション(ID)を入れていて、それが漏れるだけでセッションハイジャック可能なつくりになっているサイトは、クッキーにセッションIDを入れたとしても、それが漏れれば同じようにセッションハイジャック可能だと思います。セッションIDは最低限クライアントのIPアドレスぐらいとは紐付けしておいて、安易なハイジャックの可能性は排除するものなんじゃないでしょうか。そういう意味ではセッションを乗っ取られる危険性についてはどっちもどっちだと私は理解しています。

          クッキーのほうがより堅牢なサイトを作れると言う情報があったら認識を改めますので、ぜひ教えてください。(無いだろうという皮肉ではなく、これまで作ってきたものや、これから作るであろうものに対する責任とか考えると結構切実なので。)

          で、将来の可能性は置いておいたとしても、現状hiddenフィールドの値とクッキーの見られやすさというのは「両者はほぼ同じ」じゃないでしょうか。

          ・盗聴
          hidden
          httpは双方向,httpsは無理
          クッキー
          httpはクライアント→サーバ方向,httpsは無理(secureフラグ指定時)
          ・Man in the middle
          hidden
          http,httpsによらず横取り可能
          クッキー
          http,httpsによらず横取り可能
          ・キャッシュ
          hidden
          残る(no-cache(expireも?)で回避)。
          クッキー
          残る(有効期限で回避)。
          ・ブラウザで開いているページ
          hidden
          ソースの表示
          クッキー
          javascript:document.cookie;
          ・(おまけ)偽造
          hidden
          HTMLのソースを書き換えてリクエスト送信
          クッキー
          セットしてリクエスト送信

          httpの盗聴については2倍の確率だという主張はできますが、通信のタイミングと流れを考慮に入れれば、その主張にあまり意味が無いことは理解していただけるかと。

          蛇足ですが、A>Bとなるのは、httpsなページでクッキーを利用していてsecureフラグをつけていない場合、でしょうか。

          ---
          hidden信者ではないが、クライアントに「hidden禁止」と言われると非常に困る

          親コメント
          • 蛇足ですが、A>Bとなるのは、httpsなページでクッキーを利用していてsecureフラグをつけていない場合、でしょうか。
            元の話題の A > B というのは、他の脆弱性が原因となって漏れる確率のことでしょう。(#914399 に書かれているのは脆弱性がないことを前提とした場合ですね。)
        • by Anonymous Coward
           Cookieも他のページから取得できる仕様だとしてもおかしくなかったわけですが、まあ、色々あってアドホックな情報になってますよね。
           Cookieの場合、HTMLというわけではないので、違う処理に分離しやすいので、対処も管理も比較的楽なのかもしれませんね。
           反面、hiddenはHTMLの中にありますので、なんらかの原因で読み取ることも、比較的起き易いと言えるのかもしれません。実装もかなり注意しないと。実際、今回のも仕様に絡むバグですし、せめてこの機能だけでもオフできるようになっていれば・・・。

           よく、Cookieだって漏洩するだろうという反論を見かけます
        • by Anonymous Coward
          > hiddenは見られるのが当たり前な情報だと思います。

          Cookie も見られるのが当たり前な情報ですよ。ご存じないのでしょうか。そういう認識で Cookie を使うのは危険ですね。

          > A>Bになることなんてあるんでしょうか?

          Cookie は漏洩するが hidden は漏洩しないという脆弱性は過去に何度もありましたね。IE にもあったし、Netscape にもあった。

アレゲは一日にしてならず -- アレゲ研究家

処理中...