パスワードを忘れた? アカウント作成
12192 story

正しいCSRF対策、してますか? 134

ストーリー by mhatta
正しいのはどちら? 部門より

あるAnonymous Coward曰く、"最近WebアプリのCSRF脆弱性への対策が注目されていますが、30日に金床氏が「開発者のための正しいCSRF対策」という秀逸なテキストを発表してくれました。 Googleで「CSRF 対策」で検索すると高木浩光氏の「クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法」がトップに出てきますが、金床氏によると、この方法は誤った対策であり「CSSXSS脆弱性が知られている現在では、絶対に実施すべきでないもの」とのことです。この対策は、IPAの「情報セキュリティ白書2006年版」や「用語「CSRF」@鳩丸ぐろっさり (用語集)」ほか書籍などにも書かれており、金床氏は「記事の内容を訂正していただきたい」としています。スラドの開発者のみなさんはきちんと正しいCSRF対策をしていますか?"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2006年04月02日 10時46分 (#913760)
    いまいちはっきりわからないのですが、ここ [hatena.ne.jp]に、Microsoftに問い合わせた?人が得た?Microsoftの見解?らしきものがあります。
    有用な情報を適切な方法でご連絡いただき大変感謝いたしておりますが、Web サイト側での対応が困難である事が判明し、また、Internet Explorer の脆弱性が近々対応できる見込みであるため、Internet Explorer の修正により、この問題に対応する方向で作業を進めております。
    (snip)
    また、この問題の根幹となります Internet Explorer の脆弱性については、現在鋭意対応中でございますが、こちらのリリース時期につきましては、詳細をお伝えすることができません。
    誠に申し訳ございませんが、何卒ご理解とお客様の保護にご協力の程よろしく お願いいたします。
    • by Anonymous Coward on 2006年04月02日 12時02分 (#913784)
      hoshikuzu star_dust と申します。

      > ここに、 Microsoft に問い合わせた?人が得た?

      お取り上げ頂いた件は、 Microsoft さんからの意思表示で間違いありません。いわゆる CSSXSS 脆弱性に関しては、 Internet Explorer へのセキュリティ修正プログラムが提供されるであろうと思われます。

      親コメント
  • by Anonymous Coward on 2006年04月02日 11時18分 (#913771)
    ええと、こちらのリンクも同時に示さないと公平さに欠けるんじゃないですかねえ…
    http://www.oiwa.jp/~yutaka/tdiary/20060330.html

    セキュリティ関係に興味のある人なら、当然大岩さんのページは常時チェックしてると思ってたんですが、そうでもないのかな? > タレコんだ人
  • by ef (25263) on 2006年04月02日 10時34分 (#913755)
    セッション管理に(クライアントサイドの) JavaScript を使うようです。また私には金床氏の対策にはセッション管理のために Cookie を有効にすることも必須だと思えます。
    「JavaScript を有効にしてください。
    また Cookie も有効にしてください。」
    をクライアントに強制する事は、CSSXSS 脆弱性を悪用される危険性と比較してもリスクが小さいとは思えません。
    • 件の文書で示されている、JavaScriptが必要になるケースは、
      リクエスト1にGETメソッドを使いたい場合の対処法で、
      POSTメソッドを使う限りJavaScriptは不要だと思います。
      親コメント
      • by ef (25263) on 2006年04月02日 13時03分 (#913798)
        POSTメソッドを使う限りJavaScriptは不要
        その通りだと思いますが、セッションを全て POST で開始するということは FORM の SUBMIT で行われる事になります。
        ここ [srad.jp]の[返事を書く]が全部 SUBMIT なボタンになっている様子
        を想像してみてください。
        新たにサイトを構築するような場合でも、これは困難を伴うと思います。

        また JavaScript で自動POSTさせる方法を併用されると(いくつもの条件が必要ですが) CSSXSS 脆弱性の悪用の道が開けるので、POST を使えだけでは十分ではありません。

        親コメント
    • 高木さんのとこへの主張も混ぜて考えると
      Cookieを使わないセッション管理は
      "CSSXSSを前提とする場合"
      セッションハイジャックされる可能性があるからそもそも(以下略
      ってことになるのでは。
      親コメント
  • by tix (7637) on 2006年04月02日 18時54分 (#913853) ホームページ
    金床氏の提案する対策(「正しい対策その1: ワンタイムトークンを正しく使用する方法」)は、主に次の二つから成ります。リクエスト1とかレスポンス1とかの意味は金床さんのページ [jumperz.net]を参照してください。
    1. リクエスト1を POST にする(リクエスト1がGETだったらサーバーはエラー等を返すようにする)
    2. ワンタイムトークンを使用する。詳しくは、 (a) 処理1でワンタイムトークンを生成する。 (b) レスポンス1に含まれるフォームにトークンを hidden フィールドとして追加する。 (c) 処理2では本来の処理(日記にデータを追加する等)の前に、 cookie として送られてきたセッション ID と hidden フィールドとして送られてきたトークンの組み合わせが正当であることを確認する
    1は CSSXSS 脆弱性の悪用を防ぐために必要です。金床氏自身も
    まず、アプリケーションの作りとして、リクエスト1が必ずPOSTを用いるような形にする。これによってCSSXSS脆弱性を利用したhiddenフィールドの情報の抜き取りを防ぐことができる。
    と書いています。しかし、2はどうして必要なのか、金床氏は説明していないように思いました。少なくとも僕には理解できませんでした。

    高木氏は、
    • (a) レスポンス1に含まれるフォームにセッション ID を hidden フィールドとして追加する。 (b) 処理2では本来の処理の前に、クッキーとして送られてきたセッション ID と hidden フィールドとして送られてきたセッション ID が一致してかつ正当であることを確認する
    ということを提案しました。このままでは、(「リクエスト1の方法によっては」という留保が必要だと思いますが) CSSXSS 問題のせいで危険である、というのが金床氏のページの要点だと思います。であれば、高木氏の提案する対策に加えてさらにリクエスト1を POST 専用にすれば、今問題になっている CSRF 攻撃対策と CSSXSS 問題対策はできているように思います。僕は何か見落としているんでしょうか。

    (efさんのコメント [srad.jp]に POST であっても CSSXSS 問題が悪用できる場合があると書かれていて、それを僕は理解できていないので、何か見落としがあるとしたらその辺りではないかと睨んでいますが……。)
    --
    鵜呑みにしてみる?
    • 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対策を行ったことにより、
      他のセキュリティホールが生じる可能性が高まる状況は好ましいと言えますか?

      親コメント
    • たぶん、同じセッションIDを含んでいる他のページをGETで取得できる場合、そのセッションIDは容易に類推可能なものになってしまうからじゃないでしょうか。

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

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

      親コメント
  • 結局これって何?
    技術的議論では勝てないので、
    アイデンティティを守るために名誉毀損なんてくだらん文系的世間体の問題を取ったって事?
    それとも、間違いと指摘した側が間違ってて、名誉毀損怖いですって尻尾を巻いて逃げたのか?

    なんかさっぱり意味分からんのだが、、、
    そもそも、技術的に間違ってりゃ、
    それを公表し続けてる事そのものが不名誉なんだから、
    如何なる指摘も名誉毀損になり得ないわけで、、、
    逆に指摘が間違いなら、その指摘してる奴が不名誉であるわけだから、
    技術的視点で見れば、名誉毀損なんて事が存在する事が信じられない、、、
    # 結局、技術的問題において不名誉は自分で自分に付けているのだ。

    だいたい俺の個人的感覚だと、どちらにしても、
    技術的な問題を技術的な議論で決着できない上、
    名誉毀損なんて持ち出して、技術的な議論を放棄するような奴は最低の人種だぜ、、、って感じなんだがなぁ、、、
    そもそも技術者倫理ってもんがねぇよ、、、それって、、、
    間違ってる方が、勉強して出直して来い!って一喝されて終わってりゃいいじゃん、、、
    技術的に間違ってるんなら、名誉なんて糞にもならんのだよ、、、
    つぅか、それは虚栄心だよ、、、それ、、、
    --
    uxi
  • by Anonymous Coward on 2006年04月02日 7時17分 (#913722)
    素人のおれでも解る。
    この対策はまるでデタラメ。
    だって「2006年4月01日 Version 1.1」だもん。
    だ、騙されないぞ?!

    #どうみてもそういうネタじゃありません、本当に(ry
  • C か X か (スコア:1, 興味深い)

    by Anonymous Coward on 2006年04月02日 7時45分 (#913724)
    「クロスサイト」は「C」で始まるのか「X」で始まるのか。
    「CSRF」と「XSS」で両方とも「クロスサイト〜〜」と読むのが、どうも釈然としません。
    • Re:C か X か (スコア:2, 参考になる)

      by Anonymous Coward on 2006年04月02日 8時03分 (#913729)
      XSSについては、CSSとの誤解を避けるためにXSSという呼称を考えたと聞いています。
      親コメント
  • by hirata (3986) on 2006年04月02日 8時28分 (#913733)

    できるだけCookie使いたくないんだけどね。

    1. 基本的に hidden フィールドにトークンを置く
    2. IE 対策には Referer を見る
    3. 知らないメールのリンクを踏むのはCSRF以前

    ってのはダメなのかな。

    • by Anonymous Coward on 2006年04月02日 11時07分 (#913767)
      投稿者の意図とは視点がずれますが、

        知らないメールのリンクを踏むのはCSRF以前

      人間というものは間違いを犯すものであり、技術はそういうものを
      *なるべく* 前提として考えるものだと思います。なにか最近の
      「自己責任」大流行の風潮の中なのか、間違いを技術で救えるかの
      検討がおろそかになっていきつつあるように感じてます。

      「知らないメールのリンクを踏む」のを除外すれば、知っている人が
      だまされたりして送ってくるメールにも無防備になって、そういう
      対策自体の効力に疑問が生じます。
      親コメント
    • よく読んでみたらCookie要らんかも。失礼しました。

      出直してくる。

      親コメント
    • Cookieを使いたくないということですが、どういった形態のサイトについての話なんでしょうか?

      もし、ログインが必要な会員制のサイトならば、セッションIDやパスワードなどの識別情報を、URLに含めて渡すかPOSTメソッドで送信していることになります。

      そういった方式での管理ならば、セッション情報を確認していないページがあるなどの脆弱性が無い限り、そもそも、CSRF及びCSSXSS攻撃は受けません。
      なぜならば、攻撃者は識別情報を予測することができないからです。

      親コメント
  • 高木さんは (スコア:1, 興味深い)

    by Anonymous Coward on 2006年04月02日 9時54分 (#913747)
    CSSXSSはブラウザ側で対処すべきというスタンスだったと思います。
    • by Anonymous Coward on 2006年04月02日 10時40分 (#913758)
      で、金床さんは、ブラウザ市場の9割を占めるIEに関して

      ・・・これは深刻なバグであるにも関わらずパッチがリリースされておらず、2006年3月の時点で既に数ヶ月もの間脆弱なままの状態が続いている・・・

      なので、ちょっとその姿勢を改めたほうが良いのでは?と提言しているわけです
      親コメント
      • Re:高木さんは (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2006年04月02日 10時59分 (#913763)
         でも、それで本当にいいわけ?

         すべてのサービスが対応するなんてあり得ないし、対処したらしたで、「実質的な脅威は軽微」とか言い訳できてしまうでしょう。
         一般人はそれで納得するでしょうから、あとでネットの片隅でピーチクパーチク薀蓄をたれたところで意味はないでしょう。

         正論としては、パッチのリリースを要求するというのは誰だって分かってることです。
         金床氏が違った意見を持つのも分かりますし、その為の有用な情報を提供してくれるのはありがたいことです。

         しかしながら、他人の著作物にまでにまで修正を要求するのは行き過ぎでしょう。間違いの指摘部分については正しいのでしょうが・・・。

        #Javascript+Cookieを強制するのと、IEを使うなというのではあんまり大差ない気もするが・・・。
        親コメント
        • by Anonymous Coward on 2006年04月02日 11時16分 (#913770)
          正論としては、パッチのリリースを要求するというのは誰だって分かってることです。
          金床氏が違った意見を持つのも分かりますし、その為の有用な情報を提供してくれるのはありがたいことです。
          しかしながら、他人の著作物にまでにまで修正を要求するのは行き過ぎでしょう。間違いの指摘部分については正しいのでしょうが・・・。
          私もそう思いますが、「間違いの指摘部分が正しい」というのは正しくないでしょう。「間違い」ではありませんから。

          あらゆる議論には暗黙の前提がつきもので、議論の正否はその前提の上で正しいか間違いであるかで論ずるべきです。
          前提が妥当でないならば、前提が妥当でないことを論ずるべきです。

          親コメント
        • Re:高木さんは (スコア:2, すばらしい洞察)

          by targz (14071) on 2006年04月02日 11時07分 (#913766) 日記
          >Javascript+Cookieを強制するのと、IEを使うなというのではあんまり大差ない気もするが・・・。

          /.J を読み書きするような人なら大差ないと思いますが、そうではない一般人だと違うと思います。前者は OS デフォルトで有効にされていますが、後者は他のブラウザをインストールさせる必要がありますから。

          親コメント
        • Re:高木さんは (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年04月02日 12時07分 (#913788)
          > しかしながら、他人の著作物にまでにまで修正を要求するのは行き過ぎでしょう。

          拒めば済む(あるいは拒む必要すら無い)ことだから、行き過ぎとは思わないな。
          親コメント
  • by Anonymous Coward on 2006年04月02日 11時44分 (#913780)
    って、CSSXSS脆弱性ってのがIE7で直ってるのか知らないけど。

    #金床氏のは読みづらかったので全部読んでません
    • by Anonymous Coward on 2006年04月02日 13時59分 (#913807)
      手もとで試した限りは直っている気がします。
      Internet Optionの "Open file based on content, not file extension"(日本語版IE6 on WinXP SP2では"拡張子ではなく、内容によってファイルを開くこと") が影響するのかと思っていじってみましたけど、Enabled, Disabledどちらでも影響はないようでした。
      親コメント
  • by kgw (29702) on 2006年04月02日 15時21分 (#913820)
    よく分かってないのですが、ごく単純にCSRFの他にCSSXSSという脅威が存在する、という理解ではダメですか?
    • CSRFへの対策は論理的にコレコレこういう対策。
    • CSSXSSへの対策はこういう対策です。
    そういう形で理解していいのなら一般の開発者にも説明しやすいと思うのですが…。
  • by Anonymous Coward on 2006年04月02日 16時02分 (#913829)
    この方式は日本語圏独自のもの(おそらく高木氏の案を元に国内で広がっているもの)であり、英語圏ではこの方式をCSRF対策としている記述は見つからなかった。

    その通り。オープンソースに限らずセキュリティでも日本はガラパゴス諸島化しているんです、とか書くとまた叩かれるのかな。基本的に彼の書いているのは、日本以外でよく見かけるドキュメントと基本的にかわりませんが、有用であることは確かであり、いずれにしてもよく調べていると思います。

    • by Anonymous Coward on 2006年04月02日 16時16分 (#913832)
      嘘ばっかり。

      CSRF が最初に Bugtraq に出たときから sessionid を POST に入れる話は出てましたよ。

      The Dangers of Allowing Users to Post Images (Cross-Site Request Forgeries) 17 Jun. 2001 [securiteam.com]

      How can it be fixed? Well, there are a couple of ways to stop it, but the easiest (in PHP at least) seems to be to have most of the variables used by scripts be used through $HTTP_POST_VARS. So instead of checking for $action in a script, $HTTP_POST_VARS['action'] would be checked. This forces the user to use a POST request, not a GET. Alternatively, the sessionid could be required to come with the GET/POST request variables, rather than by cookie. Finally, in the specific case of [img] tags, the use of ? or & in the img URL can be disabled by some regexes.
      親コメント
  • by Anonymous Coward on 2006年04月02日 17時16分 (#913843)
    挙げておきます。

    いしなお! - なぜCSSXSSに抜本的に対策をとることが難しいか [ishinao.net]

    その答えとしては、ある特定された状況における問題を回避するように修正することは可能であろう。しかし、CSSXSSという問題に対して、抜本的な対策をサーバーサイドのみで行うことは、現在のWebアプリケーションの設計手法を根本から変えない限りは、不可能だ。

    ・・・・

    どちらにしろ、これらの対策は従来のWebアプリケーション設計手法とは異なる方法でWebサイト(アプリケーション)を再構築する必要があり、またブラウザ互換性も損ねてしまう。あるいはブラウザ互換性の代わりにユーザビリティを大幅に下げることになる。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...