CREX｜Security

CREX｜Security

クロスサイトスクリプティング（XSS）とは？仕組みと脆弱性対策10選

更新日：

クロスサイトスクリプティング（XSS）とは？、仕組みと脆弱性対策10選

インターネットが社会インフラとして定着した現代において、WebサイトやWebアプリケーションの安全性は、企業活動や個人の情報資産を守る上で極めて重要な要素となっています。数あるサイバー攻撃の中でも、Webアプリケーションの脆弱性を突く攻撃は後を絶ちません。その代表格の一つが「クロスサイトスクリプティング（XSS）」です。

XSSは、多くのWebサイトが抱える可能性のある脆弱性であり、攻撃が成功すると利用者の個人情報漏えいやアカウント乗っ取りなど、深刻な被害を引き起こす可能性があります。Webサイトの開発者にとっては、自らが提供するサービスの信頼性を根底から揺るがしかねない脅威であり、利用者にとっては、意図せずサイバー犯罪の被害者となってしまうリスクをはらんでいます。

この記事では、クロスサイトスクリプティング（XSS）の基本的な概念から、攻撃が成立する仕組み、具体的な被害事例、そして開発者と利用者の両面から取るべき実践的な対策までを網羅的に解説します。安全なWeb利用環境を構築し、維持していくための知識を深めていきましょう。

クロスサイトスクリプティング（XSS）とは

クロスサイトスクリプティング（XSS）とは

クロスサイトスクリプティング（Cross-Site Scripting、略称：XSS）とは、Webアプリケーションの脆弱性を利用して、悪意のある第三者が作成したスクリプト（簡易的なプログラム）を、他の利用者のブラウザ上で実行させる攻撃手法のことです。

この攻撃の最大の特徴は、攻撃者が直接利用者を狙うのではなく、脆弱性のあるWebサイトを「踏み台」として利用する点にあります。利用者は信頼しているWebサイトを閲覧しているつもりが、その裏で不正なスクリプトが実行され、さまざまな被害に遭ってしまうのです。

なぜ「クロスサイト（サイトを横断する）」という名前が付いているのでしょうか。これは、攻撃が成立する過程で、攻撃者が用意したサイトと標的となる脆弱なサイト、そして利用者のブラウザという複数のドメイン（サイト）をまたがって（クロスして）スクリプトが実行されることに由来します。

XSSの主な標的となるのは、ユーザーからの入力内容（検索キーワード、コメント、プロフィール情報など）を受け取り、その内容を動的にWebページ上に表示する機能を持つ、いわゆる「動的サイト」です。例えば、以下のような機能を持つWebサイトは特に注意が必要です。

  • 検索機能
  • 掲示板やブログのコメント機能
  • SNSの投稿機能
  • ユーザー登録フォームやプロフィール編集機能
  • ECサイトの商品レビュー機能
  • お問い合わせフォームとその確認画面

攻撃の基本的な流れは、以下のようになります。

  1. 罠の設置: 攻撃者は、脆弱性のあるWebサイトの入力フォームなどに、不正なスクリプトを埋め込みます。あるいは、不正なスクリプトを含むURLを作成します。
  2. 利用者のアクセス: 利用者は、何も知らずにそのWebページを閲覧したり、攻撃者が作った罠のURLをクリックしたりします。
  3. スクリプトの実行: Webサイトは、攻撃者が埋め込んだスクリプトを正規のコンテンツの一部として利用者のブラウザに送信します。ブラウザは受け取ったスクリプトを信頼されたものと解釈し、実行してしまいます。
  4. 被害の発生: 実行されたスクリプトにより、利用者のCookie情報が盗まれたり、偽の入力フォームが表示されたりといった被害が発生します。

ここで重要なのは、不正なスクリプトが「信頼されているWebサイトのドメイン」で実行されるという点です。ブラウザには「同一オリジンポリシー」というセキュリティ機構があり、異なるドメインのWebページが互いの情報（Cookieなど）を読み取ることを原則として禁止しています。しかし、XSS攻撃では、スクリプトが標的サイトのドメイン上で実行されるため、この同一オリジンポリシーを回避し、そのサイトのCookie情報などを不正に取得することが可能になってしまうのです。

この巧妙さゆえに、利用者は攻撃に気づきにくく、Webサイトの運営者は自社のサービスが犯罪の温床となることで、金銭的な損害だけでなく、ブランドイメージの失墜という計り知れないダメージを受ける可能性があります。

したがって、XSSはWebアプリケーション開発における最も基本的かつ重大なセキュリティリスクの一つとして認識されており、その対策は開発者にとって必須の知識と言えます。この後の章で、より具体的な攻撃の仕組みや種類、そして万全な対策について詳しく掘り下げていきます。

クロスサイトスクリプティングの仕組みと3つの種類

クロスサイトスクリプティング（XSS）は、攻撃の手法やスクリプトがどこに格納されるかによって、大きく3つの種類に分類されます。それぞれの仕組みと特徴を理解することは、適切な対策を講じる上で不可欠です。ここでは、「反射型XSS」「格納型XSS」「DOM Based XSS」の3つについて、その動作原理を詳しく解説します。

種類 スクリプトの格納場所 攻撃の持続性 被害範囲 サーバーの関与
反射型XSS URLパラメータなど（サーバーに保存されない） 一時的 罠のリンクをクリックした利用者 あり（スクリプトを「反射」して応答する）
格納型XSS Webサーバーのデータベースなど 持続的 該当ページを閲覧した不特定多数の利用者 あり（スクリプトを「格納」し、配信する）
DOM Based XSS URLのフラグメントなど（クライアントサイド） 一時的 罠のリンクをクリックした利用者 原則なし（ブラウザ内で完結する）

反射型XSS（Reflected XSS）

反射型XSSは、攻撃者が仕込んだ不正なスクリプトを含むURLを利用者にクリックさせることで、スクリプトを実行させる最も古典的で一般的なタイプのXSSです。サーバーは受け取ったスクリプトをそのまま利用者のブラウザに「反射」するように応答するため、この名前が付けられています。

