クロスサイトスクリプティング(XSS)とは|攻撃の仕組みと対策方法を解説
クロスサイトスクリプティング(XSS)は、近年注目されている攻撃の一つです。 専門的な知見があれば、比較的容易に実行できてしまう攻撃のため、Webサイト運営者は脆弱性の対策が求められます。 本記事では、クロスサイトスクリプティング(XSS)の概要と手口、対策などについて解説いたします。
目次
クロスサイトスクリプティング(XSS)とは?

クロスサイトスクリプティング(XSS)とは、攻撃対象のWebサイトの脆弱性を突き、攻撃者がそこに悪質なサイトへ誘導するスクリプトを仕掛けることで、サイトに訪れるユーザーの個人情報などを詐取する攻撃のことを指します。
罠を仕掛けたWebサイトに訪問したユーザーを脆弱性のあるWebサイトに誘導(サイトをクロス)して、情報搾取などの攻撃をすることから、この名称が付けられています。
IPA(情報処理推進機構)の調査では、Webサイトの脆弱性の種類別の届出状況において、「クロスサイトスクリプティング(XSS)」が58%と、続いて「DNS情報の設定不備」が12%と、半数以上を占めています。
参照:ソフトウェア等の脆弱性関連情報に関する届出状況(2020年第3四半期)7〜9月|IPA(情報処理推進機構)
クロスサイトスクリプティング(XSS)攻撃の流れ・仕組み

それでは、クロスサイトスクリプティング(XSS)攻撃の流れ・仕組みについて説明します。 まず攻撃者は、インターネット掲示板などの動的なWebサイトにある入力フォームに罠(脆弱性のあるサイトへ誘導するスクリプトを含んだリンク)を設置します。 リンクをクリックしてこのようなサイトに誘導されると、ユーザーのブラウザ上で不正なスクリプトが実行され、入力した情報やCookieなどが攻撃者へ漏洩、マルウェアへの感染、なりすましなどの被害が発生します。
クロスサイトスクリプティング(XSS)が起こってしまう要因は、入力値が制限されていなかったり、入力したスクリプトをそのまま実行できる状態にあり、攻撃者が容易に不正なスクリプトを入力できてしまうことが挙げられます。
クロスサイトリクエストフォージェリ(CSRF)との違い
クロスサイトスクリプティング(XSS)に似たものに、クロスサイトリクエストフォージェリ(CSRF)があります。 クロスサイトスクリプティング(XSS)はインターネット掲示板など動的なWebサイトにある入力フォームの脆弱性を狙ったものですが、クロスサイトリクエストフォージェリ(CSRF)はセッション管理における脆弱性を狙う攻撃です。
セッションはセッションIDとも呼ばれ、サーバーやアプリケーションがユーザーを一意的に識別するために付与される情報のことを指します。 攻撃者はこのセッション管理に脆弱性があるWebサイトにログインした状態のユーザーをターゲットにします。 罠を仕掛けたWebサイトにそのユーザーを誘導して、攻撃用のリクエストURLをクリックさせます。 これにより、脆弱性のあるWebサイトに対する改ざんや強制書き込み、不正操作などをユーザーのセッションIDを使って行います。
SQLインジェクションとの違い
クロスサイトスクリプティング(XSS)に似た攻撃に、SQLインジェクションがあります。 SQLインジェクションはクロスサイトスクリプティング(XSS)と同様、Webアプリケーションの脆弱性を狙った攻撃です。 SQLインジェクションとは、「SQL」に不正なコードを挿入し、直接データベースを不正操作するサイバー攻撃を指します。
SQLインジェクションについてはこちらの記事で詳しく解説しています。
また、JP-Secure Labsの調査によれば、2019年に「ロリポップ!レンタルサーバー」で検出された攻撃総数2億7898万件のうち、「47%」がSQLインジェクションであることが分かっています。
参照:JP-Secure Labs Report Vol.04
クロスサイトスクリプティング(XSS)の種類

次に、クロスサイトスクリプティング(XSS)の種類について解説します。 クロスサイトスクリプティング(XSS)は「Reflected XSS(反射型XSS)」「Stored/Persistent XSS(格納型/蓄積型/持続型XSS)」「DOM Based XSS」の3種類があります。
non-persistent/Reflected XSS(反射型XSS)
攻撃者は偽メールや偽サイトに不正なスクリプトを含んだリンクを用意し、脆弱性のあるWEBサイトに誘導する(リクエストさせる)ことで、ユーザーのブラウザで不正なスクリプトを実行させ、情報の搾取やマルウェアのダウンロードなどを行います。 リクエストした者にスクリプトが返ってくることから、「反射型XSS」と呼ばれています。
Stored/Persistent XSS(格納型/蓄積型/持続型XSS)
あらかじめ、攻撃者はWebアプリケーションに直接スプリクトを格納します。 その後、該当のページをユーザーが閲覧するたびに、不正なスクリプトが実行されます。 該当のページにアクセスするだけであるため、Reflected XSSと比較すると罠を仕掛けたWebサイトを準備したり、スクリプトを含んだリンクをメール送信したりしなくても攻撃が成立する点では、効率的と言えます。
DOM Based XSS
DOMは、「Document Object Model」の略で、HTMLやXMLを取り扱うためのAPIやデータ構造を定義したものです。 Webブラウザで動作するJavaScript上のコードの脆弱性を悪用した攻撃で、サーバ側で攻撃用スクリプトが実行されるのではなく、クライアントのWebブラウザ上で不正なスクリプトが実行されます。 また、DOM Based XSSの場合では、静的なHTMLにおいてもJavaScriptが利用されていれば攻撃対象となります。
クロスサイトスクリプティング(XSS)で起こる被害内容

