2024年4月、ある有名人のライブ配信に書き込まれたたった一件の悪意あるコメントが、 9万件もの視聴者セッションを乗っ取りました。攻撃者が仕込んだ短いスクリプトが YouTubeのクッキーを盗み出し、ファンを暗号資産の詐欺サイトへ飛ばし、 勝手な購入の波を引き起こしたのです。これはゼロデイではなく、 1990年代から延々とウェブに付きまとってきた、ごく古典的なクロスサイトスクリプティングの不具合でした。
XSSがニュースの見出しを飾ることはほとんどありません。ディスクにマルウェアが残らないからです。 ブラウザのなかで静かに動いてはデータを抜き、表示を書き換え、信頼につけ込んでいきます。 その仕組みと、どう防ぎ、どう封じ込めるかを理解しておくことは、 開発者にとっても、ふつうにブラウザを使うだけのユーザーにとっても、いまだに欠かせません。
XSSをかみ砕いて説明
クロスサイトスクリプティングとは、攻撃者がうまく仕向けて、 ほかのユーザーが見るページに悪意あるスクリプトをウェブサイト側に埋め込ませてしまう攻撃です。 ブラウザはそのスクリプトを信頼します。配信元が正規のドメインだからです。 そしてスクリプトは被害者の権限で動き、クッキーやセッショントークン、 ページの中身、DOM要素などに手を伸ばしていきます。
ふだんコードを書かない人向けに、たとえてみます。会社の掲示板にポストイットが貼られる場面を思い浮かべてみてください。 誰も掲示板を見張っていなければ、偽の指示を貼り付けて同僚にそのとおり動いてもらうこともできてしまいます。 XSSはそのデジタル版です。信頼できない中身が、信頼されているはずの場所にこっそり紛れ込んでくる、ということですね。
主な3つのタイプ（プラス少しの例外）
XSSのタイプを押さえておくと、脆弱性の切り分けがぐっと速くなります。主要なタイプは3つで、 これに加えて、現実の攻撃キャンペーンに今もたびたび顔を出す例外がいくつかあります。
Stored XSS。悪意あるスクリプトがサーバー側 （データベースやCMSなど）に保存され、訪問してきたユーザー全員に配信されてしまうタイプです。 コメント欄やサポートのチケットシステムが舞台になりがちです。 ページを開いたユーザー全員がpayloadを踏むことになるので、影響範囲は大きくなりやすいのが特徴です。
Reflected XSS。悪意あるスクリプトが、サーバーからの応答にそのまま乗って跳ね返ってくるタイプです。 典型的にはURLパラメータ経由で起こります。被害者が細工されたリンクをクリックすると、サーバーが入力をそのままページに書き戻し、 そこでpayloadが実行されてしまいます。
DOMベースのXSS。payloadがサーバーまで届くことはなく、 DOMを書き換えながらブラウザのなかだけで完結します。サーバー側がまったく気づかないこともあり、 そのぶん検知が難しい。インシデントレポートにこのタイプがくり返し顔を出すのは、まさにこのためです。
self-XSS（ユーザー自身にコンソールへスクリプトを貼らせる手口）や、 XS-Search（検索フォームを悪用して内部状態を推測する手口）も、いまの攻撃に登場し続けています。 防御の考え方は、結局のところ古典的なXSS対策と大きく重なります。
XSS攻撃の流れをステップごとに
典型的なexploitの連鎖を追ってみると、どこにコントロールを挟めば連鎖を断てるかが見えてきます。
- 1
入力の受け口を見つける
攻撃者はまず、まともなサニタイズを経ずに入力を返してしまうフォームや、 URLパラメータ、保存フィールドを探します。 - 2
payloadを組み立てる
クッキーを盗む、DOMを書き換える、マルウェアを読み込ませる、 トラフィックを別サイトに飛ばす、といったJavaScriptを書きます。 - 3
payloadを送り込む
細工したリンク、乗っ取ったアカウント、すでにサーバーに残してある投稿などを経由します。 - 4
被害者のブラウザで実行させる
正規のドメインから配信されてくるので、ブラウザはそのpayloadを疑いません。 - 5
データを抜き取る、あるいは横に広げる
スクリプトは盗んだデータを攻撃者側のエンドポイントへ送り、さらにマルウェアを追加で仕込みにいきます。
攻撃者が手に入れるもの
XSSはもはや単なるdefacementでは終わりません。 いまのキャンペーンはこれを軸にインパクトの大きい攻撃を仕掛けてきます。なかでもよく見かけるのが、次の4つです。
セッションの乗っ取り。認証トークンを盗み出し、 バンキングポータルや管理ダッシュボード、SaaSサービスでユーザーになりすまします。 本人は盗まれたことに最後まで気づきません。
認証情報の窃取。偽のログインフォームを挿し込んだり、 すでにあるフォームを書き換えたりして、本物の送信が走る前にユーザー名とパスワードをブラウザ内で奪い取ります。
マルウェアの配信。外部のスクリプトを呼び込ませて、 ランサムウェアや暗号資産マイナーを送り込みます。信頼されていたサードパーティスクリプトが乗っ取られるサプライチェーン攻撃では、とくに効きます。
ソーシャルな揺さぶり。表示を書き換えたり、 チャットにメッセージを混ぜ込んだりして、ユーザーを危ない操作や送金へと誘導します。 信頼しているサイトから「送金してください」と言われれば、ユーザーは送金してしまうものです。
さまざまな業界の実例5件
ここで紹介するインシデントは、公的な開示資料や業界メディアの報道をもとにしたもので、XSSがどれだけ幅広い被害につながりうるかを示しています。
メディアプラットフォーム（2024年）。コメントモデレーションに潜んでいたXSSを使い、 攻撃者が詐欺チャンネルに対して自動でいいねを付けて回っていました。 評判への打撃は実害となって表れ、サブスクライバーの信頼指標は7%低下、復旧作業には1週間を要しました。
ECサイトのマーケットプレイス（2023年）。クーポンコードに残っていたreflected XSSが、 買い物客をフィッシングのチェックアウトページに誘導していました。被害額は410万ドル。 チームがパターンに気づくまでのあいだに、それだけの不正請求が積み上がってしまいました。
医療系の患者ポータル（2022年）。患者メッセージング機能に仕込まれたstored XSSが、 セッションクッキーを盗み出し、検査結果まで露出させました。 最終的にはHIPAA違反の通知と120万ドルの和解にまで至っています。
バンキングアプリ（2021年）。ウィジェット経由のDOMベースXSSが、 身に覚えのない送金リクエストを差し込んでいました。SOCが素早く動いたおかげで金銭的損失は防げたものの、 インシデントをきっかけに数か月にわたる規制当局の監査が始まりました。
行政のCMS（2020年）。レガシーCMSに眠っていた古いXSSが原因で、 自治体のCOVID-19関連の告知ページがdefacementされてしまいました。 損害は金額ではなく、危機のさなかに失われた公共からの信頼として計上されたケースです。
なぜ2025年になってもXSSは消えないのか
モダンなフレームワークが揃っているにもかかわらず、XSSは毎年OWASP Top 10に顔を出し続けています。 理由は技術的というより、構造的なものです。
巨大なコードベースの内側では、いまも文字列連結や古いテンプレートエンジンが現役で動いています。 サードパーティのウィジェット（マーケティングピクセル、チャットボット、アナリティクス）は、 セキュリティチームの手が届かない攻撃面を新たに持ち込みます。新しく加わったエンジニアリングチームは、 そのコードを形づくった過去のインシデントを知らないまま、安全でないパターンを引き継いでしまいます。 自動スキャナーは、サーバー側でレンダリングされた出力を対象に走るため、実際に生きているDOMは見ておらず、 DOMベースのpayloadは取り逃がしがちです。そして手動のペンテストは、なぜかいつも別のところを見ています。
日常でできる防御
インターネット全体にパッチを当てることはできませんが、被害が広がる範囲を狭めることはできます。 4つの習慣を押さえておけば、現実的なリスクのほとんどはカバーできます。
信頼できないリンクはBrowser.lolのなかで開いて、自分のマシン上でスクリプトを走らせないようにしてください。 使っていないブラウザ拡張は無効にしておきます。多くの拡張がXSSの攻撃面を広げてしまうからです。 ブラウザは常に最新の状態に保ちましょう。新しいCSP（Content Security Policy）は、 インラインスクリプトや古いXSSのテクニックをまとめてブロックしてくれます。 使っていないときは、機密性の高いサイトからは必ずログアウトしておくこと。 セッションが早めに切れていれば、たとえクッキーを盗まれたとしてもすぐに無価値になります。
開発者とセキュリティチーム向けチェックリスト
Webアプリを開発・運用する立場なら、効きが大きいのはこの5つです。
出力はコンテキストごとにescapeする。 HTML、JavaScript、URL、CSSはそれぞれ違うescapingルールを必要とします。 ひとつの汎用「sanitize」関数で済まそうとすると、ほぼ確実にどこかのカテゴリを取りこぼします。
サニタイズが組み込まれたフレームワークを使う。 React、Vue、AngularはDOMを直接いじる必要を減らし、安全な書き方をデフォルトの選択肢にしてくれます。
Content Security Policyを導入する。 スクリプトの読み込み元を絞り込み、できる限りインラインスクリプトは禁止しましょう。 CSPは、これまでブラウザに搭載されてきた防御の中でも、もっとも費用対効果の高いもののひとつです。
セキュリティ志向のlinterとSASTを取り入れる。 ESLintのセキュリティプラグインや、Semgrep、SonarQubeといったツールは、 よくあるパターンを修正コストの低いうちに見つけてくれます。
定期的なセキュリティレビューをスケジュールに入れる。 XSSのpayloadラボをQAやbug bountyのスコープに含めましょう。Browser.lolをQAに組み込んでおけば、 信頼できないPoCのpayloadも、開発マシンを危険にさらさずに動かせます。
スクリプトを閉じ込めて、リスクを手の内に置く
XSSがなくなることはありません。ウィジェット、マーケティングピクセル、サードパーティ連携が ひとつ増えるたびに、攻撃面はじりじりと広がっていきます。それでも、無力ということではありません。 規律あるコーディングが脆弱性そのものを減らし、ユーザー側の地道な衛生習慣が露出を抑え、 仮想ブラウザは、悪意あるスクリプトが実行されたとしても、それがあなたのハードウェアに触れないようにしてくれます。
見知らぬサイトはどれもXSSの侵入口になりうると考えてください。 隔離された環境からアクセスし、認証情報とクッキーをきちんと区画化し、 チームには根本原因を潰しに行くよう働きかける。 そうやって初めて、目に見えないスクリプトが何百万ドル規模のインシデントに化けるのを食い止められます。
どんな端末でも、デスクトップ並みの快適さを。
Browser.lol を無料で試して、スマホやタブレットでも PC 並みの快適さを体感してみませんか?
デスクトップブラウザを試すダウンロード不要・どんな端末でも動作