【仕組み】

  1. 罠のURL作成: 攻撃者は、標的となるWebサイトの脆弱性を探し出します。例えば、サイト内検索機能で、検索キーワードをURLのパラメータ（例: https://example.com/search?q=キーワード）として受け取り、そのキーワードをそのまま検索結果ページに表示するような実装になっているとします。攻撃者は、この「キーワード」の部分に、キーワード<script>alert('XSS');</script> のような不正なスクリプトを埋め込んだURLを作成します。
  2. 利用者の誘導: 攻撃者は、作成した罠のURLを、メール、SNSのダイレクトメッセージ、掲示板への投稿などを通じて利用者に送りつけ、「お得な情報はこちら」「緊急のお知らせ」といった巧みな文言でクリックさせようとします。
  3. スクリプトの送信と反射: 利用者が罠のURLをクリックすると、不正なスクリプトを含んだリクエストがWebサーバーに送信されます。脆弱なWebアプリケーションは、URLパラメータに含まれるスクリプトを無害化（エスケープ処理）することなく、そのままHTMLレスポンスに埋め込んで利用者のブラウザに返します。
  4. スクリプトの実行: 利用者のブラウザは、Webサーバーから送られてきたHTMLを解釈します。その中に含まれるスクリプトは、正規のコンテンツの一部として実行されます。その結果、アラートが表示されたり、Cookie情報が攻撃者のサーバーに送信されたりといった被害が発生します。

【特徴】

  • 一時的な攻撃: 不正なスクリプトはWebサーバーのデータベースなどには保存されません。そのため、効果は罠のURLをクリックしたその時限りです。
  • 標的は限定的: 攻撃を成功させるためには、攻撃者が能動的に利用者へURLを送り、クリックさせる必要があります。そのため、被害は基本的にそのURLをクリックした利用者個人に限定されます。
  • ソーシャルエンジニアリングとの組み合わせ: 攻撃の成否が「いかにして利用者にURLをクリックさせるか」にかかっているため、人間の心理的な隙を突くソーシャルエンジニアリングの手法と組み合わされることが多くあります。

格納型XSS（Stored XSS）

格納型XSSは、攻撃者が仕込んだ不正なスクリプトが、Webサーバーのデータベースやファイルシステムに「格納（保存）」され、そのページを閲覧した不特定多数の利用者のブラウザで実行されるタイプのXSSです。持続型XSS（Persistent XSS）とも呼ばれます。

【仕組み】

  1. スクリプトの投稿・保存: 攻撃者は、掲示板、ブログのコメント欄、プロフィール設定ページなど、ユーザーが入力した内容をサーバー側で保存する機能を持つWebサイトにアクセスします。そして、入力フォームに悪意のあるスクリプトを書き込み、投稿します。
  2. サーバーへの格納: 脆弱なWebアプリケーションは、投稿されたスクリプトを無害化することなく、そのままデータベースなどに保存します。
  3. 他者の閲覧: 他の一般利用者が、その攻撃者がスクリプトを書き込んだページ（掲示板のスレッドやブログ記事など）を閲覧しようとアクセスします。
  4. スクリプトの配信と実行: Webサーバーは、リクエストに応じてデータベースからスクリプトを含んだデータを取り出し、HTMLに埋め込んで利用者のブラウザに送信します。利用者のブラウザは、そのページを表示する過程で、埋め込まれた不正なスクリプトを正規のものとして実行してしまいます。

【特徴】

  • 持続的な攻撃: スクリプトがサーバー上に保存されているため、誰かがそのページを閲覧するたびに攻撃が成立します。脆弱性が修正されるまで、攻撃は持続的に行われます。
  • 広範囲な被害: 反射型とは異なり、罠のURLをクリックする必要がありません。ただページを閲覧するだけで被害に遭うため、不特定多数の利用者が攻撃対象となり、被害が大規模化しやすいという非常に危険な性質を持っています。
  • Webサイトの信頼性の悪用: 利用者は信頼するサイトを普通に利用しているだけなので、攻撃を受けていることに気づくのは極めて困難です。このため、格納型XSSは反射型XSSよりも深刻な脅威と見なされています。

DOM Based XSS

DOM Based XSSは、サーバー側の処理を介さず、利用者のブラウザ内で動作するJavaScriptがDOM（Document Object Model）を不正に操作することによって発生する比較的新しいタイプのXSSです。攻撃のロジックがすべてクライアントサイドで完結するのが最大の特徴です。

【仕組み】

DOMとは、ブラウザがHTML文書を解釈して構築する、文書の構造を表現するツリー状のモデルのことです。JavaScriptは、このDOMを操作することで、Webページの内容を動的に書き換えることができます。

  1. 罠のURL作成: 攻撃者は、URLのフラグメント（#以降の部分）などを悪用して、不正なスクリプトを含むURLを作成します。例えば、https://example.com/page.html#<img src=x onerror=alert('XSS')>のようなURLです。URLフラグメントは、サーバーには送信されないという特徴があります。
  2. 利用者の誘導: 反射型と同様に、攻撃者はこのURLを利用者にクリックさせます。
  3. クライアントサイドでの処理: 利用者がURLにアクセスすると、ブラウザはexample.comからpage.htmlを読み込みます。このページには、URLフラグメントの値を取得して、ページ内の特定の要素（例：<div>タグの中身）に書き出すようなJavaScript（例：document.getElementById('content').innerHTML = location.hash.substring(1);）が含まれています。
  4. DOMの改ざんとスクリプト実行: このJavaScriptが、URLフラグメントに含まれる不正なスクリプト（<img src=x onerror=...>）をDOMに書き込みます。ブラウザがこの書き込まれたHTML片を解釈する際に、onerrorイベントハンドラ内のスクリプトが実行されてしまいます。

