XSSは、Webページに紛れた不正なスクリプトが、そのページを見た人のブラウザで動く攻撃です。表示する文章として受け取った内容などが、ブラウザへの命令として扱われてしまうことで起こります。
自分で怪しいプログラムを入れた覚えがなくても、いつものサイトのページを開いたことで影響を受ける場合があります。何が、どこで動くのかを、コメント欄の例から見ていきましょう。
XSSとはクロスサイトスクリプティングの略
XSSは「クロスサイトスクリプティング」の略称です。ここでいうスクリプトは、ブラウザなどで動くプログラムを指します。Webページでは、ボタンに反応したり、内容を更新したりするJavaScriptが使われます。
スクリプトそのものは、サイトを便利にする普通の仕組みです。XSSで問題になるのは、サイトの運営者が意図しない処理が入り込み、そのサイトの一部であるかのように動くことです。
コメントとして見せるはずが、処理として動いてしまう
たとえば、読者が感想を書き込めるページを考えます。運営側は、投稿された感想を他の読者へ文字として見せたいはずです。
ところが、投稿内容をページに入れる際の処理に不備があると、文字として表示するはずの部分へ、攻撃者が仕込んだ命令が入り込むことがあります。それを受け取ったブラウザが、ページ内の処理として実行してしまいます。
攻撃者が、表示内容に処理を紛れ込ませる
不備のある表示処理が、その内容を安全に扱えない
閲覧者が開くと、ページの一部として処理される
保存された投稿を利用する場合の模式図です。XSSには、投稿を保存せずに起きる形もあります。
これは説明用の例です。コメント欄があるすべてのサイトで起きるわけではありません。外部から入った内容を、安全に表示できる形で扱っているかが重要です。
MDNのXSS解説は、攻撃者のコードが、そのWebサイトの一部であるかのように実行される点を説明しています。「別の怪しいサイトへ移ったときだけの問題」と考えると、見落としやすくなります。
XSSで動くのは閲覧者のブラウザ
XSSの説明で混同しやすいのが、悪意のある内容が保存される場所と、それが実際に動く場所です。
先ほどのコメント例では、投稿内容がサイト側に保存される場合があります。しかし、XSSのスクリプトが動くのは、そのページを開いた人のブラウザです。サーバーに保存されていたから、サーバーの中で動くとは限りません。
| 起こり得ること | なぜ問題になるか |
|---|---|
| ページの表示を変える | 本物のサイト内に、偽の案内や入力欄が出る可能性がある |
| そのページで扱う情報を読む | 入力内容などが、意図しない相手へ渡るおそれがある |
| 利用者として操作を送る | ログイン中の権限を利用し、本人が望まない処理を行う場合がある |
実際の影響は、ページの機能や権限、ブラウザ側の制限などで異なります。PC内のすべてのファイルを自由に読める、という意味ではありません。
IPAのXSS対策資料も、本物のサイト上に偽の表示が出ることや、Cookieの情報が利用される可能性を説明しています。Cookieがすべて読めるとは限らず、設定によって読み取れないものもあります。ただし、Cookieを読めなければXSSの影響がすべてなくなるわけではありません。ページの操作や表示にも注意が必要です。
SQLインジェクションとは何が違う？
SQLインジェクションは、データベースへの命令を不正に変える攻撃です。XSSは、Webページへ入り込んだ処理が、閲覧者のブラウザで動く攻撃です。
どちらも入力の扱いが関係しますが、命令を受け取る相手が違います。「入力を確認する」という一言だけでは、必要な対策を区別できません。
XSSの種類はどこに入り、どう表示されるかで見る
XSSには、格納型、反射型、DOM型といった呼び方があります。名前だけを覚えるより、悪意のある内容がどのようにページへ入るかを見ると理解しやすくなります。
| 呼び方 | 注目している仕組み | 例として考えられる場所 |
|---|---|---|
| 格納型・保存型 | 保存された内容が、後でページに表示される | コメントや投稿など |
| 反射型 | 送られた内容が、応答ページへ埋め込まれて返る | 検索語を表示する画面など |
| DOM型 | ブラウザ内でページを書き換える処理に不備がある | URLなどの値を画面へ反映する処理 |
DOMは、ブラウザがページの構造を扱うための仕組みです。この名前が出たら、「ページを受け取った後、ブラウザの中で作り替える部分にも注意が必要」と捉えるとよいでしょう。
三つは、常に完全に分かれた箱ではありません。保存されるかどうかと、どこでページへ組み込まれるかは、別の見方だからです。細かな分類よりも、外から来た内容が、どの段階で実行できる形へ変わるかを見ます。
また、特別なファイルのダウンロードが必要とは限りません。不正な内容を含むページやリンクを読み込むことで処理が動く場合があります。反対に、ページを開くと必ず感染する、と一般化することもできません。サイトに不備があり、攻撃が成立する条件が必要です。
XSS対策でサイト側と利用者側ができること
根本の対策は、ページへ入れる内容を、意図しない命令として実行させない作りにすることです。
文章として表示したいなら、特別な記号も文字として表示されるよう処理します。これを、出力のエンコードやエスケープ処理と呼びます。文字の装飾などを一部許す場合は、許可した要素だけを残す処理も必要になります。
ただし、ページの本文へ入れる場合と、リンク先やプログラムの中へ入れる場合では、必要な扱いが違います。どこでも同じ置き換えをすればよいわけではありません。開発者は、利用する仕組みの公式な方法と、その適用範囲を確認します。
サイト側は「何を動かしてよいか」も制限する
CSPという、ブラウザが実行してよい処理などを制限する仕組みもあります。先ほどのMDN資料は、これを、入力を安全に扱う対策に加える防御として説明しています。
「CSPを付けたから表示処理の修正は不要」ではありません。安全な表示処理と、想定外の実行を抑える設定を組み合わせます。CMSや部品に修正版が出たときは、対象となるものを更新することも運用側の仕事です。
利用者は、見た目だけで判定しようとしない
XSSを見た目だけで見抜くのは難しく、すべてを利用者の注意で防ぐことはできません。利用者としては、次の対応が現実的です。
- ブラウザやOSを更新し、利用できる保護を保つ。ただし、更新だけでサイトのXSSをすべて直せるわけではありません。
- いつものページで不自然な入力や操作を求められたら、すぐに情報を入れず、公式の別の案内で確かめる。
- サービスから対象者向けの通知が出たら、確認された情報と必要な対応を読む。
XSSは「悪い文字が投稿された」というだけの話ではありません。表示する内容と、動かす処理の境界に問題があり、その影響がページを見た人へ届く攻撃です。内容が保存される場所と、スクリプトが動く場所を分けると、ニュースや対策の説明を読み解きやすくなります。
