クロスサイトスクリプティングとは？XSS攻撃の種類と対策を考える

クロスサイトスクリプティングとは主にユーザーに被害がおよぶスクリプトがサイトを渡り歩くサイバー攻撃です。

ユーザーに不正プログラムを持たせ、動的ページにセキュリティホール・脆弱性があるWEBサイトに誘導し、スクリプトを実行して操作をします。

対策としてはWEBサイト側は入力規制チェックし、WAFを導入して不正通信をブロックする事、ユーザーはセキュリティソフトの導入が有効です。

サイバー攻撃の代表格：クロスサイトスクリプティング

最近は、WEBアプリケーションのセキュリティ対策がより一層注目されています。

それは未だに多くのWEBアプリケーションにセキュリティホール（脆弱性）が存在するためです。

セキュリティホール（脆弱性）を突く攻撃には様々な種類がありますが、中でも「クロスサイトスクリプティング」と呼ばれるサイバー攻撃が有名ですね。

※他にSQLインジェクション等の攻撃もあります。

クロスサイトスクリプティングを徹底紹介

それではこのクロスサイトスクリプティングとはどのような攻撃の仕組みなのでしょうか。

本記事ではクロスサイトスクリプティングの仕組みや、攻撃を受けて起きる被害、WEB管理者側・ユーザー側それぞれがおこなうべき対策方法も含めて紹介していきます。

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

クロスサイトスクリプティングの事を略してXSS攻撃と呼びます。

XSS攻撃は以前からよく知られている代表的なサイバー攻撃の1つです。

WEBサイトの動的ページのセキュリティホールを狙う

XSS攻撃は、ログインページなど入力内容によって動的ページを生成する機能が脆弱性（セキュリティが甘い部分）を持っているWEBサイトを対象にしておこなわれます。

入力内容により表示が変わる動的ページ

WEBページでお名前やメールアドレスを入力すると確認画面等が表示されますよね？あれが「動的に生成されたページ」の一例です。

コメント投稿など入力ができるページは全て動的ページ

ユーザーが違えば入力される内容が違いますので、その都度生成されるHTMLページの内容も変わります。

閲覧ユーザー側が自由にボックスへの入力・投稿ができるという意味で、TwitterやYoutubeのコメント欄なども含まれます。

それに対し誰がいつ見ても同じ内容で固定されているページを「静的ページ」と呼びます。

被害はユーザー側が被る事が多い

このXSS攻撃によって一般的に直接被害を受けるのは、ターゲットにされたセキュリティホールを持つWEBサイトの方ではありません。

そのWEBサービスを利用している訪問者、つまりユーザー側（例えばあなた）の方なのです。

ユーザー自身のログイン情報やクレジットカード情報などの個人情報が盗まれたり、PCがウイルス感染したりという被害がでるのです。

ユーザー自身が不正なプログラムを運ぶ

そして何よりの特徴なのが、その不正なプログラムをユーザー自身が運んでいく事です。

XSS攻撃の仕組み

では具体的なXSS攻撃の流れをご紹介しましょう。

パターンは様々あり、下に紹介する例だけではないのであくまで基本的な流れの参考としてください。

図の番号ごとに解説をしていきます。

①.セキュリティホールを持つWEBサイト調査と準備

まず悪意ある攻撃者は常日頃から、セキュリティホールのあるWEBサイトを探しています。

以下このサイトを「ターゲットサイト」とします。

※WEBサイトを調査して脆弱性があるかどうかを（表示されるエラー画面などから）調べています。外部からでもかなり把握ができるのですね。

ターゲットサイトを発見・決定したら、そこに攻撃をする為に以下を準備します。

※ホントにヒマな奴もいるもんですね。

②.ユーザーが訪れそうな関連サイトへ罠を仕掛ける

次に作ったスクリプトをユーザーに背負わせるための「関連サイト」で罠を貼ります。

このWEBサイトはあえて、ターゲットサイトに関連した掲示板や特設サイト・SNSにしてある場合が多いですね。

そうすればターゲットサイトを利用するユーザーであれば10,000人のうち1人でも、この関連掲示板や特設サイトなどを見に来る可能性がありますよね。

その関連サイトに来てもらって、そのスクリプトをユーザーに背負ってもらおうとじっと待っているのです。

③.スクリプトを背負わせたらターゲットサイトへ誘導

確立としては低い訳ですが、運よくユーザーがその罠に掛かったとしましょう。

その関連サイトの入力フォームやリンクなどを使ってユーザーに不正なプログラム（スクリプト）を持たせます。

