適当
XSSがある=なんでもやり放題ではない
ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。
参考までに
- http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話)
- http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話)
管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられている例がこちら。
- http://d.hatena.ne.jp/rosylilly/20091216/1260961264
- http://d.hatena.ne.jp/rosylilly/20091219/1261254527
scriptが書ければブラクラを置いて閲覧者に対して嫌がらせすることは出来るし、ブラウザやpluginに脆弱性がある場合「scriptを書けること自体」が深刻な脅威になりうるので、scriptを一切書けないようにするというポリシーも勿論ある。同じ会社が運営しているサービスでもドメインごとにセキュリティポリシーがある。たとえばはてなダイアリだったら、ユーザーの入力したscriptは実行不可、Google AdSenseや一部のブログパーツのスクリプトは実行されて良い、といった具合に決まってる。単にscriptが実行できるというだけで「あのサービスはXSS脆弱性がある、危険だ」と騒ぎ立てるのは良くないことだと思う。
脆弱性があった場合の影響範囲を抑える
- もし初心者がウェブアプリケーションを作るのであれば、まず最初に「脆弱性があっても大丈夫にする」ことを覚えるのが良いと思う。
- さまざまな攻撃手段や、それに対する対策方法を網羅的に学習するのは時間がかかるし、長年運営しているサイトにも放置されている脆弱性があったりする。
- 個人情報を預からないようにするとか、決済機能は外部サイトに頼るとか。
単純な例を言うと「重要な機能にはパスワードの再確認を入れる」ことだ。重要な機能は例えば、パスワードの変更、メールアドレスの変更、サービスの退会などだ。これらの機能にパスワードの再確認が無い場合、XSSが一つあるだけで、アカウントを乗っ取ったり、サービスを退会したり出来てしまう。(パスワード再確認はCSRF対策にもなる)
正しい脆弱性報告のあり方
IPAを通したりすると、対応が遅くなるのが普通です。IPAを通じて脆弱性の報告が来るということは、脆弱性の発見者がセキュリティ専門家だったりするため、対策が取られるまで公開されないことが予測できる。つまりIPAから脆弱性の報告が来る=緊急ではないという図式が成り立ってしまう！！
早急に脆弱性が修正されることを望んでいるのであれば「俺はゼロデイXSSのURLをtwitterに晒したくてウズウズしてるんだよォォォ！！！！」という姿勢を見せながら中の人に連絡するのが良いでしょう。大体その日のうちに何とかしてくれるはずです。
脆弱性の報告はIPA通すと諸々の手続きが面倒くさくなることを知っているため、サービス開発者同士のネットワークでは、IRC、各種IM、Skypeなどで中の人に直接知らせるのが普通です。そして脆弱性の報告を受けたら、お礼として焼肉や寿司を奢るという慣習がある。
ところが京都に本社を置くHという会社は、脆弱性報告の謝礼を「はてなポイント」や「カラースター」で代用するという風習があるため、必然的に脆弱性を報告するメリットが少なくなる。これは非常に危険な状態であるため、猛省を促したい。