【特徴】

  • サーバー非関与: 攻撃のペイロード（不正なスクリプト）はサーバーに送信されず、サーバーのレスポンスにも含まれません。すべての処理がクライアントサイド（ブラウザ内）で完結します。
  • 検知の困難さ: サーバー側のログには攻撃の痕跡が残らないため、WAF（Web Application Firewall）などのサーバーサイドのセキュリティ製品では検知・防御が非常に困難です。
  • 根本原因はクライアントサイドのコード: 脆弱性の原因は、サーバー側のプログラムではなく、フロントエンドのJavaScriptの不適切な実装にあります。

これら3つのタイプは、それぞれ異なるアプローチを取りますが、最終的に「利用者のブラウザ上で意図しないスクリプトを実行させる」という点で共通しています。開発者は、これらすべてのパターンを想定した上で、堅牢なセキュリティ対策を実装する必要があります。

クロスサイトスクリプティングによって引き起こされる被害

Cookie情報の盗難とセッションハイジャック、個人情報や機密情報の漏えい、Webサイトの見た目の改ざん、悪意のあるサイトへの誘導（フィッシング詐欺）、マルウェアへの感染

クロスサイトスクリプティング（XSS）の脆弱性が悪用されると、Webサイトの利用者や運営者に多岐にわたる深刻な被害がもたらされます。攻撃者は、利用者のブラウザを乗っ取ることで、さまざまな不正行為を働くことが可能になります。ここでは、XSSによって引き起こされる代表的な被害を5つ紹介します。

Cookie情報の盗難とセッションハイジャック

最も代表的で危険な被害が、Cookie情報の盗難と、それに続く「セッションハイジャック」です。

多くのWebサービスでは、ユーザーがログインすると「セッションID」という一意の識別子を発行し、それをCookieに保存します。利用者のブラウザは、以降のリクエストのたびにこのセッションIDをサーバーに送信することで、ログイン状態を維持しています。つまり、セッションIDは「ログインしている本人であることの証明書」のようなものです。

XSS攻撃では、不正なスクリプト（例: document.cookie）を使ってこのCookie情報を読み取り、攻撃者が管理する外部のサーバーへ送信することが可能です。セッションIDを盗んだ攻撃者は、そのIDを自身のブラウザに設定することで、正規の利用者になりすましてWebサービスにログインできてしまいます。これをセッションハイジャックと呼びます。

セッションハイジャックが成功すると、攻撃者は被害者アカウントで以下のような不正行為を行えます。

  • 登録されている個人情報（氏名、住所、電話番号など）の閲覧・変更
  • ECサイトでの不正な商品購入
  • SNSアカウントでの不適切な投稿やメッセージ送信
  • オンラインバンキングでの不正送金

このように、アカウントが乗っ取られることで、プライバシーの侵害から金銭的な被害まで、極めて深刻な事態に発展する恐れがあります。

個人情報や機密情報の漏えい

XSSは、Cookie情報だけでなく、Webページ上に入力されるあらゆる情報を盗み出すことが可能です。

例えば、お問い合わせフォームや会員登録フォームにXSS脆弱性があった場合、攻撃者はキーボードの入力イベントを監視するスクリプト（キーロガー）を仕掛けることができます。利用者がフォームに氏名、メールアドレス、パスワード、クレジットカード番号などを入力すると、その内容がWebサーバーに送信される前に、リアルタイムで攻撃者のサーバーに送信されてしまいます。

この手口は、正規のWebサイト上で実行されるため、SSL/TLSによる通信の暗号化（URLがhttpsで始まるサイト）も意味をなしません。暗号化される前の平文のデータが盗まれてしまうからです。

また、企業向けのWebアプリケーション（グループウェアや顧客管理システムなど）にXSS脆弱性があった場合、従業員がアクセスすることで、ページに表示されている顧客情報や社外秘のプロジェクト情報などが丸ごと攻撃者に漏えいするリスクも考えられます。

Webサイトの見た目の改ざん

XSSで実行されるスクリプトは、Webページの見た目、すなわちDOM（Document Object Model）を自由に書き換えることができます。これにより、Webサイトの改ざんが可能になります。

例えば、以下のような改ざんが行われる可能性があります。

  • 偽情報の掲載: 企業の公式サイトのトップページに、事実無根の不祥事に関する謝罪文や、偽の製品リコール情報を掲載する。これにより、企業の社会的信用は大きく損なわれます。
  • 不適切なコンテンツの表示: サイト上に、わいせつな画像や差別的なメッセージを表示させる。
  • 偽の警告メッセージ: 「あなたのPCはウイルスに感染しています」といった偽の警告を表示し、利用者の不安を煽って偽のセキュリティソフトを購入させようとする。

これらの改ざんは、格納型XSSの場合はサイトを訪れた不特定多数の利用者に影響を与え、反射型XSSやDOM Based XSSの場合は、罠のリンクをクリックした特定の利用者にだけ改ざんされたページを見せることができます。いずれにせよ、Webサイトの信頼性を著しく低下させる行為です。

悪意のあるサイトへの誘導（フィッシング詐欺）

XSSは、フィッシング詐欺の巧妙な手口としても利用されます。攻撃者は、スクリプトを使って利用者を悪意のある偽サイトへ強制的にリダイレクトさせることができます。

例えば、銀行の公式サイトにXSS脆弱性があったとします。攻撃者は、そのサイトのURLにスクリプトを仕込み、利用者を誘導します。利用者がそのURLをクリックすると、一瞬だけ本物の銀行のサイトが表示された後、見た目がそっくりなフィッシングサイトへ自動的に転送されます。

利用者は本物のサイトにアクセスしたと信じ込んでいるため、偽サイトであることに気づかずにIDやパスワード、暗証番号などを入力してしまい、金融情報が盗まれてしまいます。

また、リダイレクトさせる代わりに、本物のサイト上にスクリプトで偽のログインフォームをオーバーレイ表示させる手口もあります。URLは本物のままであるため、利用者は極めて騙されやすく、非常に危険です。

マルウェアへの感染

より悪質なケースでは、XSSが悪意のあるソフトウェア、すなわちマルウェア（ウイルス、スパイウェア、ランサムウェアなど）の感染経路として悪用されることがあります。