実際にクロスサイトスクリプティング(XSS)攻撃をされると、具体的にどのような被害が生じるのでしょうか。
セッションハイジャック
セッションハイジャックとは、Webサイト上のIDやCookieをなんらかの方法で不正に入手し、セッションを乗っ取るサイバー攻撃のこと。 セッションハイジャックをされてしまうと、サーバ内への侵入や機密情報の搾取、不正出金、クレジットカードの不正利用などの被害に遭う可能性があります。
個人情報の流出
もちろん、個人情報の流出につながるケースもあります。 重要な住所、名前、誕生日、カード情報などが搾取された結果、ダークウェブサイトなどで情報リストとして売却され、パスワードリスト攻撃の標的になったり、情報漏えいを示唆し、金銭要求の脅迫をされてしまうことも。
Webページの改ざん
実行させる攻撃用のスクリプト次第では、表示させるWebページを改ざんすることもできます。 過去にはクロスサイトスクリプティング(XSS)攻撃で公式サイトを改ざんし、トロイの木馬を設置した結果、ユーザーの個人情報を抜き取るといった被害も起こっています。
クロスサイトスクリプティング(XSS)の事件・事例

過去にも、クロスサイトスクリプティング(XSS)によって発生した被害事例がいくつか存在します。 ここでは実際に過去に発生した被害内容の事件・事例をいくつかご紹介します。
2010年に何者かがTwitter公式サイトの脆弱性を悪用し、大量にリツイートさせる事件が発生。 仕掛けられたリンクにマウスオーバーするだけで、リツイートされてしまうコードなどが投稿され、最大で50万人が何かしらの影響を受けたといわれています。
PayPal
2015年、PayPalのセキュアペイメントページを直接書き換えることができてしまう重大な脆弱性が見つかりました。 幸いにも、PayPalは問題の報告を受けてから、すぐに修正を行ったため、被害が出ることはありませんでした。
YouTube
アメリカ版YouTubeのコメント機能における脆弱性を悪用したクロスサイトスクリプティング(XSS)が行われ、フェイクニュースがポップアップ表示されたり、悪質なWebサイトへリダイレクトされるなどの被害が起こりました。
クロスサイトスクリプティング(XSS)攻撃の対策

最後に、クロスサイトスクリプティング(XSS)の対策について解説いたします。
サニタイジング(エスケープ)処理をする
サニタイジング(エスケープ)処理とは、「<」や「“」といった区切りやタグなどの意味を持つ文字を、意味を持たない文字列に置き換え無害化する行為を指します。 サニタイジング(エスケープ)処理をすることで、スクリプトが意図せずに挙動してしまうことを防ぐことができます。
バリデーション処理(入力値の制限)
例えば、パスワード入力欄に「全角英数字の6文字」と入力制限をかけたり、電話番号の入力欄で、数字以外の入力データを弾いたりするなどして、不正なスクリプトを入力されないようにします。 JavaScriptを使い、ブラウザ側で入力値の制限を行ってしまうと、ユーザー側がJavaScriptをオフにし不正スクリプトの入力ができてしまうため、必ずサーバ側での入力値制限を実施しましょう。
WAFを設置する
WAFとは、「Web Application Firewall」の略称で、Webアプリケーションを対象とした攻撃を検知・防御するセキュリティ製品です。 自社において、オープンソースのシステムを利用していたり、CMSやフレームワークを使ってシステムやWebサイトを構築していたりする場合、全ての脆弱性修正に対応するには限界があります。 修正漏れによるセキュリティリスクを防ぐためにも、WAFの導入は必要不可欠です。
WAFについてはこちらの記事で詳しく解説しています。
出力時はhttpやhttpsから始まるURLのみ許可する
URLに「javascriptスキーム」や「dataスキーム」などが含まれている場合でも、クロスサイトスクリプティング(XSS)のリスクが生じます。 入力するリンク先のURLはhttpやhttpsから始まるもののみを許可する設定にすることで、想定外の処理がされるリスクを防げます。
まとめ

動的なHTMLページがあるWebサイトの管理者においては、クロスサイトスクリプティング(XSS)から身を守るために、脆弱性を修正し、前述したサニタイジングやバリテーション処理などを行う必要があります。 攻撃を受けてしまうと、自社だけでなくユーザーに実害が及び、企業イメージの毀損だけでなく損害賠償なども発生してしまう事態に発展することも。 ぜひ、この記事を参考に、改めて自社のセキュリティ対策について見直してみてください。