皆さんこんにちは、川口です。コラムの第6回「IPSは“魔法の箱”か」でまっちゃ１３９で講演をしたお話を書きましたが、今度は関東でやっている「まっちゃ４４５」にお招きいただき、お話ししてきました。
まっちゃ４４５は募集開始から定員が埋まるまでがとても速く、今まで参加したことがなかったのですが、今回は運良く（？）講師側ということでキャンセル待ちにならずに参加することができました。ロックオンの福田さんがオープンソースのECサイト構築システム「EC-CUBE」に脆弱（ぜいじゃく）性が発見された際のインシデントハンドリングのお話をされていました。EC-CUBEにSQLインジェクションとクロスサイトスクリプティング（以下、XSS）が発見されたあとの対応のお話です。JSOCで日々インシデントにかかわっているいる自分としてはとても興味深い内容でした。
日本のエンジニアのセキュリティ意識は過剰？
今回のような勉強会でも多数の人が参加するあたりセキュリティに対する関心が高いことがうかがえます。特に海外のカンファレンスで話したことと比較すると、日本ではウェブセキュリティに関する意識がとても高いように感じます。ただ、最近この意識の高さが行き過ぎていたりしないか？ とも思っているのです。
いま、あえて問います。世間でいわれているほど、XSSは危ないのでしょうか？
このセキュリティの記事をご覧になっている人ということは多少なりともセキュリティに興味があり、セキュリティ診断を受けた、もしくは関係したことがある人も多いのではないでしょうか。そのセキュリティ診断のレポートの中に「XSSの脆弱性あり」と記載されていたこともあるでしょう。または外部の組織から「おたくのサイトにXSSの脆弱性あるんだけど」と連絡を受けた人もいるかもしれません。ウェブとセキュリティに少しでも関係する人にとって、XSSというキーワードは無縁ではないと思います。
おしかりを覚悟で書きます。
“XSSってそんなに危ないのか？ 認識にギャップがないか？”
いままで丸6年間、JSOCで働いてきましたが、お客様の企業の株価が暴落したり、ビジネスを脅かすようなXSSは見たことはありません。JSOCのレポートの上位にXSSがランクインされても、そのほとんどはお客様が把握／管理していないセキュリティ診断通信です。もちろん対策が必須なウェブサイトがあることも、今までにSNSで悪用されてニュースになった事例も知っています。それでも世間は、XSSに対して「あおりすぎ」ではないでしょうか。その一端にセキュリティ企業である、私たちラックも当然含まれています。
XSSについて語る人はこういうでしょう。
「XSSなんてバグなんだから存在してはならない」
「過去にはこんなワームなどで悪用された」
「こうやったらCookieが漏れる」
これらの技術的な話はいままで何度も語られてきました。そういう私も今までXSSについて、そう説明してきました。しかし、説明すれば説明するほど、違和感を覚えるのです。
「XSSなんてバグなんだから存在してはならない」
→当たり前だが、バグのないシステムなんかあるのか？
「過去にはこんなワームなどで悪用された」
→5年間で10件程度もない頻度で、SQLインジェクションと比べたら微々たるもの
「こうやったらCookieが漏れる」
→それでどれくらい事件になったか？ これが経営者の投資意欲につながる数字なのか？
皆さんは、どうお考えでしょうか。
金もうけの視点から見た「XSS」
実際の攻撃事例はどうでしょうか。われわれのJSOCで観測しているものをみても、XSS攻撃を行っているのは日本からのみで、海外からのXSSはほとんどみられません。それは攻撃する側にとって、XSSはお金もうけの手段として大変面倒くさいものだからです。XSSで能動的に攻撃を行うことでなにかが得られるものではないため、わなを仕込む必要があります。わなを仕込んで誘導するくらいであれば、クライアントアプリケーションの脆弱性を狙ってボットを仕込む方がはるかに効率的だからです。
- 年に1回も起きないことに関してセキュリティ投資をする価値があるのか？
- “技術的に可能”なことがそのまま現実に起こるのか？
- XSSの脆弱性のためだけにシステムの再構築する必要があるのか？
- この問題で株価が下がることなんてあるのか？
- やられてしまったら営業担当者1人に謝罪にいかせた方が安いんじゃないのか？
このような思いから今回のコラムを書くことに至りました。例えばSQLインジェクションであれば、情報漏えいやデータ改ざんなどの危険性があるので理解できますが、XSS対策として過剰に投資する必要性に疑問を感じるのです。誤解がないようにいっておきたいのは私は「脆弱性があっても構わない」と主張しているのではなく、「過剰にあおりすぎていないか」ということです。
では、なぜこんなにもあおられているのでしょうか。私は以下のような理由があるのではないかと推測しています。
- 脆弱性を見つける“だけ”なら技術力がなくてもある程度発見可能
- 脆弱性をどれだけ見つけられるかが、調査をする人のステータスになっているため、とにかくたくさんの脆弱性を見つけて、指摘したい
- 「危険であることの証明」より「危険ではないことの証明」の方が難しいため、指摘された人は対応せざるをえない
- 「大したことないですよ」と発言して、あとで責任を追及されるとまずいから「危険ですよ」といっておきたい
- XSSをやっても不正アクセスにはならないから企業のサイトをガンガン攻撃しよう
いずれにせよ、過剰にあおる時代はそろそろ終わりにしなければなりません。
リスクを考える際には、脆弱性の存在とともに、その脆弱性の悪用難易度と発生頻度も考えなければなりません。悪用が難しく、発生頻度が低いリスクに関しては、リスクを保有するのが自然な考えではないかと思います。世の企業はセキュリティで100点満点を取るためにビジネスをやっているわけではありません。ビジネスのメリットとデメリットを考えて対策を選別するべきです。
まずは掲示板、日記など、外部からデータを登録可能な内容を閲覧する機能にはXSSが存在しないようにしてください。特に「不特定多数からデータを登録可能」かつ「そのデータを不特定多数に表示する」機能については攻撃者に狙われる確率が高く、狙われた場合の被害が大きくなりますので、対策の優先順位は高くするべきです。
現実的なリスクを考え、現実的な対策からはじめよう
現時点でのXSSのリスクはなんでしょうか。私の考えるリスクは以下のものです。
- 社会的信用のある企業・サービスが被害を受ける
銀行、クレジットカード決済、公共サービスなど社会的に信用が必要なサイトは狙われる可能性も高く、被害が発生した場合の存在も大きくなります。 - 痛くもない腹を探られる
XSSの脆弱性があるだけで「おたくのサービスは大丈夫か？」「ほかのサービスも危ないのでは？」と疑われるきっかけを生みます。 - いちゃもんをつけられる
“正義の味方”的な人に「ここは脆弱性があるぞ」とさらされます。見方によっては脆弱性の存在をタダで教えてくれる便利な人かもしれません。
これらをみて、対策が必要だと感じる人が、ビジネスの規模と相談して対策をすればよいと思っています。対策ができることにこしたことはありませんが、リスクを保有することがビジネス上の判断であれば、そのリスクを保有しているということを忘れないようにしてください。
思い起こせば、JSOCでSQLインジェクションを初めて検知した2003年には、いまのようにSQLインジェクションで大規模な情報漏えい事件が頻発することは夢にも思いませんでした。時代は変わるものです。いつかXSSもお金もうけの手段として使うことができるようになる可能性も十分あります。そのときに警鐘を鳴らすことが私の義務です。
私が尊敬する同業の方と神谷バーで電気ブランを飲みながら今回の話を振ったところ、同意をしてもらいました。同じ思いでいる人も多いのかもしれません。今回の話は昔から疑問に思っていたことなのですが、自社ではなく他社にも同じ思いの人がいたことがとてもうれしかったです。
1〜2年前まではこういう話をする機会もあまりなかったのですが、最近ではいろいろと縁があってこういうお話ができる機会も増えてきました。私は日本のセキュリティレベル向上を目指し、熱い議論をするために今日も飲みに行くのでした。
Profile
川口 洋（かわぐち ひろし）
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS／IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリスト兼セキュリティアナリストとして、JSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。
- 「DNS通信」記録していますか？――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは？
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた！
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ！
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は？
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか？ クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み？静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは？
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実：「検知できる」ってどういうこと？
- ところで、パッケージアプリのセキュリティは？
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.