クロスサイトスクリプティング
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/07/21 10:00 UTC 版)
「クロスサイト（サイト横断）」という名称は歴史的なもので、初期に発見されたXSSでは脆弱性のあるサイトと攻撃者のサイトを「サイト横断的」に利用して攻撃を実行することから名づけられたものだが[3][4]、XSSの定義は新しいタイプの攻撃が見つかるたびに拡張され、サイト横断的なものでなくともXSSと呼ぶようになった[3]。
この拡張された定義においてXSS攻撃とは、攻撃者の作成したスクリプトを脆弱性のある標的サイトのドメインの権限において閲覧者のブラウザで実行させる攻撃一般を指す[3]。斜体で書いた部分がXSS攻撃の重要な特徴であり、この特徴により標的サイトの権限がないと実行できないようブラウザが制限している（同一生成元ポリシー）はずの行動を、攻撃者に実行可能にしてしまう[5]。
概要
背景
XSSについて述べる前に、ウェブサイトの仕組みについて簡単に復習する。JavaScriptのようなクライアントサイドのスクリプトは、ウェブサイトが閲覧者が取った行動（例えばフォーム に何を記載したか）を変数の形で取得し、取得した変数値に応じて動的にHTMLを生成する。
セキュリティの観点から見た場合スクリプトには非常に強い権限が与えられている為、これを悪用された場合には大きな危険を伴う事になる。具体的にはスクリプトを使えばブラウザに保管されているcookieの内容を読み書きする事も可能であるし、ログイン時にはサイトからユーザ固有の情報を読み書きする事も可能である。さらにはそうした情報を別のサイト（例えば攻撃者のサイト）に転送する事も可能である。
こうした事情によりウェブブラウザには同一生成元ポリシーという、スクリプトの悪用を制限するためのポリシーが実装されている。このポリシーは、「ウェブページ１に記載されたスクリプトがそれとは別のウェブページ２に関するデータにアクセスできるのは、ページ１と２が同一の「オリジン」にある場合のみである」とするものである。ここでページ１と２のオリジンが同一であるとは、１と２のプロトコル、ホスト名、ポート番号が一致する事を指す。
多くのケースにおいて同一のウェブサイト上にあるページは同一のホスト上において同一のプロトコル(http)と同一ポート番号(80番)で動作するものなので、同一生成元ポリシーはウェブサイトを構築する上であまり邪魔にならない。しかし攻撃者が全く別のサイトからスクリプトによってデータを不正に読み取ろうとしたとしても同一生成元ポリシーがこれを妨げるのでセキュリティは担保される。
XSS攻撃の目的と特徴づけ
XSS攻撃は、ウェブサイト（標的サイト）の脆弱性(XSS脆弱性)を利用する事で、標的サイトの権限で悪意のあるコンテンツ（多くの場合スクリプト）を実行する事を目的として行われる[5][1]。悪意のあるコンテンツは標的サイトの権限で実行されるので、同一生成元ポリシーによる制限が迂回される[5][1]。これを悪用する事により攻撃者は標的サイトを閲覧したユーザ（＝被害者）のcookieを盗むなど、様々な攻撃を行う。
CWE-79ではXSS攻撃を以下のような攻撃として特徴づけており、XSS脆弱性をXSS攻撃を可能にする脆弱性として特徴づけている[1]。XSS攻撃を行う攻撃者は標的サイトへのデータ入力経路に不正なデータを注入（インジェクション）する。ここでいう「データ入力経路」は正規のユーザのために用意された入力経路（例えばフォーム）の場合もあればそうでない場合もあり、標的サイトのウェブアプリケーションへのWebリクエスト全般が狙われる[1]。また不正なデータはスクリプトなどWebブラウザで実行可能な悪意のあるコンテンツを含んだものが用いられる。
このインジェクションの結果、標的サイトのウェブサーバが攻撃者の用意した不正データを含んだウェブページを動的に生成する[1]。この生成されたウェブページを被害者となるユーザが閲覧すると、不正なデータに含まれる悪意のあるコンテンツが標的サイトの権限により被害者のブラウザ上で実行され、攻撃が成功する[1]。
XSS攻撃に用いる「Webブラウザで実行可能なコンテンツ」は何らかのスクリプトである事が多いので、本稿では以下、特に断りがない限りスクリプトのケースについて述べる。
XSS脆弱性とXSS攻撃の詳細
本節ではXSS脆弱性とXSS攻撃の詳細を具体例を通して述べる。 すでに述べたように、ウェブサイトではユーザがフォームなどで入力した値を変数として持ち、変数にセットされた値に応じてその後の動的なページ内容の生成が行われ、その際には変数値そのものがページに表示されることもある。XSS脆弱性の簡単な例としてはユーザが値を決定できる変数値を加工せずそのままウェブページに表示（エコーバック）してしまう[6]というものがある。具体的には以下のようなシチュエーションでXSS脆弱性が生じる事が多い：
そこで最初に挙げた確認ページのシチュエーションにおける脆弱性を利用したXSS攻撃の例を述べる。今、標的サイト example.comのウェブページにユーザの性別を選択させるフォームがあり、そのページではユーザが選択した値（"man"もしくは"woman"）を変数genderにそのまま保管し、genderの内容を以下のようにそのまま表示する事でフォームの内容をユーザに再確認させるページを動的に生成するとする（再確認ページのURLはフォームのあるページのURLと同一でも異なってもよい）。
入力した性別は以下のもので正しいでしょうか：
（genderの値）具体的にはたとえばPHPで
<?php echo "名前：".$_GET['gender']; ?>
もしくは
<?php echo "名前：".$_POST['gender']; ?>
というスクリプトが書かれていた場合である。
このようなページにおいて、攻撃者が何らかの方法でgenderの値を
gender=<script>（悪意のあるスクリプト）</script>
にセット（＝スクリプトのインジェクション。 詳細後述）し、この状態で被害者となるユーザがこのページにアクセスしてしまうとXSS攻撃は成功となる。
実際、標的サイトのウェブページには、変数genderの値をそのまま表示するページを動的に生成してしまうという脆弱性があるので、攻撃者が前述のようにgenderをセットした状態で被害者となるユーザがこのページを閲覧してしまうと、ウェブサイトは動的に生成したHTML
入力した性別は以下のもので正しいでしょうか：
<script>（悪意のあるスクリプト）</script>
を被害者のブラウザに送りつけてくるため、悪意のあるスクリプトが被害者のブラウザ上で自動的に実行されてしまう。
なお、ウェブサイトの作者がgenderの値としてフォームに準備した値が「man」と「woman」の２つだけだったとしても、実際にgenderにセットされた値が「man」か「woman」のいずれかであることを、ウェブサイトを置いているサーバ側でチェックしない限り、攻撃者はそれ以外の値（＝悪意のあるスクリプト）にgenderをセット可能である。
インジェクション方法の具体例
次に攻撃者が悪意のあるスクリプトをインジェクションする方法を述べる。方法はウェブページにどのようなXSS脆弱性が存在するのかに依存するので、ここではフォームの入力値の２通りの送信方法(GETメソッド、POSTメソッド)に応じてインジェクション方法を２通り述べる。
なお、ここで説明する例はいずれも、後述するXSSの分類では「反射型」に属する。
GETメソッドのみに適用できる方法
GETメソッドでは変数の値がURLに明記されるので、フォームの内容をユーザに再確認させるページのURLは
http://example.com/?gender=（フォームで入力した値）
のような形になっている。
そこで攻撃者は被害者となるユーザに以下のURLにアクセスするよう何らかの方法（たとえばexample.comを装った罠メールにこのURLを記載）で促す：
http://example.com/?gender=<script>（悪意のあるスクリプト）</script>
するとgenderが悪意のあるスクリプトにセットされたページを被害者が閲覧することになるので、攻撃が成功したことになる。
ここで重要なのは、上記のURLが「http://example.com/」から始まる事である。これが原因でユーザはexample.comの何ら問題のないWebページだと誤解してしまい、上記のURLをクリックしてしまう可能性がある。
なお、ここでは悪意のあるスクリプトを標的サイトのURLに埋め込む方法を紹介したが、URLの長さには上限がある関係上、埋め込めるスクリプトの長さが制限されてしまうため、攻撃者が行える攻撃の種類が制限されてしまう。
長さに制限のないスクリプトを埋め込むには、攻撃者は自分のサイトを立ち上げ、そこに悪意のあるスクリプト「http://（攻撃者のサイト上の悪意のあるスクリプト）」をおいた上で、被害者に
http://example.com/?gender=<script src="http://（攻撃者のサイト上の悪意のあるスクリプト名）"></script>
を閲覧させればよい。
ただしこちらの攻撃の場合、攻撃者のサイトのURLがウェブサーバのログに残るため、これを手がかりにサーバ管理者が攻撃者を特定できる可能性がある。したがって攻撃者は自身のサイトの場所を頻繁に変えるなど追跡の手を逃れる手段を講じる必要がある。
GETメソッド、POSTメソッド双方に適用できる方法
上述したGETメソッドの例ではURLに変数の値がそのまま表示されている事が攻撃者にXSS攻撃を可能にしてしまった原因の一つである。しかしURLに変数の値が表示されないPOSTメソッドを使った場合でもXSS攻撃が可能である。以下、POSTメソッドを前提にして話をすすめるが、GETメソッドに対しても同様の方法でインジェクションが可能である。
標的サイトにXSS攻撃を仕掛けるため、攻撃者は自身でウェブサイト（罠サイト）を立ち上げ、そこに以下のようなHTMLを書く：
<form action="http://example.com/" method="POST" name ="hoge"> <input type="hidden" name="gender" value='<script>（悪意のあるスクリプト）</script>'> </form> <script>document.hoge.submit()</script>
被害者が罠サイトを表示してしまうと、フォームhogeのinput文においてgenderが（悪意のあるスクリプト）にセットされた状態で標的サイト「http://example.com/」が表示されてしまうので、被害者のブラウザで悪意のあるスクリプトが実行されてしまう。
しかもこのinput文はhidden指定なのでgenderの値は被害者のブラウザ上に表示されず、被害者はこの事実に気づかない。
隠蔽工作
上で説明した「GETメソッドのみに適用できる例」ではユーザがアクセスした攻撃用サイトには「入力した性別は以下のもので正しいでしょうか」といった文章が表示されてしまうため、攻撃を受けたことにユーザが気づいてしまう可能性があるが、攻撃者が悪意のあるスクリプト部分の冒頭に
document.body.innerHTML=""
というJavaScriptを記載しておけば、HTML本文が完全消去されるため、上述のような不自然な文章は表示されない。
これに続けて（JavaScriptのdocument.writeメソッドを使って）攻撃に必要な内容をスクリプト部分に自由に記述可能となる。
別の隠蔽工作方法として、罠サイトでHTMLのiframeタグとCSSを用いるというものがあり、この方法には攻撃者にとって上で述べた隠蔽工作とは違った利点がある（詳細後述）。なおiframeとはウェブページを入れ子にするためのHTMLタグで、ウェブページA上にウェブページBのURLを指定したiframeタグを書くと、A上に四角いフレームができ、その中にBの内容が表示される。これを利用して攻撃者は以下のように隠蔽工作を図る。
まず攻撃者は罠サイトのページAにiframeタグを書くことで、悪意のあるスクリプトを埋め込んだ標的サイトのURLを読み込む。具体的には、ページAに
<iframe src=http://example.com/?gender=<script>（悪意のあるスクリプト）</script>></iframe>
さらにCSSを書くことでiframeの内容が表示されたフレームがAの閲覧者には見えないようにする[9]。この状態で被害者を誘導してページAを開かせると、iframeにより自動的に悪意のあるスクリプトを埋め込んだ標的サイトが読み込まれるので、攻撃が成功する。
この隠蔽工作の利点は、攻撃に用いたiframeはCSSで隠しているので、標的サイトと全く無関係に見える罠サイトを被害者が開いただけで攻撃が完了し、しかも罠サイトのURLにも不自然なところはないので、被害者にとって罠サイトと通常サイトを見分ける手段が無いことである。
「GETメソッド、POSTメソッド双方に適用できる方法」に対しても同様にiframeとCSSで隠蔽工作が可能である。こちらの場合、攻撃用のフォームを書いたページBを罠サイトに作成し、BをiframeでページAに読み込んだ上でCSSによりiframeを隠せばよい。
被害者がページAを閲覧すると、iframe内は悪意のあるスクリプトを埋め込んだ標的サイトに遷移するという不自然な動きをするが、CSSでiframeを隠しているので被害者はこのことに気づかない。
インジェクションする言語
XSS攻撃に用いる「Webブラウザで実行可能なコンテンツ」の例として、CWE-79では以下のものを挙げている：
インジェクション箇所
HTML内には攻撃者が悪意のあるスクリプトをインジェクションし得る箇所として以下のものがある：
2.の場合、URLとして「javascript:(JavaScript文)」の形式(javascriptスキーム)を利用してJavaScriptを注入することができる[10]。
- ^ a b c d e f g h i j k l m n o p q r s CWE-79 2011.
- ^ 共通脆弱性タイプ一覧CWE概説。IPA
- ^ a b c d e f g h 金床 2007, p. 3章冒頭部.
- ^ IT用語辞典e-words「クロスサイトスクリプティング」 2016/09/12閲覧
- ^ a b c 金床 2007, p. 3章『攻撃の概要』節.
- ^ a b c d e f g IPA 2014.
- ^ a b c d IPA 2011.
- ^ 金床 2007, p. 第三章「攻撃の概要」節.
- ^ a b 徳丸 2011, p. 91.
- ^ a b c d 徳丸 2011, p. 106.
- ^ IPA 2015, p. 22-29.
- ^ a b IPA 2013, p. 5-8.
- ^ IPA 2013, p. 10.
- ^ “あまり知られていない脆弱性：DOM Based XSSにご用心”. アークウェブ (2007年2月16日). 2016年9月12日閲覧。
- ^ 徳丸 2011, p. 100-101.
- 1 クロスサイトスクリプティングとは
- 2 クロスサイトスクリプティングの概要
- 3 XSSの被害
- 4 攻撃手法の分類
- 5 対策
- 6 脚注
- クロスサイトスクリプティングのページへのリンク
