「あるサイトにXSSの脆弱性があって、不正ログインが発生した」――このような情報が耳に入ることもあるかもしれませんが、このXSSの実際の仕組みを理解している人はどれくらいいるでしょうか。そもそも、XSSとは?という人も少なくないでしょう。

XSSとは、ウェブサーバ、Webアプリケーションなどで発生する脆弱性のひとつです。最近は被害事例が少なくなってきてはいますが、それでも潜在的にこの脆弱性が含まれているウェブサイトはまだまだ存在しています。今回はこのXSSに焦点をあてて、危険性や対処策を学んでいきましょう。

クロスサイトスクリプティング(XSS)攻撃とは?言葉の意味と仕組み

XSSとは「クロスサイトスクリプティング」の略です。本来の英語つづりにすると「CSS」となるのですが、HTMLにおけるカスケーディングスタイルシートと混同する可能性があるため「XSS」と表記されています。

これはウェブサイト(あるいは“SaaS”のようなWebアプリケーション)の脆弱性にあたるもので、単純に言ってしまえば「もともともアクセスしようとしていたサイトとは別の意図していないサイトに対して情報送信を実施してしまう」ことを指します。
本来のサイトと別のサイトを「横断する(クロスする)」=「クロスサイト」。情報を送信する方法が「スクリプトを実行させる(使用する)」=スクリプティング。そして、この仕組みを利用してサイバー攻撃をしかけることがXSS攻撃となります。

マルウェアではなく「脆弱性」という言葉に分類される通り、ウェブサイト側が正しく「不正なスクリプトを実行させない」処理をしていればXSSは発生しません。XSS脆弱性が存在するサイトに対して、悪意のあるユーザが不正なスクリプトを含んだURLを作成し、一般ユーザがそのURLをクリックすることで、XSS攻撃が成立します。もちろん攻撃の入り口はURLに限った話ではありません。

以前はサイト横断型が中心的でしたが、現在では悪意のあるユーザに直接情報を送信させる方法など、単純に「サイト横断型」ではないものも存在するようです。

クロスサイトスクリプティングで起こりうる影響

XSS攻撃によってどんな事象が発生するのでしょうか。

初期型のわかりやすいパターンでは、「正規のURLから始まるリンクだったので、正規サイトに飛んだと思ったユーザがフォームに入力してみたところ、実際は悪意のあるサイトに飛んでおり、そのフォームに入力した情報を盗み取られてしまった」というものがあります。
現在ではXSSを利用して、「ログインした挙動とセッション」自体が悪意のあるユーザに送信されてしまい、悪意のあるユーザによって不正ログイン、いわゆる「なりすまし」が実行されてしまうという例が多くなっています。

どのようなパターンにおいても、Webサイトの改ざんを経由して最終的に情報漏洩につながるという例が多く報告されています。ユーザが使用しようとしているサービスに保管しているデータが、漏洩してしまうのです。

クロスサイトスクリプティングでの被害事例

スクリプトを仕込む場所は一般的にリンクとなるURL文字列であることが多いのですが、掲示板や記事に対するコメントなどもXSS攻撃を受けやすい場所です。

2010年7月にYouTubeで発生したXSS攻撃ではコメント欄が悪用され、ページに飛ぶとポップアップが出る、別のサイトに飛ばされる、ログインするためのcookieが不正に取得される……などの被害が発生しました。この時はGoogleによって2時間ほどで対策が採られています。

同年にはTwitterでもツイートに任意のコードを挿入できるXSS脆弱性が発見されるなど、2010年は著名な大規模サイトにおけるXSS脆弱性の報告が目立った年でした。

最近ではこのようなXSSの被害事例はあまり見られませんが、全くないわけではありません。2015年には米国の風力発電システムのウェブ管理画面内にXSS脆弱性が発見されています。昨今では特に「内部環境で使用されるからあまり気にしていない」システムにおいて潜在的にXSS脆弱性が発見される例が増えてきているように見受けられます。

危険なサイトの見分け方

XSS脆弱性を抱えているサイトとはどんなサイトなのか、見分ける方法は「ほとんどありません」。見た目はきれいなサイトであってもXSS脆弱性が存在している可能性があります。
最近ではウェブサイト・Webアプリケーションなどに共通して仕様されるフレームワーク自体に脆弱性が存在しており、それ自体がサイバー攻撃の温床となるという事例もあります。

2017年には多くのサイトで使用されていたApache StrutsにおいてXSS脆弱性を含む複数の脆弱性が発見されています。後継のApache Struts 2でもこれは同様で、2018年以降断続的に脆弱性が報告されており、その中には実際に攻撃まで至った例も複数報告されています。

これはXSS脆弱性に限った話ではありませんが、一部の「専門家」を自称する評論家などが「アドレスバーが緑であれば安全」もしくは「httpsから始まっているURLなら大丈夫」といった発言をしており、それがテレビなどのメディアで紹介されていることがあります。
このサイトでも繰り返し取り上げていますが「○○だから安全」などというものはセキュリティにおいて存在しません。上記のようなサイトでも脆弱性があれば攻撃者の侵入を許しますし、最近では悪意のあるサイトでも、前に挙げた「https」などの表示がされることも多くなっているので、注意が必要です。

ユーザ観点で見た対策

では、ユーザは何もできず、そういったウェブサイトに当たらないよう祈るしかないのでしょうか?
そんなことはありません。頼りとなるのが「セキュリティソフト」です。特にXSSでは「スクリプト」を経由して攻撃が実施されるのですが、このスクリプトは「自分のコンピュータ(ブラウザ)上」で実行されます。
昨今のセキュリティソフトには、このような挙動を監視し、不正であるかどうかを常に確認する機能が搭載されているものもあるのです。

最近では、本来と関係ないサイトに飛ばされるような挙動もしっかりと確認し、ブロックすることができます。ウェブサイト側の対策ができていない場合でも、ある程度の防御は可能になるのです。

また、複数台のコンピュータを管理しなければならない管理者側では、こういったセキュリティソフトのログを抽出することで「どのサイトにアクセスしようとした時にセキュリティ機能が働いたのか」を調査することができます。
この調査結果を利用し、社内のファイアウォールなどに適用させることで、第2第3の被害を大きく減らせるのです。

まとめ XSSは無くなっていない。ただ知らないだけ。

クロスサイトスクリプティングは基本的には「ウェブサイト側の対策ができていない」脆弱性によるものです。本来はサイト側が対処しなければならないのですが、脆弱性はいたちごっこであり、連日新しいものが発見されています。

ユーザ側である程度の対策をしなければ、安全にサービスを使用することが難しくなってきている現代。重要な情報を取り扱うビジネスの場所においてそういったことを未然に防ぐことができる立場にいるのが、セキュリティ担当者です。
セキュリティインシデントを未然に防ぐためにも、自社の環境をもう一度見直してみましょう。