XSS（Cross-Site Scripting、クロスサイトスクリプティング）は、攻撃者が用意したJavaScriptコードを、被害者がアクセスする正規Webサイトの応答に紛れ込ませ、そのサイトを開いた利用者のブラウザ上で実行させる脆弱性です。1990年代後半にマイクロソフトのセキュリティチームやCERT/CCの公開情報を通じて概念が整理され、OWASP Top 10には初版（2003年）から長年掲載され続けてきました。Cookieの窃取によるセッション乗っ取り、フィッシング画面の差し込み、ブラウザ内マイニングなど、「信頼の差し替え」を起点としたあらゆる悪用に発展する、Webセキュリティの基礎的な脅威です。
この記事の目次
- 反射・格納・DOMの三類型
- Samyワームから現代の事例まで
- 出力エスケープとCSPで多層防御
- CSRF・SQLインジェクションとの違い
- まとめ
反射・格納・DOMの三類型
XSSは入力経路と保存場所の違いによって反射型・格納型・DOM型の3類型に分けられます。反射型はURLのクエリ文字列やフォームに混入させたスクリプトが、検索結果ページなどにそのまま出力される形で発動します。攻撃者は罠リンクをメールやSNSで配布し、被害者がそのリンクを踏んだ瞬間に正規ドメイン上でスクリプトが走る、という流れです。格納型は掲示板・口コミ・プロフィール欄など、サーバ側のデータベースに書き込まれた悪意の入力が、別の閲覧者へのレスポンスにまで持ち回られて発動します。閲覧するだけで感染が広がる「ワーム型XSS」の典型例が、2005年のMySpace Samyワームです。
DOM型XSSは、サーバが返すHTMLには問題が無いのに、ブラウザ側のJavaScriptがlocation.hashやdocument.referrerなどの値を無防備にinnerHTMLへ差し込んだ結果、クライアント側だけで完結して発動するタイプです。SPA（シングルページアプリケーション）の普及とともに割合が増し、サーバログだけを眺めていても気付きにくいため検出が難しいとされます。ブラウザ側のセキュリティ研究者Amit Klein氏が2005年に発表した論文で初めて「DOM Based Cross-Site Scripting」という呼称が定着しました。
Samyワームから現代の事例まで
XSSの代表的な歴史的事件として真っ先に挙げられるのが、2005年10月に発生したMySpace Samyワームです。サミー・カムカル氏が自分のプロフィールに格納型XSSのコードを仕込んだところ、プロフィールを閲覧した利用者のアカウントにも自動的にそのコードが複製され、わずか20時間で100万を超えるアカウントが「Samy is my hero」という文字列を持つに至りました。刑事訴追にまで発展した事件で、SNS時代における格納型XSSの破壊力を世界に示した節目となっています。
その後もTwitterのonMouseover攻撃（2010年）、Yahoo! Mailの脆弱性によるアカウント乗っ取り、eBayのリスティング欄を悪用したフィッシングなど、大手サービスでXSSによるインシデントが繰り返されてきました。OWASP Top 10では2017年版で「インジェクション」傘下に整理された後も常連であり、現代でもブラウザ拡張機能、広告タグ、CMSプラグイン経由のXSSが頻繁に報告されています。「古典的だが消えない脆弱性」の代表として、四半世紀にわたり警戒対象であり続けています。
出力エスケープとCSPで多層防御
XSS対策の中核は、入力ではなく出力の段階で「データを実行可能なコードに化けさせない」ことです。HTML本文、属性値、JavaScriptリテラル、URL、CSSといった文脈ごとに必要なエスケープが異なり、現代では React、Vue、Angular、Djangoテンプレート、Thymeleafなどが標準で文脈別の自動エスケープを行います。innerHTMLや危険なdangerouslySetInnerHTMLを避け、テキスト挿入はtextContentに寄せる、URLはallowlistで検証する、といった原則を徹底するだけでも多くの脆弱性が消えます。
アプリ側の修正と並行して、Content Security Policy（CSP）ヘッダによるブラウザ側の多層防御が重要です。script-srcでnonceやhashを指定し、外部ドメインから無秩序にスクリプトを読み込ませない設定にすれば、万一エスケープ漏れがあってもインライン実行や外部呼び出しを止められます。セッション関連のCookieにはHttpOnly属性を付け、JavaScriptから読めなくしておくとセッション窃取の被害も抑えられます。ライブラリ依存性の見直し、広告タグや解析タグの定期棚卸しも欠かせない実務です。
CSRF・SQLインジェクションとの違い
XSSは「Webサイトの応答にスクリプトを潜り込ませ、閲覧者のブラウザで実行させる」という、クライアント側の信頼関係を悪用する攻撃です。これに対しCSRF（クロスサイトリクエストフォージェリ）は、被害者が既に認証済みのサイトに対し、別サイトに仕込まれた罠から強制的に何らかのリクエストを送らせる攻撃で、スクリプト実行よりも「正規ユーザーになりすました操作」に主眼があります。ただし、XSSが成立しているサイトではCSRFトークンも盗まれてしまうため、両者は併発しがちです。
SQLインジェクションは入力をDBクエリに混入させて取得や改ざんを行う「サーバ側」の脆弱性で、クライアントのブラウザを介さなくても被害が成立する点でXSSとは射程が異なります。クリックジャッキングは透明iframeで操作を盗む別系統の攻撃で、これも実行コードの注入ではなくUI上の錯覚を狙うものです。XSSはこれらと「Webアプリの脆弱性」という枠を共有しつつ、標的が閲覧者ブラウザ、武器がJavaScriptという点で独自の位置を占めています。
まとめ
XSSは四半世紀にわたりWebセキュリティの最前線にあり続ける古典的脆弱性です。出力時の文脈別エスケープ、CSPによるブラウザ側統制、HttpOnly Cookieによるセッション保護を重ねれば、現代のWebアプリケーションでも十分に抑え込めます。「入力検証より出力制御」という原則を、設計初期から徹底することが何より大切です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント