LASSIC Media らしくメディア
XSS（クロスサイトスクリプティング）の仕組みと対策
Webサイトのセキュリティに関する話題で、「XSS（クロスサイトスクリプティング）の対策はできていますか」「脆弱性診断でXSSの指摘がありました」といった言葉を耳にしたことはないでしょうか。XSSは、Webサイトを狙う攻撃手法として長年知られており、SQLインジェクションと並んで代表的な脅威の一つです。IT事業部でシステムの発注や運用に関わる立場であれば、名前は聞いたことがあっても、それが具体的に何を突く攻撃で、なぜ危ないのか、どう防ぐのかまでは説明しにくいかもしれません。とはいえ、その大まかな仕組みを理解しておくと、ベンダーの提案や脆弱性診断の報告を受けたときに、対策が妥当かどうかを判断する助けになるでしょう。本記事では、攻撃コードの書き方といった実践的な手順ではなく、XSSとはそもそも何を突く攻撃なのか、なぜ起こり、どんな被害につながり、どう防ぐのかを、発注・運用の視点から順に整理します。専門的な用語をすべて覚える必要はありませんが、「利用者の入力を、そのまま画面に出力しない」という対策の勘所をつかんでおくと、セキュリティの会話が理解しやすくなるはずです。
XSSとは何か
XSS（Cross-Site Scripting、クロスサイトスクリプティング）とは、Webサイトの入力欄や表示部分を通じて、攻撃者が用意した悪意あるスクリプト（プログラム）を紛れ込ませ、そのサイトを見た利用者のブラウザ上で実行させる攻撃です。ポイントは、被害を受けるのがサイトのサーバではなく、そのページを開いた「利用者のブラウザ」だという点にあります。
もう少しかみ砕いてみましょう。多くのWebサイトは、利用者が入力した内容——たとえば掲示板への書き込みや検索キーワード——を、あとから画面に表示する作りです。このとき、入力された文字をそのまま画面に出力してしまうと、攻撃者は入力欄に「ただの文章」ではなく「ブラウザが命令として実行してしまう文字列」を仕込めます。その結果、ほかの利用者がそのページを開いた瞬間に、攻撃者の仕込んだスクリプトが、その人のブラウザで動いてしまうのです。いわば、掲示板の投稿に見せかけて、読んだ人のブラウザを勝手に操作する仕掛けを埋め込むようなものです。
身近なところでは、掲示板やレビュー、SNSの投稿、プロフィール欄、検索結果の表示など、利用者の入力がそのまま他の人の画面に出る場面はいくらでもあります。XSSは、そうした「入力がやがて誰かの画面に表示される」経路に潜むものです。誰もが使う機能の裏に潜むからこそ、作り手が意識して防がないと見過ごされやすいという難しさがあります。
XSSが長く問題であり続けているのは、利用者の入力を受け取って表示するという作りが、Webサイトではごく当たり前だからです。気をつけて作らないと、この「入力をそのまま表示する」すきが生まれやすく、そこが攻撃の糸口になります。情報処理推進機構（IPA）も、届出の多い脆弱性として長年にわたり注意を促しています。
なぜ起こるのか（攻撃の仕組み）
XSSが成立してしまう根っこには、「利用者が入力した文字（データ）」と「ブラウザへの命令（スクリプト）」の区別があいまいになる、という問題があります。これは、前提こそ違え、SQLインジェクションと似た構図です。
Webページは、文字だけでなく、ブラウザに動きを指示するスクリプトも一緒に記述できます。利用者の入力をそのままページに埋め込んで表示すると、入力の中にスクリプトを表す記号が含まれていた場合、ブラウザはそれを「表示すべき文字」ではなく「実行すべき命令」として解釈してしまいます。その結果、本来はただ表示されるだけのはずだった内容が、ブラウザ上で動くプログラムに変わってしまうのです。攻撃者はこのすきを突いて、狙ったスクリプトを他人のブラウザで実行させます。次の図は、出力の扱い方によって、攻撃が成立する場合と防げる場合が分かれる様子を単純化して示したものです。
ここで大切なのは、XSSは特別に高度な技術というより、「出力の扱い方の不備」から生まれるという点です。逆にいえば、利用者の入力を画面に出す際に、スクリプトとして解釈されないよう変換（無害化）しておけば、多くの場合は防げます。この考え方が、後述する対策の中心になります。
この記事のポイント
- XSSは、悪意あるスクリプトをサイトに紛れ込ませ、利用者のブラウザ上で実行させる攻撃です。
- 原因は、利用者の「入力（データ）」と「命令（スクリプト）」の区別があいまいになることにあります。
- 出力時にエスケープ（無害化）して表示すれば、多くは防げます。
XSSの主な種類
XSSは、スクリプトがどのように仕込まれ、実行されるかによって、いくつかの型に分けられます。細かな分類を覚える必要はありませんが、種類によって影響範囲が異なるため、大まかに知っておくと報告を理解しやすくなります。
| 種類 | 特徴 |
|---|---|
| 反射型 | 攻撃者が用意したURLなどを利用者がクリックすると、その場で悪意あるスクリプトが実行される型。攻撃用のリンクを踏ませることで成立し、その利用者だけが影響を受けます。 |
| 格納型（蓄積型） | 掲示板やコメント欄などにスクリプトが保存され、そのページを開いた不特定多数の利用者に影響が及ぶ型。被害が広がりやすく、影響が大きくなりがちです。 |
| DOM型 | サーバではなく、ブラウザ側で動くプログラムが入力を処理する過程で発生する型。画面を組み立てる仕組みの中で起こるため、見つけにくい場合があります。 |
いずれの型も、根っこにあるのは「入力を、そのまま実行され得る形で扱ってしまう」という共通の問題です。型ごとに発生する場所は違っても、対策の考え方の中心は変わりません。発注や報告の場でこれらの用語が出てきたら、「スクリプトがどこで仕込まれ、誰に影響するのかが違うのだな」と捉えておくと、話の見通しが立ちます。
どんな被害につながるのか
XSSが成立すると、攻撃者は利用者のブラウザ上で、その利用者になりかわってさまざまな操作を行えてしまいます。代表的な被害を挙げておきましょう。
一つ目はセッションの乗っ取りです。ログイン状態を保つための情報が盗まれると、攻撃者がその利用者になりすまし、本人しかできない操作を行えるおそれがあります。二つ目は情報の抜き取りです。画面に表示されている個人情報や、入力しようとしている内容が、外部へ送られてしまうことがあります。三つ目は偽の画面の表示です。本物のサイトの中に、偽の入力フォームやメッセージを差し込み、利用者をだましてパスワードなどを入力させる手口につながります。
やっかいなのは、これらの被害が「正規のサイト上で」起こる点です。利用者は見慣れた本物のサイトを開いているつもりなので、警戒しにくくなります。偽サイトへ誘導するフィッシングと違い、URLも見た目も本物のままであるため、だまされていることに気づきにくいのです。この「気づきにくさ」が、XSSの被害を深刻にする一因になっています。
共通しているのは、いずれも「そのサイトを信頼して訪れた利用者」が被害を受ける点です。利用者から見れば、正規のサイトを開いただけなのに被害に遭うため、サイトを提供する側の信頼は大きく損なわれます。XSSが軽視できないのは、攻撃の入り口が「よくある入力欄や表示」でありながら、被害が利用者に直接及び、事業の信用にまで波及しうるという、その広がりの大きさにあるといえるでしょう。
基本の対策と発注・運用の観点
XSSにも、有効性が広く知られた対策があります。中心になる考え方と、発注・運用で押さえておきたい観点を整理しておきましょう。
| 対策 | 考え方 |
|---|---|
| 出力時のエスケープ（無害化） | 最も基本かつ効果の高い対策。入力を画面に出す際に、スクリプトを表す記号を「ただの文字」に変換し、命令として解釈されないようにします。IPAも根本的対策として推奨しています。 |
| 入力値の検証 | 想定する形式に沿わない入力をはじく補助的な対策。エスケープを補う位置づけで、これ単独に頼り切るものではありません。 |
| コンテンツセキュリティポリシー（CSP） | ブラウザに対し、実行してよいスクリプトの範囲を制限する仕組み。万一のときの被害を抑える多層防御の一枚です。 |
| Cookieの保護 | ログイン情報を持つCookieに、スクリプトから読み取れなくする設定（HttpOnly）を付け、盗まれにくくします。乗っ取り被害を軽くする備えです。 |
中心になるのは、あくまで出力時のエスケープによって入力を無害化するという根本対策です。ほかの対策は、それを補い、被害を広げないための多層的な守りと位置づけると整理しやすくなります。「WAFを入れたから問題ない」といった単独の対策への過信は、かえって危ういものです。
発注・運用の立場では、いくつかの観点を押さえておくとよいでしょう。第一に挙げられるのが、対策方針の確認になります。開発を委託する際に、XSSを含む代表的な脆弱性への対策方針を、提案や仕様の中で確認しておくと後がスムーズです。とりわけ「出力時にエスケープする作りを基本にしているか」は、核心を突く問いになります。第二に、脆弱性診断の活用です。リリース前や定期的なタイミングで診断を受けると、作り込みの不備を早い段階で見つけられます。第三に、既存サイトの棚卸しです。古くから公開しているサイトほど、対策が手薄になっている場合があるため、一度確認しておくと思わぬリスクの早期発見につながります。なお本記事は攻撃手法の実践的な手順ではなく、XSSという脅威の考え方と、発注・運用で押さえたい観点に焦点を当てているものです。個別の対策の実装や診断は、実績のあるベンダーや専門機関への相談が別途必要になります。
まとめ
- XSSは、悪意あるスクリプトをサイトに紛れ込ませ、利用者のブラウザ上で実行させる代表的な攻撃です。
- 被害を受けるのはサーバではなく、そのページを開いた利用者のブラウザである点が特徴です。
- 原因は、利用者の「入力（データ）」と「命令（スクリプト）」の区別があいまいになることにあります。
- 反射型・格納型・DOM型などの種類があり、仕込まれる場所と影響範囲が異なります。
- 被害は、セッションの乗っ取り・情報の抜き取り・偽画面によるだましなど、利用者に直接及びます。
- 根本対策は出力時のエスケープ（無害化）で、CSPやCookie保護などの多層防御を重ねます。
- 本記事は攻撃手法の手順ではなく、脅威の考え方と発注・運用の観点の整理を狙いとしています。
よくある質問
XSSとSQLインジェクションは何が違うのですか。
狙う先と実行される場所が異なります。SQLインジェクションは、不正な命令をデータベースに実行させ、サーバ側の情報を狙う攻撃です。一方XSSは、悪意あるスクリプトを利用者のブラウザ上で実行させ、その利用者を直接狙う攻撃です。両者は「入力（データ）と命令の区別があいまいになると起こる」という点で構図が似ていますが、被害が及ぶ場所が、前者はサーバ側、後者は利用者のブラウザ側という違いがあります。どちらも代表的な脅威であり、あわせて対策しておくことが求められます。
WAFを導入すればXSS対策は十分ですか。
WAFは有効な備えの一つですが、それだけで十分とはいえません。WAFは不審な通信を入り口で検知・遮断する多層防御の一枚であり、巧妙な攻撃をすり抜ける可能性も残ります。根本的な対策は、プログラム側で出力時に入力をエスケープ（無害化）することです。WAFはこの根本対策を補う位置づけと考え、プログラム側の作り込みと組み合わせて多層で守るのが基本になります。単独の対策に頼り切るのは避けるのが望ましいでしょう。
エスケープとは具体的にどういうことですか。
エスケープとは、スクリプトの一部として解釈されうる記号を、意味を持たない「ただの文字」に変換して表示することです。たとえば、タグの始まりを示す記号などを、そのままの命令としてではなく、画面上に文字として見えるだけの形に置き換えます。これにより、入力にスクリプトが含まれていても、ブラウザは命令として実行せず、単なる文字列として表示するのです。多くの開発フレームワークには、この変換を自動または容易に行う仕組みが備わっており、これを正しく使うことがXSS対策の基本になります。
古くから公開しているサイトも心配すべきですか。
確認しておくことをおすすめします。長く公開しているサイトほど、開発当時の作り方のまま、現在の観点では対策が手薄になりがちです。表面上は問題なく見えても、内部に弱点が潜んでいることがあり、XSSは利用者に直接被害が及ぶため影響も小さくありません。すでに公開しているサイトについても、対策状況を一度棚卸しし、必要に応じて脆弱性診断を受けておくと、思わぬリスクの早期発見につながります。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、XSSをはじめとする脆弱性を作り込まないための設計・実装から、出力時のエスケープを基本とした作り込み、既存サイトの対策状況の確認、脆弱性診断を踏まえた改修までを一貫して支援する体制です。診断で指摘を受けたが対応の優先順位に迷う、古いサイトのリスクが気になるといった課題の見直しについてもご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セキュリティの作り込みに不安がある段階からでも、ご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