攻撃者は、スクリプトを利用して、利用者の意図に反してマルウェアを自動的にダウンロードさせたり、ブラウザやOSの別の脆弱性を突いてマルウェアを実行させたりします。これは「ドライブバイダウンロード攻撃」と呼ばれる手法の一種です。

一度マルウェアに感染してしまうと、PC内のファイルが人質に取られたり（ランサムウェア）、キーボード入力をすべて記録されたり（キーロガー）、遠隔操作されたり（RAT: Remote Access Trojan）と、被害はPC全体に及び、回復には多大な労力とコストがかかります。

これらの被害は単独で発生するだけでなく、複合的に発生することもあります。XSS脆弱性を放置することは、これらすべてのリスクを許容することと同義であり、Webサイト運営者にとってはいかに迅速な発見と修正が重要であるかがわかります。

他のサイバー攻撃との違い

サイバー攻撃には多種多様な手法が存在し、中にはクロスサイトスクリプティング（XSS）と混同されやすいものもあります。特に「SQLインジェクション」と「クロスサイトリクエストフォージェリ（CSRF）」は、Webアプリケーションの脆弱性を突く攻撃としてよく比較されます。これらの攻撃との違いを正確に理解することは、適切なセキュリティ対策を講じる上で非常に重要です。

攻撃手法 攻撃対象 攻撃内容 主な対策
クロスサイトスクリプティング (XSS) Webサイト利用者（ブラウザ） 不正なスクリプトを注入し、ブラウザ上で実行させることで、利用者の情報を盗んだり、意図しない操作を行わせたりする。 入出力値のエスケープ処理、入力値の検証、Content Security Policy (CSP) の設定
SQLインジェクション Webアプリケーションの背後にあるデータベースサーバー 不正なSQL文を注入し、データベースを不正に操作（情報の窃取、改ざん、削除など）する。 プレースホルダ（バインド変数）の使用、エスケープ処理、WAFの導入
クロスサイトリクエストフォージェリ (CSRF) Webアプリケーションサーバー（利用者の認証状態を悪用） ログイン状態の利用者に、意図しないリクエスト（投稿、購入、退会など）をサーバーへ送信させる。 トークンによるリクエストの検証、SameSite Cookie属性の設定、重要な操作前のパスワード再入力要求

SQLインジェクションとの違い

SQLインジェクションは、XSSと並んでWebアプリケーションの脆弱性を代表する攻撃手法ですが、その攻撃対象と目的は大きく異なります。

【攻撃対象の違い】

  • XSS: 攻撃対象は「Webサイトの利用者（のブラウザ）」です。脆弱なWebサイトはあくまで攻撃の踏み台であり、最終的な被害は利用者の側で発生します。
  • SQLインジェクション: 攻撃対象は「Webアプリケーションの背後にあるデータベースサーバー」です。攻撃者はWebアプリケーションを通じて、データベースを直接攻撃します。

【攻撃手法と目的の違い】

  • XSS: Webアプリケーションの入力フォームなどに「HTMLタグやJavaScriptコード」を注入（インジェクション）します。その目的は、注入したスクリプトを他の利用者のブラウザ上で実行させ、Cookieの窃取（セッションハイジャック）や個人情報の詐取、Webサイトの改ざんなどを行うことです。
  • SQLインジェクション: Webアプリケーションの入力フォームなどに「SQL文の断片」を注入します。SQLとは、データベースを操作するための言語です。攻撃者は、開発者が意図しない不正なSQL文を生成・実行させることで、データベースに格納されている情報をすべて盗み出したり（例：全顧客の個人情報漏えい）、データを改ざん・削除したりすることを目的とします。

【具体例での比較】

  • XSSの例: サイト内検索で <script>alert('XSS')</script> と入力する。すると、検索結果ページにこのスクリプトが埋め込まれ、ブラウザでアラートが表示される。
  • SQLインジェクションの例: ログインフォームのユーザーID欄に ' OR 'A'='A のような文字列を入力する。これにより、パスワード認証を回避して不正にログインする。

要するに、XSSはクライアントサイド（ブラウザ）への攻撃、SQLインジェクションはサーバーサイド（データベース）への攻撃と大別できます。どちらも入力値の扱いに関する脆弱性ですが、影響範囲と対策方法が異なるため、明確に区別して理解する必要があります。

クロスサイトリクエストフォージェリ（CSRF）との違い

クロスサイトリクエストフォージェリ（Cross-Site Request Forgery、略称：CSRFまたはXSRF）は、「サイトを横断する（クロスサイト）」という名前が似ているためXSSと混同されやすいですが、攻撃のメカニズムは全く異なります。

【信頼関係の悪用の違い】

  • XSS: 「Webサイトに対する利用者の信頼」を悪用します。利用者は「このサイトは安全だ」と信じてアクセスしますが、そのサイト上で不正なスクリプトが実行されてしまいます。
  • CSRF: 「利用者に対するWebサイトの信頼」を悪用します。Webサイト側は、正規のセッションIDを持つ利用者から送られてきたリクエストを「本人が意図したもの」と信頼して処理します。CSRFは、この信頼を逆手に取ります。

【攻撃の主体と仕組みの違い】

  • XSS: 攻撃の主体は「攻撃者が仕込んだスクリプト」です。このスクリプトが利用者のブラウザ上で能動的に悪事を働きます（例：Cookieを盗んで外部に送信する）。
  • CSRF: 攻撃の主体は「利用者本人」です。ただし、本人はその操作を意図していません。攻撃者は、利用者がログイン状態にあることを前提に、罠のWebページにアクセスさせます。そのページには、標的サイトへのリクエスト（例：パスワード変更、商品購入、SNSへの投稿など）を自動的に送信するようなフォームや画像タグが仕込まれています。利用者が罠ページを開くと、ブラウザは自動的にCookie（セッションID）を付けて標的サイトへリクエストを送信してしまい、意図しない操作が実行されてしまいます。

【攻撃の具体例】

  • XSSの例: 掲示板にスクリプトを書き込み、閲覧した人のCookieを盗む。
  • CSRFの例: 攻撃者が「面白い猫の画像」というタイトルの罠サイトを用意する。ログイン状態のAさんがそのサイトを見ると、裏ではAさんのSNSアカウントで「私は馬鹿です」と投稿するリクエストが自動的に送信されてしまう。