その持たせたユーザーに今回の脆弱性を持つターゲットサイトを訪問してもらう様に仕向けるのです。

※お得な情報があるとかイベント中の画像等が出ればクリックしたくなりますよね。

④.スクリプトをターゲットサイトの動的ページ処理で発動してもらう

元々このターゲットサイトにはセキュリティホール・脆弱性があります。

このサイトの持つ脆弱性があるポイント（動的ページの部分）をユーザーが表示させたとき、サーバーで背負っていたスクリプトが処理され発動します。

⑤.発動後は様々な操作がされる場合あり

ここからは攻撃者によりいろいろなタイプの動きがあります。

例えばこのスクリプトの効果で偽サイトに飛ばされていたりします。

ユーザーは偽サイトである事がわからずにログインをしてしまう事になります。

偽サイトでログインをしたという事は、そのログイン情報が全て盗まれている訳ですね。

そこからはいろいろな被害方向が考えられます。

想定できる被害

このようにスクリプトを背負って実行させるまでの全てを、攻撃者ではなく「ユーザーがおこなう」という恐るべきサイバー攻撃なのですね。

クロスサイトスクリプティングの語源

繰り返しますが、XSS攻撃では脆弱性を持つWEBサイトに攻撃を実行するのはユーザー自身です。

不正プログラムを構築した攻撃者の手によって、偽のサイトやターゲットのWEBサイト、そしてまた偽サイトへとスクリプトがどんどん渡り歩く訳です（ユーザーが持ち運ぶからです）。

このサイトを渡り歩いていく部分を称して「クロスサイト」スクリプティングと呼んでいるのです。

ユーザーとターゲットサイトの関係

ここが重要な部分なのですが、スクリプトを持っているだけは実害はありません。

そのスクリプトを実行させて初めて、ユーザーやWEBページへのさまざまな効果が発動するのです。

脆弱性のあるWEBサイトの動的ページ表示をするサーバー処理部分が、そのスクリプトの実行を代行してくれるという訳です。

攻撃者はターゲットサイトに実行役を担ってもらおうとしているのです。

ターゲットは動的ページの脆弱性

攻撃対象のポイントになるのは、ユーザーの入力に対して動的にHTMLページを生成する様な動的なアプリケーションです。

ですので通常のHTMLページの様な静的なページでは、このようなクロスサイトスクリプティング攻撃は起きません。

HTMLページは固定ですからユーザーによって入力・更新される事がないからですね。

ですのでWEBサイト管理者は、この動的ページへの攻撃に対するセキュリティ対策をしておくことが必要です。

SSL暗号化でも防げない

WEBサイトがhttps（SSL化）で暗号化されていても、このXSS攻撃は防げません。

ネットワークに設置してあるIDS等でもデータは暗号化されているため、暗号化されて流れる間は不正プログラムではありません。

なので感知できないのです。

サーバーに読み込まれて初めてスクリプトとして実行されるのです。

さらにSSL証明書により、スクリプト自体が正しいWEBサイトから送られてきている事が保証されてしまいますので意味をなさない事になりますね。

クロスサイトスクリプティングの被害

フィッシング詐欺タイプ

フィッシング詐欺タイプの場合、スクリプトが実行された瞬間に本物のWEBサイトを模倣した偽サイトへ移動している事が多いです。

偽サイトに来ている事なんてユーザーはわかりませんよね。URLを一回一回確認しませんからね。

ユーザーはそれに気づかずIDとパスワードを入力してログインします。そのログイン情報を攻撃者に盗まれてしまうのです。

なりすまし行為による犯罪

攻撃者は盗んだログイン情報を使ってユーザーになりすまし、本当のサイトをユーザーとして利用されてしまいます。

たとえばこのサイトがECサイトなら、ユーザーのふりをして商品購入ができてしまいます。

支払い先は「本来のユーザー」なのですからたまったもんじゃありませんね。

ログイン情報だけでなく、同じく偽サイト内でクレジットカード情報を入力させてその情報を盗む手口もあります。

セッションハイジャック

セッションハイジャックとは、不正プログラムでユーザーのCookie情報を盗む攻撃です。

WEBサイトを閲覧する際には、cookieという個人情報のデータが利用されることがあります。

cookieにはID・Passなどの重要な情報を含むさまざまなユーザーの個人情報が保存されています。

便利なcookie機能

cookieを利用していると、一度ID・Passを入力した事のあるWEBサイトだと2回目以降は自動的に入力される便利な機能です。

それもこのcookieが保存されていればこそです。

しかしながらXSS攻撃により動的ページを閲覧する事が引き金でスクリプトが発動し、このcookie情報が盗まれてしまう場合もあります。

cookieが盗まれるイコールユーザーの個人情報を盗まれた事と同じになりますので、なりすまし詐欺を受ける事になりますね。

WEBサイトの改ざん

XSS攻撃によって対象のWEBサイトが書き換えられてしまう（改ざんされてしまう）場合があります。

ユーザーが訪問・入力をする事で実行されるスクリプトにより、脆弱性のあったWEBサイト自体が改ざんされるだけではありません。

その訪問ユーザーまでも別のWEBサイトへ誘導し、さらにマルウェア等のウイルスに感染させるなどの多重攻撃も起きています。

XSS攻撃の被害事例

「Twitter」上で展開されたXSS攻撃の例

Twitterのタイムライン上に罠が仕掛けられており、ユーザーが該当ツイートをマウスオーバーしただけで、埋め込まれたスクリプトが実行されてしまうというものでした。

このスクリプトが実行されると前もって埋め込まれた偽ツイートを勝手にリツイートするようになり、それがフォロワーに広がりました。

「YouTube」での被害事例

YouTubeのコメント欄に存在した脆弱性を狙った攻撃です。

コメント欄に罠が仕掛けられ、それを閲覧したユーザーのブラウザではコメントが表示されなくなりました。

あなた専用のフェイクニュースが表示されたり、別のいかかがわしいWEBサイトへ強制リダイレクトされてしまうなどの被害がありました。

いずれも特に実害があった訳ではありませんが、ユーザーが媒介になりつつ、自身が被害に遭っているという点は同じですね。

オークションサイト「eBay」をでの実質被害事例

この事例では、eBayの出品リストのなかに攻撃用のスクリプトが埋め込まれていました。セキュリティホールが放置されていたのですね。

そのリストをユーザーが閲覧すると、スクリプトが発動し偽のログインページが表示されます。

そのページでユーザーがID・パスワードを入力すると、その情報が攻撃者に盗まれてしまうという訳です。

攻撃者による不正ログインを許してしまう

結果、攻撃者がそのユーザーのID・パスワードを使ってeBayに不正ログインされてしまっています。

これはスクリプトを埋め込まれるサイトと実行されるサイトが同じWEBサイトである例です。

脆弱性があるとこのようなフィッシング詐欺が起こりうるのです。

XSS攻撃クロスサイトスクリプティングへの対策案

クロスサイトスクリプティングを防ぐためにはWEBサイトの運営者側も訪問するユーザー側もそれぞれに対策が必要になります。

特にユーザー側の対策は、特別に難しい事ではなくすぐに実行できるはずです。即実施をしましょう。

WEBアプリケーション管理者側の対策

WEB制作者・管理者側に求められる対策としては以下が挙げられます。

ユーザー側の対策

ユーザー側（個人・企業）に求められる対策としては以下が挙げられます。

WEBサイト管理者側の具体的なクロスサイトスクリプティング対策について

一番はWEBサイトのセキュリティホール・脆弱性をなくす事が先決です。

上の項目にでた、WEBサイト管理者側がまず必須でおこなうべきクロスサイトスクリプティングの具体策から一部ご紹介しましょう。

入力ボックスへの入力値の制限・チェック

とにかくXSSの攻撃者は、WEBサイトに対し不正なスクリプトをユーザーに埋め込んでもらおうとします。

これを防ぐ一番の手立てが全ての入力ボックスへの「入力値をチェックおよび制限」する事です。

これによりアプリケーション全体の脆弱性を無くすことが出来ます。

入力チェック例

以上のような制限を全ての項目に対してチェックをおこないます。

なお「お問い合わせ内容など」フリーで文字が入力できるエリアでは、入力文字数を制限するだけでも効果があります。

入力制限ガイダンスの例

入力チェックはサーバー側でおこなう

この入力チェックは、ユーザー側ではなくWEBサーバー側で制限をしなくてはなりません。

入力値の制限だけで言えば、JavaScriptを使ってユーザーのブラウザ側で行わせる事も出来なくはないのです。

しかし仮にユーザーがJavaScriptを無効にしたりすると、ブラウザ側で入力チェックが行われないので駄々洩れになります。

サニタイジング（エスケープ処理）

サニタイジング・エスケープ処理とは、文字の書換の事です。

WEBサイトのフォームなどに入ったスクリプトの文字を別の文字へ書き換えて、「スクリプトでないものにする」事です。

これにより仮に攻撃者がスクリプトを埋め込んでも、スクリプトではない「ただの文字列」になるので安全です。

サニタイジングをすべき文字は様々ありますが、必ず使われる代表的な文字には以下があります。

エスケープ処理の対象文字列と変換文字列

対象の文字	変換後の文字例
<	& l t ;
>	& g t ;
&	& a m p ;
“	& q u o t ;
‘	# 3 9 ;

上の変換後の文字は文字の間にあえて半角スペースを入れて表示させています。

サニタイジングの例

例えば以下の様なプログラムコードが入力ボックスに入れ込まれた時に、実行がされないようにサニタイジングするとしましょう。

このようなコードではスクリプトとしては何の意味もないのですが、あえてわかりやすい様に例にとっています。

プログラムコード

<script src="scroll.js"></script>

サニタイジング・エスケープ処理例

& l t ; script src=& q u o t ;scroll.js& q u o t ; & g t ; & l t ; /script & g t ;

ここも変換文字には全て半角スペースが入っています。ご了承下さい。

このように、コードを示す記号を全て「文字」として扱えば、それを出力するだけで何も起きませんね。

サニタイジングのタイミングはHTML生成時に実施

エスケープはデータ入力時ではなくHTML生成時にする様にしましょう。

データとして格納されている時点では何も悪さをしたりはしません。

例えば動的ページを生成するため、データの実行・読込がされて初めてスクリプトが威力を発揮するのです。

とにかくHTMLとしてページが生成されるタイミングでサニタイジングしていれば問題はありません。

最終的に出力時にサニタイジングをしておけば、様々なソースから入ってくるデータに対し毎回加工を加える必要がありませんので工程が少なくて済みます。

WAF設定

WAFとは、簡単にいうとWEBアプリケーション専用のファイアウォールで、正式名称はWeb Application Firewallです。

WAFはポート番号やIPアドレスなどにより攻撃を防御するネットワークレベルのファイアウォール（IDS）とは別のものになります。

ネットワークレベルのファイアーウォールでは防げない

このネットワークレベルで設置されているファイアウォールは、外部ネットワークからの不正アクセスなどを検知するものです。

WEBサイトの中で動く掲示板機能で入力された内容まではチェックができません。

そこで登場するのがこの「WAF」です。

導入が容易なWAF

WAFはWEBアプリケーションで発生する通信内容をチェックし、不正通信をブロックする事ができます。

WAFにはサーバー管理画面から使えるタイプや、Wordpressのプラグインとしてインストールするものもあります。

最近ではWAFが標準で利用できるレンタルサーバーも多くなっています。

サーバーの設定などにそれほど詳しくない場合は、レンタルサーバーのWAFサービスを是非導入して下さい。

まとめ

クロスサイトスクリプティング（XSS攻撃）が非常に危険なサイバー攻撃である事がおわかりいただけたと思います。

攻撃者に個人情報などの収集を目的として作られたスクリプトをユーザー自身が持ち運んで、結果甚大な被害を及ぼすという卑劣な犯罪行為です。

現代ではWEBサイト運営をする管理側・利用するユーザー側、双方でXSS攻撃への対策を取る事が重要といえます。

まずはシステムを最新に保つ事・セキュリティホールをつぶす事

脆弱性があるWEBサイトは攻撃者にとって格好の標的となってしまいます。そしてそんな脆弱性を持つサイトが未だにたくさんあるのです。

Wordpressが定期的にバージョンアップを図るのはこのクロスサイトスクリプティング対策の一つです。

都度発見される新たなセキュリティホールを随時潰しているのです。

脆弱性を持つサイトをそのまま放置して、サイトユーザーにこのXSS攻撃による被害が出てしまえば、それはユーザーからの信用を全て失った事を意味します。

開発時からXSS攻撃を想定した設計を

XSS攻撃以外にも様々なサイバー攻撃情報を想定した上での開発が必要になる大規模サイトでは、このセキュリティ対策は大がかりな事になります。

しかしサイバー攻撃を受けてユーザーからの信頼を失ってしまっては、元も子もありませんよね。

まずは動的ページの設計時から入力制限などをしてチェックする・スクリプトをスクリプトと判定させない工夫が必要です。

ユーザーも同様にセキュリティ対策を強化すべき

さらにWEB管理者同様、サイトユーザー側もPC端末へ高機能のセキュリティソフトを導入しておくなどのキュリティ対策をおこなっておくべきです。

無料のセキュリティソフトを使っている人は、是非ソフト入替をご検討下さい。

一押し人気コーナー紹介

セキュリティ関連記事