XSS攻撃は、バグのある Web アプリケーション (今回の場合 Wiki サーバのソフト) に怪しげなデータを送りつけて、偽物のスクリプトをあたかも本物の Web アプリケーションの出力した JavaScript のように見せかけて Web ページに埋め込んでやるという攻撃です。ブラウザが受信した HTML ファイルを見ると、どちらも本物のスクリプトのように見えます。本物に見える以上、基本的にはブラウザは言われた通りに（スクリプトに許される権限の範囲で）実行するのが仕様に沿った「正しい」動作です。最初にブラウザに脆弱性があって、それを攻撃する、というシナリオではそもそもないのです。
# 逆に言えば、本物のスクリプトがやろうとしてもできないこと（いきなりローカルディスクのファイルを勝手に送信しちゃうとか）は XSS 脆弱性だけを使っても実現できません。できたらそれは「ブラウザのバグ」ですね。
誰も今ウィルス入りのソフトを実行してデータ盗まれたからって、ウィルスを実行する Intel/AMD の CPU はケシカラン、とは普通言いませんよね。だってウィルス入りソフトのコードは機械語としては悪い事するのが「正しい動作」なんですから、Intel/AMD の CPU にとっては言われた通りのことを忠実に僕として実行しただけで、基本的にはそこを責められても困ります。XSS とブラウザの関係も基本的にそれと同じことです。
ええと、今 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 とは別件です。
AsWikiやHikiは該当しないのでは？ (スコア:1)
http://jvn.jp/jp/JVN%23465742E4/index.html
のベンダ情報みると、AsWikiやHikiは「該当製品なし」と書いてありますが、この２つには脆弱性はないということなんじゃないですか？
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
Re:AsWikiやHikiは該当しないのでは？ (スコア:4, 参考になる)
「ユーザーからファイルをアップロードできる」ようにするからには、こういう危険性を回避する方法はまったくないかと思います。
たとえば、単に画像をアップできる掲示板でも、JPEGファイルを用いて任意のコードが実行できるという脆弱性 [srad.jp]による危険はあるわけですよね。
Wikiもどきの対応 [moonrock.jp]:
A.添付機能を無効に
B.アップロード元ホスト・ファイル名・Content-Type に基づく添付可否条件が設定可能
PukiWiki [pukiwiki.org]:
回避策(1) 全体をリードオンリーに
回避策(2) 管理者だけが添付ファイルのアップロードができるように
回避策(3)(4) 添付ファイルのアップロードができないように
どちらも、根本的な解決じゃないですよね。
WikiもどきのBはまともそうに見えますが、
Internet Explorer の「拡張子もContent-Typeも無視してデータの内容を元にどうやって表示するかを決める」という困った仕様の
前には無力だと思います。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
表示については次の版で、Hikiと同じようにContent-Depositionヘッダフィールドによる対処を行う予定です。ただ、これって全てのブラウザで有効なのかしりませんので効果も今イチ把握出来てません。
ＤＯＮ
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
さすがに、ブラウザに脆弱性があって、Webソフト側の妥当な仕様がトリガーを引くパターンと、Wiki の仕様＋ブラウザの仕様 から引き起こされる脆弱性を同一に扱うのはどうかと思いますが...。
Wikiもどきの(B)が対策になっていない、というIEの仕様は非常に問題だと思うんですが、現状ではこれはWiki側がなんとかしないとまずいでしょうねぇ。
あと、AsWiki の態度は個人的には開き直りに見えて妥当ではないと感じています。これが「該当製品なし」に分類されてしまう JVN の分類も問題ですが。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1, 興味深い)
今回の問題は、通常の掲示板であれば、管理者以外は画像やテキストなどしか書き込みできないのが、Wiki等の添付ファイルのアップロード機能があるものではブラウザのXSS脆弱性を攻撃するファイルをアップロードできてしまう。
だからマズいんじゃない？
という話で、Wikiの仕様がトリガーとなってブラウザの脆弱性が現出するのですからJPEGファイルの問題と形としては一緒です。
あとは、その「Wikiの仕様」が妥当かどうかという話になる訳で・・・
ブラウザの脆弱性を攻撃するファイルのアップロードは全て「妥当な仕様ではない」と断ずるのであれば、JPEGファイルがアップロードできる掲示板なども全部「妥当な仕様ではない」という事になっちゃいますし。
Re:AsWikiやHikiは該当しないのでは？ (スコア:1)
だから違うんだってばさ。今回の件に関して言えば、攻撃されたブラウザのXSS脆弱性というものはそもそも存在しません。
# スクリプトに絡むブラウザのバグで、XSSと似たような結果を生むものはありましたけど、今回の件とは別件です。
XSS攻撃は、バグのある Web アプリケーション (今回の場合 Wiki サーバのソフト) に怪しげなデータを送りつけて、偽物のスクリプトをあたかも本物の Web アプリケーションの出力した JavaScript のように見せかけて Web ページに埋め込んでやるという攻撃です。ブラウザが受信した HTML ファイルを見ると、どちらも本物のスクリプトのように見えます。本物に見える以上、基本的にはブラウザは言われた通りに（スクリプトに許される権限の範囲で）実行するのが仕様に沿った「正しい」動作です。最初にブラウザに脆弱性があって、それを攻撃する、というシナリオではそもそもないのです。
# 逆に言えば、本物のスクリプトがやろうとしてもできないこと（いきなりローカルディスクのファイルを勝手に送信しちゃうとか）は XSS 脆弱性だけを使っても実現できません。できたらそれは「ブラウザのバグ」ですね。
一方で JPEG のバグは、画像を表示しろとだけ指示されそれを受け入れたブラウザが、なぜかメモリ内容をブッ壊してわけのわからん機械語の実行を始めてしまうというバグですので、ブラウザの問題です。
誰も今ウィルス入りのソフトを実行してデータ盗まれたからって、ウィルスを実行する Intel/AMD の CPU はケシカラン、とは普通言いませんよね。だってウィルス入りソフトのコードは機械語としては悪い事するのが「正しい動作」なんですから、Intel/AMD の CPU にとっては言われた通りのことを忠実に僕として実行しただけで、基本的にはそこを責められても困ります。XSS とブラウザの関係も基本的にそれと同じことです。
＃『基本的には』と書くからにはもうちょっと厳密な話をしないといけない点があるんですが、それはまた今度……。
Re:AsWikiやHikiは該当しないのでは？ (スコア:0)
それは管理者が意図しないJavaScriptが埋め込めるというだけで、全然クロスサイトしてません。
JavaScriptに関する問題を何でもかんでもXSSというのはバカみたいですからやめましょう。
# バカみたいなだけでなく、問題の本質をわかりにくくする。
管理者が任意のファイルをアップロードできるという仕組みを用意した以上、攻撃性がある物を含め、任意のフ
Re:AsWikiやHikiは該当しないのでは？ (スコア:0)
Wikiの「どこの誰とも知れない第三者が編集できる」って性質自体問題ってことになってしまうような。
被害を受けるのが人かマシンか、もっともそういうレベルまで落とすのならHTTPなりTCPだって同様の問題を抱えることになりますが。
有害な情報を簡単にフィルタできないUAまたは文化の問題の
Re:AsWikiやHikiは該当しないのでは？ (スコア:3, すばらしい洞察)
# 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 とは別件です。