簡単に言えば、XSSは「ブラウザを乗っ取って情報を盗む攻撃」、CSRFは「利用者を騙して意図しない操作を代わりに実行させる攻撃」と整理できます。

XSSの主たる対策は「出力時のエスケープ」ですが、CSRFの主たる対策は、リクエストが正規の画面遷移を経て送信されたことを証明するための「トークン（推測困難な文字列）の埋め込みと検証」や、CookieのSameSite属性の設定となります。両者は関連しつつも異なる脆弱性であり、それぞれに応じた対策が必要です。

クロスサイトスクリプティングの脆弱性対策10選

クロスサイトスクリプティング（XSS）の脅威からWebサイトと利用者を守るためには、開発者側と利用者側の双方で適切な対策を講じる必要があります。特に、Webアプリケーションを提供する開発者側の責任は重大です。ここでは、具体的で実践的な脆弱性対策を10項目に分けて解説します。

①【開発者向け】Webページに出力するすべての要素をエスケープ処理する（サニタイジング）

これは、XSS対策の基本中の基本であり、最も重要な対策です。エスケープ処理（またはサニタイジング）とは、ユーザーからの入力値など、外部から与えられたデータをWebページに出力する際に、HTMLとして特別な意味を持つ文字（メタ文字）を、単なる文字列として表示される別の文字（文字実体参照）に変換する処理のことです。

具体的には、以下のような変換を行います。

  • < を &lt; に変換
  • > を &gt; に変換
  • & を &amp; に変換
  • " を &quot; に変換
  • ' を ' に変換

この処理により、仮に攻撃者が <script>alert('XSS')</script> という文字列を入力したとしても、Webページ上には <script>alert('XSS')</script> という文字列がそのまま表示されるだけで、スクリプトとして解釈・実行されることはありません。

重要なポイントは、「Webページに出力するすべての要素」に対して、「出力する直前」にこの処理を行うことです。URLのクエリパラメータ、フォームからの入力値、データベースから読み出した値、APIから取得した値など、プログラムの外部から渡されるすべてのデータを信頼せず、必ずエスケープ処理を施す習慣を徹底することが不可欠です。多くのプログラミング言語やフレームワークには、この処理を行うための標準関数（例: PHPの htmlspecialchars()、Python/Djangoのテンプレートエンジン、Ruby on Railsの h() ヘルパーメソッドなど）が用意されているため、これらを適切に利用しましょう。

②【開発者向け】入力値の検証を行う（バリデーション）

エスケープ処理が出口対策であるのに対し、バリデーションは入り口対策です。バリデーションとは、ユーザーからの入力値が、アプリケーションが想定しているデータの形式や種類、範囲に合致しているかを検証する処理です。

例えば、以下のような検証が考えられます。

  • 型チェック: 数値を受け付けるべき箇所に文字列が入力されていないか。
  • フォーマットチェック: メールアドレス、電話番号、郵便番号などが正しい形式か。
  • 文字種チェック: 半角英数字のみ、日本語のみなど、許可する文字の種類を検証する。
  • 範囲チェック: 年齢や個数などが、妥当な範囲内の数値か。

バリデーションを厳密に行うことで、そもそもスクリプトとして解釈されうるような記号（<, > など）を含む不正なデータがシステム内に登録されることを防ぎます。バリデーションの実装には、「ホワイトリスト方式」と「ブラックリスト方式」がありますが、セキュリティ上はホワイトリスト方式が強く推奨されます。ブラックリスト方式（例: <script>という文字列を禁止する）は、攻撃者が <img> タグや onerror 属性を使うなど、抜け道を見つけやすいため不完全です。一方、ホワイトリスト方式（例: 半角英数字のみを許可する）であれば、想定外の入力はすべて拒否されるため、より安全です。

③【開発者向け】入力値の文字数や種類を制限する

これはバリデーションの一環とも言えますが、特に意識すべき重要な対策です。氏名や電話番号など、入力されるデータの種類ごとにおおよその最大文字数は決まっています。不必要に長い文字列の入力を許可すると、攻撃者が複雑で長いスクリプトを送り込む余地を与えてしまいます。

データベースのカラム定義やHTMLの maxlength 属性、そしてサーバーサイドのプログラムで、各入力項目に対して現実的かつ適切な最大文字数を設定しましょう。 同様に、入力値として不要な記号（<, >, ", ' など）をそもそも受け付けないように制限することも、XSSのリスクを低減させる上で効果的です。

④【開発者向け】WAF（Webアプリケーションファイアウォール）を導入する

WAF（Web Application Firewall）は、Webアプリケーションの前面に設置され、送受信されるHTTP通信を監視し、サイバー攻撃と判断されるパターン（シグネチャ）を検知・遮断するセキュリティ製品です。

WAFを導入することで、XSS攻撃でよく使われる典型的なスクリプトのパターンを検知し、リクエストがWebアプリケーションに到達する前にブロックできます。これは、アプリケーション自体の脆弱性を修正する根本対策とは別に、多層防御の観点から非常に有効な対策です。万が一、アプリケーションに未知の脆弱性が存在した場合でも、WAFが防波堤となってくれる可能性があります。

ただし、WAFを導入したからといって、①のエスケープ処理などの根本対策が不要になるわけではありません。 WAFはあくまで保険的な役割であり、攻撃手法の進化によってはシグネチャをすり抜けられる可能性もあるため、両方の対策を組み合わせることが重要です。

⑤【開発者向け】CookieにHttpOnly属性を設定する

これは、XSSによる最も深刻な被害の一つであるセッションハイジャックを防ぐための、非常に効果的な対策です。サーバーがCookieを発行する際に HttpOnly という属性を付与すると、そのCookieはJavaScriptの document.cookie からアクセスできなくなります。

