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

複数のWikiクローンのファイル添付機能にXSSな脆弱性」記事へのコメント

  • タレコミのリンク先
    http://jvn.jp/jp/JVN%23465742E4/index.html
    のベンダ情報みると、AsWikiやHikiは「該当製品なし」と書いてありますが、この2つには脆弱性はないということなんじゃないですか?
    • by to (16347) on 2005年05月19日 17時32分 (#737470)
      Hiki の JVN#465742E4 への対応
      http://jvn.jp/jp/JVN%23465742E4/270028/index.html
      には、
            2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。
      となっています。
      親コメント
    • by temple_craft (13186) on 2005年05月19日 17時36分 (#737471)
      よく読むと「該当製品なし」=「脆弱性なし」、ではなく、現在は対策済みという意味なんでしょうか。Hikiは
      「2005/05/17 にリリースした Hiki 0.6.6 ならびに Hiki 0.8.0 preview1 にて修正しました。」
      とありますし。

      読み方が甘くてすみません...
      親コメント
      • 「JVNの読み方」の「ベンダ情報 [jvn.jp]」を見ると、
        > 該当製品なし 脆弱性該当製品がない場合
        となっていて、「脆弱性なし」としか読み取れないです、自分は。

        「脆弱性あり・対応済み製品あり」とかってステータスがあるべきなんじゃないかなあ。
        # 自分はyukiwikiを使ってるんだけど、これも今回の脆弱性には無関係のようで。
        親コメント
    • #コメント書いてるうちに他の人にフォロー書かれたので省略ですが、

      「該当製品なし」ですっとばしていました。ちゃんと確認しないといかんですね。
      親コメント
    • AsWikiは
      attach pluginを利用したときに、危険なファイルを添付されて危険だという指摘を頂いてますが、それはそういうものです。デフォルトで使用してませんので、自分でリスクを理解して設定して下さい。開発側でチェックコードを入れるとかはしません。
      という態度。なんだかなー。
      Hikiも自サイトでは脆弱性に関する報告を目立つようにあげていないし、結構対応に差があるよな。
      親コメント
      • 態度はともかく、対応としてはそういうものじゃないでしょうか。
        「ユーザーからファイルをアップロードできる」ようにするからには、こういう危険性を回避する方法はまったくないかと思います。

        たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性 [srad.jp]による危険はあるわけですよね。

        Wikiもどきの対応 [moonrock.jp]:
         A.添付機能を無効に
         B.アップロード元ホスト・ファイル名・Content-Type に基づく添付可否条件が設定可能

        PukiWiki [pukiwiki.org]:
         回避策(1) 全体をリードオンリーに
         回避策(2) 管理者だけが添付ファイルのアップロードができるように
         回避策(3)(4) 添付ファイルのアップロードができないように

        どちらも、根本的な解決じゃないですよね。

        WikiもどきのBはまともそうに見えますが、
        Internet Explorer の「拡張子もContent-Typeも無視してデータの内容を元にどうやって表示するかを決める」という困った仕様の
        前には無力だと思います。
        親コメント
        • WikiもどきのBは添付ファイルの表示時ではなくて、添付ファイルをアップロードする際の制限です。すでにアップロードされたものに対しては制限していません。

          表示については次の版で、Hikiと同じようにContent-Depositionヘッダフィールドによる対処を行う予定です。ただ、これって全てのブラウザで有効なのかしりませんので効果も今イチ把握出来てません。
          --
          DON
          親コメント
        • > たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性による危険はあるわけですよね。

          さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様+ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。

          Wikiもどきの(B)が対策になっていない、というIEの仕様は非常に問題だと思うんですが、現状ではこれはWiki側がなんとかしないとまずいでしょうねぇ。

          あと、AsWiki の態度は個人的には開き直りに見えて妥当ではないと感じています。これが「該当製品なし」に分類されてしまう JVN の分類も問題ですが。
          親コメント
          • by Anonymous Coward on 2005年05月19日 19時52分 (#737516)
            さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様+ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。
            いつのまにXSSがブラウザの仕様になったのでしょうか?

            今回の問題は、通常の掲示板であれば、管理者以外は画像やテキストなどしか書き込みできないのが、Wiki等の添付ファイルのアップロード機能があるものではブラウザのXSS脆弱性を攻撃するファイルをアップロードできてしまう。
            だからマズいんじゃない?
            という話で、Wikiの仕様がトリガーとなってブラウザの脆弱性が現出するのですからJPEGファイルの問題と形としては一緒です。

            あとは、その「Wikiの仕様」が妥当かどうかという話になる訳で・・・
            ブラウザの脆弱性を攻撃するファイルのアップロードは全て「妥当な仕様ではない」と断ずるのであれば、JPEGファイルがアップロードできる掲示板なども全部「妥当な仕様ではない」という事になっちゃいますし。

            親コメント

            • 今回の問題は、……だからマズいんじゃない? という話で


              だから違うんだってばさ。今回の件に関して言えば、攻撃されたブラウザのXSS脆弱性というものはそもそも存在しません。

              # スクリプトに絡むブラウザのバグで、XSSと似たような結果を生むものはありましたけど、今回の件とは別件です。

              XSS攻撃は、バグのある Web アプリケーション (今回の場合 Wiki サーバのソフト) に怪しげなデータを送りつけて、偽物のスクリプトをあたかも本物の Web アプリケーションの出力した JavaScript のように見せかけて Web ページに埋め込んでやるという攻撃です。ブラウザが受信した HTML ファイルを見ると、どちらも本物のスクリプトのように見えます。本物に見える以上、基本的にはブラウザは言われた通りに(スクリプトに許される権限の範囲で)実行するのが仕様に沿った「正しい」動作です。最初にブラウザに脆弱性があって、それを攻撃する、というシナリオではそもそもないのです。
              # 逆に言えば、本物のスクリプトがやろうとしてもできないこと(いきなりローカルディスクのファイルを勝手に送信しちゃうとか)は XSS 脆弱性だけを使っても実現できません。できたらそれは「ブラウザのバグ」ですね。

              一方で JPEG のバグは、画像を表示しろとだけ指示されそれを受け入れたブラウザが、なぜかメモリ内容をブッ壊してわけのわからん機械語の実行を始めてしまうというバグですので、ブラウザの問題です。

              誰も今ウィルス入りのソフトを実行してデータ盗まれたからって、ウィルスを実行する Intel/AMD の CPU はケシカラン、とは普通言いませんよね。だってウィルス入りソフトのコードは機械語としては悪い事するのが「正しい動作」なんですから、Intel/AMD の CPU にとっては言われた通りのことを忠実に僕として実行しただけで、基本的にはそこを責められても困ります。XSS とブラウザの関係も基本的にそれと同じことです。

              #『基本的には』と書くからにはもうちょっと厳密な話をしないといけない点があるんですが、それはまた今度……。
              親コメント
              • >XSS攻撃は、(以下略)

                それは管理者が意図しないJavaScriptが埋め込めるというだけで、全然クロスサイトしてません。
                JavaScriptに関する問題を何でもかんでもXSSというのはバカみたいですからやめましょう。

                # バカみたいなだけでなく、問題の本質をわかりにくくする。

                管理者が任意のファイルをアップロードできるという仕組みを用意した以上、攻撃性がある物を含め、任意のフ

          • >あと、AsWiki の態度は~
            Wikiの「どこの誰とも知れない第三者が編集できる」って性質自体問題ってことになってしまうような。

            被害を受けるのが人かマシンか、もっともそういうレベルまで落とすのならHTTPなりTCPだって同様の問題を抱えることになりますが。

            有害な情報を簡単にフィルタできないUAまたは文化の問題の
            • by Oiwa (6627) on 2005年05月19日 20時17分 (#737525) ホームページ
              ええと、今 aswiki のソースを2分間くらい読んでいるんですが、「そういうものです」という開き直ったような Web ページの書き方とは裏腹に、ひょっとしたらそもそも今回の脆弱性は存在しないかも... という気がしてきました。あとでインストールして確かめてみます。
              # Content-disposition: attachment を出力している気配があります。

              ですので、ここから先は脆弱性があるという前提での話としてですが...

              で、元コメントですが、Wiki の「誰でも編集できる」ことそれ自体、社会的・人的被害 (SPAM とか誹謗中傷とか) というレベルでは脆弱性といえるかもしれません。それは Wiki の弱点であり、「読者側の人間は(Wiki がそういうものだと知っていれば)理性的に内容を取捨選択できる」という前提に依存したセキュリティモデルでもあります。個人的には広くインターネット全体に書き込み権限を許すのはあまり勧められた物ではないと考えてはいますが、まぁ全く許せないポリシーというわけではありません。

              しかし、Wiki が独自文法を強制して、HTML タグ (特に<SCRIPT>や<OBJECT>)を書けないようにするというのは、機械的にウィルスを埋め込まれないとか、cookie を盗まれないとか、そういった web アプリケーションソフトウェアとしての基本的な安全性を保証しているという意味で、重要なsecurity featureです。機械は誤った情報を人間のように賢く取捨選択することができませんから、きちんと機械が誤動作しないような情報をクライアントに送信するのは、Webアプリケーション側の責任です。

              今回の場合、きちんと処理をしておかないと、攻撃者は外部から添付ファイルにリンクを張ることで、上記の Wiki 構文の制限を回避して、Wiki 利用者(設置者)や Wiki 読者に限らず全ての Web ユーザに対し、いきなり Wiki 設置サイトの権限で任意の HTML ファイルを読み込ませ、Javascript を走らせることができます。これは、現在の Web ブラウザと Web アプリケーションの基本的な設計モデルからすれば許容できない脆弱性に当たります。

              一方で、きちんと処理された Wiki やアップローダから添付ファイルを「ダウンロード」した後、そのファイルを人間が開くか開かないかは、添付付き Wiki やアップローダを使う人間の問題になります。やばいファイルが添付されていれば、やばいことが起こりますが、それは「そういうものです」。今回の XSS とは別件です。
              親コメント

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

処理中...