これにより、たとえWebサイトにXSS脆弱性が存在し、攻撃者に任意のスクリプトを実行されたとしても、セッションIDが格納されたCookieを盗み出すことができなくなります。 すべてのXSS攻撃を防ぐものではありませんが、アカウント乗っ取りという最悪の事態を防ぐ上で極めて重要な緩和策です。特別な理由がない限り、セッションIDを格納するCookieには必ず HttpOnly 属性を設定すべきです。

⑥【開発者向け】Content Security Policy（CSP）を設定する

Content Security Policy（CSP）は、ブラウザがWebページで読み込み、実行できるリソース（スクリプト、画像、CSS、フォントなど）を、サーバーがHTTPレスポンスヘッダで明示的に指定（ホワイトリスト化）する仕組みです。

例えば、Content-Security-Policy: script-src 'self' https://apis.google.com というヘッダを設定すると、ブラウザは自サイト（'self'）と https://apis.google.com から配信されるJavaScriptしか実行しなくなります。これにより、攻撃者がインラインスクリプトや未知のドメインからのスクリプトを注入しようとしても、ブラウザのレベルで実行をブロックできます。

CSPは設定が複雑な側面もありますが、反射型、格納型、DOM BasedのいずれのXSSに対しても強力な防御層となり、未知の脆弱性に対する緩和策としても機能するため、導入を強く推奨します。

⑦【開発者向け】脆弱性診断ツールで定期的にチェックする

人間による開発では、どうしても脆弱性の見落としが発生する可能性があります。そこで、脆弱性診断ツールを導入し、定期的に自社のWebサイトをスキャンすることが重要です。

脆弱性診断ツールは、Webサイトを自動的に巡回し、XSSの脆弱性が潜んでいる可能性のある箇所を擬似的に攻撃して、その応答を分析します。開発の早い段階（CI/CDパイプラインなど）で診断を組み込むことで、脆弱性を早期に発見し、修正コストを低く抑えることができます。

⑧【利用者向け】OSやブラウザを常に最新の状態に保つ

ここからは、Webサイトの利用者側ができる対策です。利用しているPCやスマートフォンのOS、そしてChrome、Firefox、SafariなどのWebブラウザは、常に最新のバージョンにアップデートしておきましょう。

近年のブラウザには、反射型XSSを検知してブロックする機能などが標準で搭載されています。また、ソフトウェアのアップデートには、既知の脆弱性の修正パッチが含まれていることがほとんどです。ソフトウェアを最新の状態に保つことは、XSSを含むさまざまなサイバー攻撃から身を守るための最も基本的で効果的な自己防衛策です。

⑨【利用者向け】不審なリンクやファイルを開かない

反射型XSSやDOM Based XSSの多くは、メールやSNSで送られてくる悪意のあるリンクをクリックすることから始まります。

  • 送信元に心当たりがないメールやメッセージ
  • 「当選おめでとうございます」「アカウントがロックされました」など、不安や欲望を煽る件名
  • 短縮URLなど、遷移先が不明なリンク

これらには特に注意し、安易にクリックしないようにしましょう。もしURLにカーソルを合わせた際に、ステータスバーに表示されるリンク先アドレスに %3Cscript%3E（<script>のURLエンコード）のような不審な文字列が含まれている場合は、XSS攻撃の可能性が高いです。

⑩【利用者向け】信頼できるセキュリティソフトを導入する

総合的なセキュリティソフト（アンチウイルスソフト）を導入することも有効な対策です。多くのセキュリティソフトには、悪意のあるスクリプトを検知・ブロックする機能や、フィッシングサイトやマルウェア配布サイトとして報告されている危険なWebサイトへのアクセスを未然に防ぐ機能が備わっています。OSやブラウザの保護機能に加えて、専門のセキュリティソフトを導入することで、より多層的な防御が可能になります。

自社サイトにXSS脆弱性がないか確認する方法

自社で運営するWebサイトやWebアプリケーションにクロスサイトスクリプティング（XSS）の脆弱性が存在しないかを確認することは、安全なサービス提供と企業の信頼性維持のために不可欠です。確認方法には、専門家の知識と経験に頼る「手動診断」と、ツールを用いて機械的にチェックする「ツール診断」の2つが主流です。それぞれにメリット・デメリットがあり、両者を組み合わせることで、より精度の高い診断が実現できます。

診断方法 メリット デメリット おすすめのシーン
専門家による手動診断 ・高精度で信頼性が高い
・ツールの自動検知では見つけられない複雑なロジックの脆弱性を発見できる
・ビジネスロジック上の欠陥も指摘可能
・誤検知が極めて少ない		 ・コストが高い
・診断に時間がかかる（数週間～数ヶ月）
・診断員のスキルに品質が依存する		 ・金融機関など高いセキュリティ要件が求められるサイト
・サービスのローンチ前や大規模な改修後の最終確認
・定期的な第三者による客観的な評価が必要な場合
脆弱性診断ツール ・低コストまたは無料で利用可能
・短時間で広範囲を網羅的にスキャンできる
・開発の初期段階から繰り返し実行できる
・人的リソースを割かずに定期的なチェックが可能		 ・検知漏れや誤検知が発生する可能性がある
・複雑な仕様や動的なページの診断は苦手な場合がある
・検出された脆弱性の危険度判断には専門知識が必要		 ・開発プロセス（CI/CD）へのセキュリティチェックの組み込み
・日常的なセキュリティレベルのヘルスチェック
・大規模なWebサイトの全体的な脆弱性の洗い出し

専門家による手動診断

専門家による手動診断は、セキュリティの専門家（ホワイトハッカー、ペネトレーションテスターなど）が、実際の攻撃者の視点に立って、Webアプリケーションの脆弱性を探し出す方法です。診断員は、アプリケーションの仕様やビジネスロジックを深く理解した上で、ツールでは検知できないような巧妙な脆弱性を洗い出します。

【診断プロセス】
手動診断は一般的に、以下のような流れで進められます。

  1. ヒアリングと計画: 診断対象の範囲（URL、機能）、アプリケーションの仕様、ビジネス上の重要機能などをヒアリングし、診断計画を策定します。
  2. 情報収集: 対象のWebサイトの構造、使用されている技術（フレームワーク、ミドルウェアなど）を分析します。
  3. 脆弱性診断の実施: 計画に基づき、さまざまな疑似攻撃を試みます。XSSに関しては、あらゆる入力箇所（URLパラメータ、フォーム、HTTPヘッダなど）に多種多様なペイロード（攻撃用コード）を送り込み、その応答や挙動を詳細に分析します。特に、複数のステップを経て初めて発現するような、複雑なロジックを持つ格納型XSSやDOM Based XSSの発見に強みを発揮します。
  4. 報告と提言: 発見された脆弱性について、その内容、危険度、再現手順、そして具体的な対策方法をまとめた報告書が提出されます。単に脆弱性を指摘するだけでなく、なぜその脆弱性が生まれたのか、今後同様の脆弱性を生まないためにはどうすれば良いか、といった開発プロセス改善への提言が含まれることもあります。

【メリットと価値】
手動診断の最大の価値は、その「精度の高さ」と「思考力」にあります。ツールは決められたパターンしか試せませんが、専門家はアプリケーションの挙動から新たな攻撃ベクトルを推測し、創造的な方法で脆弱性を探します。例えば、「ユーザー権限によって表示内容が変わるページ」でのみ発生するXSSなど、アプリケーションの文脈を理解していなければ発見できない脆弱性を見つけ出すことができます。誤検知が少ないため、開発者は報告された内容に集中して修正作業に取り組めるという利点もあります。

脆弱性診断ツールを利用する

脆弱性診断ツールは、プログラムによって自動的にWebサイトを巡回し、既知の脆弱性パターンに合致する箇所がないかをスキャンする方法です。近年では、クラウド型（SaaS）のサービスとして提供されることが多く、手軽に利用を開始できます。

【ツールの種類と仕組み】
脆弱性診断ツールは、大きく分けて2つのタイプがあります。

  • DAST (Dynamic Application Security Testing): 実際に動作しているWebアプリケーションに対して、外部からHTTPリクエストを送信して脆弱性を診断するツールです。「動的診断」とも呼ばれ、ブラックボックステストに分類されます。今回紹介しているXSSの確認方法としては、このDASTが一般的です。
  • SAST (Static Application Security Testing): アプリケーションのソースコードを直接解析して脆弱性を診断するツールです。「静的診断」とも呼ばれ、ホワイトボックステストに分類されます。

DASTツールは、Webサイトのリンクを辿ってページを収集し（クローリング）、各ページの入力フォームやパラメータに対して、XSS攻撃で使われるペイロードを大量に送信します。そして、サーバーからのレスポンスにそのペイロードがそのまま含まれているか、あるいは特定のJavaScriptが実行されたことを示す痕跡がないかをチェックすることで、脆弱性を検出します。

【メリットと活用シーン】
ツール診断の最大のメリットは、「コスト効率」と「スピード」です。手動診断に比べてはるかに安価で、かつ短時間で広範囲をスキャンできます。この特性を活かし、開発のライフサイクルに診断を組み込む「DevSecOps」のアプローチが注目されています。例えば、ソースコードが更新されるたびに自動的に診断ツールを起動し、新たな脆弱性が混入していないかをチェックすることで、問題の早期発見・早期修正が可能になります（シフトレフト）。

手動診断を「年に一度の精密な人間ドック」、ツール診断を「日常の血圧測定」と考えると分かりやすいでしょう。両者は対立するものではなく、互いに補完し合う関係にあります。コストや開発フェーズに応じて適切な方法を選択し、組み合わせていくことが、効果的な脆弱性管理の鍵となります。

おすすめのXSS脆弱性診断ツール・サービス

自社サイトのXSS脆弱性を効率的かつ効果的に確認するためには、信頼できる脆弱性診断ツールやサービスの活用が欠かせません。ここでは、国内で実績があり、それぞれに特色のある代表的な3つのツール・サービスを紹介します。選定にあたっては、自社の開発体制、予算、求めるセキュリティレベルなどを考慮することが重要です。

ツール名 提供会社 主な特徴 こんな場合におすすめ
Securio（セキュリオ） LRM株式会社 脆弱性診断だけでなく、情報セキュリティ教育やISMS認証コンサルティングまでをワンストップで提供。ツールと専門家の手動診断を組み合わせた手厚いサポートが強み。 専門家による客観的な評価や、セキュリティ体制全体の強化、認証取得も視野に入れている企業。
VAddy（ヴァディ） 株式会社ビットフォレスト CI/CD（継続的インテグレーション/継続的デリバリー）連携に特化した、開発者向けの高速クラウド型自動脆弱性診断ツール。設定が簡単で、日々の開発フローに組み込みやすい。 Agile/DevOpsといった高速な開発サイクルを採用しており、開発の早い段階で継続的にセキュリティチェックを行いたいWebサービス開発企業。
AeyeScan（エーアイスキャン） 株式会社エーアイセキュリティラボ AIとRPA技術を駆使し、従来ツールが苦手としていたログイン後の動的なWebアプリケーションの診断を自動化。高い巡回カバレッジと少ない誤検知を実現。 JavaScriptを多用したSPA（Single Page Application）など、ログインが必要で画面遷移が複雑なモダンなWebアプリケーションを効率的に診断したい企業。

Securio（セキュリオ）

Securioは、LRM株式会社が提供する情報セキュリティ関連の総合プラットフォームです。そのサービスの一つとして、高品質な脆弱性診断を提供しています。

【特徴】
Securioの脆弱性診断の最大の特徴は、単なるツールの提供に留まらず、専門家によるコンサルティングを含めたトータルサポートを受けられる点にあります。

  • ツールと手動のハイブリッド診断: 自動診断ツールによる網羅的なスキャンと、セキュリティ専門家による手動診断を組み合わせることで、精度の高い診断を実現します。ツールでは見逃しがちなビジネスロジックの脆弱性なども発見可能です。
  • 分かりやすい報告書: 検出された脆弱性について、危険度、再現手順、具体的な修正方法などを分かりやすくまとめた報告書が提供されます。専門家でない担当者でも理解しやすいように工夫されています。
  • 脆弱性管理から先のサポート: 診断後のセキュリティ対策や、ISMS/Pマークなどの認証取得支援、従業員向けのセキュリティ教育まで、企業のセキュリティレベルを総合的に向上させるためのサービスが充実しています。

【おすすめするケース】
「脆弱性を発見して終わり」ではなく、その後の対策や社内のセキュリティ体制構築までを一貫して専門家に相談したい企業に最適です。特に、初めて脆弱性診断を実施する企業や、セキュリティ担当者がいない企業にとって、心強いパートナーとなるでしょう。

参照：LRM株式会社 Securio公式サイト

VAddy（ヴァディ）

VAddyは、株式会社ビットフォレストが開発・提供する、開発プロセスへの統合（CI/CD連携）に特化したクラウド型のWeb脆弱性診断ツールです。

【特徴】
VAddyは、”Shift Left”（開発のできるだけ早い段階でセキュリティ対策を行う）の思想を体現したツールであり、以下のような特徴を持っています。

  • 高速スキャンと簡単なセットアップ: 診断のセットアップが非常に簡単で、スキャンも数分から数十分と高速です。これにより、開発者はコードを修正するたびに気軽に脆弱性チェックを実行できます。
  • CI/CDツールとの強力な連携: Jenkins、CircleCI、GitHub Actionsといった主要なCI/CDツールと簡単に連携できます。開発パイプラインにVAddyのスキャンを組み込むことで、脆弱性の混入を自動的に検知し、デプロイをストップするといった運用が可能です。
  • 開発者にフォーカスした設計: 診断結果はシンプルで分かりやすく、どのリクエストのどのパラメータに問題があったかが明確に示されるため、開発者は迅速に修正作業に取り掛かれます。

【おすすめするケース】
アジャイル開発やDevOpsを実践しており、開発スピードを落とさずにセキュリティを確保したいと考えている企業に強く推奨されます。開発者自身が日常的に使うツールとして設計されているため、開発チーム主導でセキュリティを向上させていきたい場合に非常に有効です。

参照：株式会社ビットフォレスト VAddy公式サイト

AeyeScan（エーアイスキャン）

AeyeScanは、株式会社エーアイセキュリティラボが提供するSaaS型の自動Webアプリケーション脆弱性診断ツールです。AI技術を活用することで、従来は手動診断でしか対応が難しかった領域の自動化を目指しています。

【特徴】
AeyeScanのコア技術は、AIによる高精度な画面遷移の自動検知にあります。

  • 動的サイトへの強み: JavaScriptを多用するSPA（Single Page Application）や、操作手順が複雑な業務システムなど、従来のクローラーが苦手としていた動的なWebサイトでも、AIが人間のように画面を認識し、自動で巡回して診断範囲を広げます。
  • 高い診断精度と低い誤検知: AIがページの構造や文脈を理解して検査を行うため、従来のツールに比べて誤検知が少なく、より本質的な脆弱性を発見する能力に長けています。
  • 使いやすさ: クラウドサービスのため、特別なインストールは不要です。診断対象のURLを登録するだけで、誰でも簡単に高精度な診断を開始できます。

【おすすめするケース】
ログイン機能があり、内部のページが複雑に連携しているようなWebアプリケーション（例：会員制サイト、ECサイトの管理画面、SaaSプロダクト）を運営している企業に最適です。手動診断のコストを抑えつつ、動的なサイトのカバレッジを最大限に高めたい場合に大きな効果を発揮します。

参照：株式会社エーアイセキュリティラボ AeyeScan公式サイト

これらのツールは、それぞれに無料トライアルやフリープランが用意されている場合が多いため、まずは実際に試してみて、自社のWebサイトや開発スタイルとの相性を確認してみることをお勧めします。

まとめ

本記事では、Webアプリケーションにおける深刻な脅威である「クロスサイトスクリプティング（XSS）」について、その基本的な概念から、攻撃の仕組み、具体的な被害、そして開発者・利用者双方の視点からの対策までを網羅的に解説しました。

最後に、この記事の要点を改めて整理します。

  • XSSとは、脆弱性のあるWebサイトを踏み台にして、利用者のブラウザ上で悪意のあるスクリプトを実行させる攻撃です。Webサイトへの信頼を悪用する巧妙な手口であり、被害が深刻化しやすい特徴があります。
  • XSSには大きく分けて3つの種類が存在します。URLを介して一時的に攻撃する「反射型XSS」、サーバーにスクリプトを保存し不特定多数に影響を及ぼす「格納型XSS」、そしてブラウザ内で完結する「DOM Based XSS」です。それぞれの仕組みを理解し、対策を講じることが重要です。
  • XSSによって引き起こされる被害は、Cookie盗難によるセッションハイジャック（アカウント乗っ取り）をはじめ、個人情報や機密情報の漏えい、Webサイトの改ざん、フィッシング詐欺サイトへの誘導、マルウェア感染など、極めて多岐にわたります。
  • 開発者が取るべき対策の根幹は、「Webページに出力するすべての要素をエスケープ処理する」ことです。これに加えて、入力値のバリデーション、HttpOnly属性やContent Security Policy（CSP）の設定、WAFの導入といった多層的な防御を組み合わせることで、Webサイトの堅牢性を高めることができます。
  • 利用者側も、OSやブラウザを常に最新の状態に保ち、不審なリンクを安易に開かないといった基本的なセキュリティ対策を徹底することが、自身を被害から守る上で不可欠です。

Webサイトの脆弱性は、企業の信頼を揺るがし、利用者に多大な損害を与える直接的な原因となります。XSS対策は、もはや専門家だけのものではなく、Webに関わるすべての人がそのリスクを認識し、それぞれの立場で責任を果たすべき課題です。

定期的な脆弱性診断によって自社サイトの状態を客観的に把握し、セキュアコーディングを開発プロセスに根付かせること。それが、安全で信頼されるWebサービスを提供し続け、デジタル社会の健全な発展に貢献するための第一歩となるでしょう。