 |
【特集】
Webアプリケーションにセキュリティホールを作らないための
クロスサイトスクリプティング対策の基本（前編）
〜クロスサイトスクリプティング脆弱性とは？〜
国分裕
三井物産GTI （現：三井物産セキュアディレクション株式会社）
2002/11/9
最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング」と呼ばれる脆弱性が有名であるが、クロスサイトスクリプティング脆弱性について正確に理解している人が依然として少ないと感じる。
本稿では、クロスサイトスクリプティングとはどのような脆弱性であるのか、この脆弱性を持ったサイトが攻撃されるとどのような被害が起き得るのか、なぜそのようなセキュリティホールが作り込まれてしまうのか、どのように対策をすればよいのかを解説していく。
| ※以下本文中では、クロスサイトスクリプティング脆弱性のことを「XSS」と表記する。「Cross Site Scripting」の略であるから「CSS」と表記している記事もあるが、「Cascading Style Sheets」の略も「CSS」となり紛らわしいため、「XSS」と表記する場合が多くなってきている。本稿でも「XSS」と表記することにする。 |
| Webアプリケーションに潜むセキュリティホール |
先日、OpenSSL、Apache、Squidのような有名なアプリケーションでセキュリティホールが見つかった。これらのアプリケーションを作成したプログラマたちはセキュリティについて気を使いながらプログラミングを行っていたことであろう。しかし、ちょっとしたミスや見落としによりセキュリティホールを作り込んでしまった。これに対して個別のWebサイト用に開発されたWebアプリケーションはどうだろうか。おそらく、セキュリティについての知識がないプログラマが開発している、あるいは知識もあり意識して開発しようとしているが納期や予算の関係でセキュリティ対策を後回しにして開発している場合がほとんどではないだろうか。そのような状態で、まともにセキュリティ対策の施されたアプリケーションが出来上がってくることはまれだろう。
これまで、Webサーバのセキュリティ対策というと一般に次のようなものが知られている。
- ファイアウォール
- IDS（不正侵入検知システム）
- ウイルスチェック
- ファイル改ざん検知
これらの対策方法は防御できる範囲に制限があり、複数の対策方法を組み合わせて使わないとサイトを守るには不十分となる。表1は、それぞれの対策方法がカバーするプロトコル範囲をまとめてある。
|
||||||||||||||||||||
| 表1 各対策方法がカバーするプロトコル範囲 |
これに対して、それぞれのプロトコルがどのプログラムによって処理されるのかを追加したものが次の表である。
|
||||||||||||||||||||||||
| 表2 各対策方法がカバーするプロトコル範囲と処理するプログラム |
この表から分かるように、個別Webアプリケーションが処理する部分については、ほとんど防御されていない。さらにこの個別Webアプリケーションとは先に述べたとおりセキュリティ対策がまともにできていないアプリケーションである。IDSは△としたが、わずかな一部の攻撃に対してのみ有効なだけである。IDSは基本的に、あらかじめ登録されているパターンの攻撃がされたときにそれを検知する。しかし、HTMLなどを処理するアプリケーションはWebサイト固有のものであるので、それに対する攻撃も千差万別である。そのためIDSはWebアプリケーションに対する攻撃の大部分は検知することさえできないのが現状である。
上記の理由により、多くの脆弱なWebアプリケーションが無防備なまま、インターネットからの攻撃の脅威にさらされているのである。
| Webアプリケーションに対する攻撃 |
Webアプリケーションに対する代表的な攻撃手法として、次のような攻撃がある。
- Buffer Overflow（バッファオーバーフロー）
- Cross Site Scripting（クロスサイトスクリプティング）
- Parameter Manipulation（パラメータ改ざん）
- Backdoor & Debug Options（バックドアとデバックオプション）
- Forceful Browsing（強制的ブラウズ）
- Session Hijacking／Replay（セッション・ハイジャック／リプレイ）
- Path Traversal（パスの乗り越え）
- SQL Injection（SQL の挿入）
- OS Command Injection（OS コマンドの挿入）
- Client Side Comment（クライアント側コメント）
- Error Codes（エラーコード）
これらの攻撃は従来のHTTPDやOSに対する攻撃と異なり、
- 必ずしもサーバの管理者権限を奪うことが目的ではない
- Webアプリケーションごとに攻撃のパターンが違う
- 必ずしもファイルを改ざんするわけではない
- ウイルスやワームを送りつけているわけではない
- ほとんどの攻撃がログに残らない
これらのWebアプリケーションに対する攻撃手法のうち、今回はXSSを取り上げている。
| XSSの仕組み |
前置きが長くなってしまったが、XSSの仕組みについて説明する。XSSを利用して攻撃が行われるのは、ユーザーの入力に対して動的にHTMLページを生成するアプリケーションが対象になる。静的なページ、つまり通常のHTMLページではこの問題は起こらない。
例として次のようなアプリケーションを考えてみる。
 |
| 図1 テキスト入力欄があるcgiの例 |
図1のようなテキスト入力欄があり、そこに名前を入力して送信ボタンをクリックすると、ユーザーが入力した名前がページの一部となって表示されるアプリケーションがあるとする（図2）。非常に単純な例ではあるが、ユーザーが入力した文字列を使って動的にHTMLページを生成し出力しているためXSSが入り込む可能性のあるアプリケーションである。
 |
| 図2 ユーザーが入力した文字列を使って動的にHTMLページを生成させている画面 |
ブラウザの機能でこのページのソースを見ることができる。出力されているHTMLは、次のようになっている。
<html> |
HTMLとしては間違った文法であるが XSSの問題とは関係ない。
さて、ここで名前の入力欄にHTMLタグを使用した「<s>kokubu</s>」という“名前”を入力してみる。この場合はどうなるだろうか。XSS対策が不十分なWebアプリケーションのほとんどがkokubuの部分に取消線が引かれた“名前”が表示される(図3)。
 |
| 図3 kokubuの部分に取消線のHTMLタグを入力した画面 |
このとき、出力されているHTMLは、次のようになっている。
| <html> <body> ようこそ<s>kokubu</s>さん </body> </html> |
本来、「<s>kokubu</s>」という文字列をブラウザ上に表示したい場合は、「<s>kokubu</s>」としなければならないのだが、その処理が抜けてしまっているのだろう。
さらに、名前入力欄にscriptタグを使用した「<script>alert("XSS");</script>」という“名前”を入力してみる。すると、XSSと書かれたダイアログボックスが表示される。
 |
| 図4 名前入力欄にscriptタグ「<script>alert("XSS");</script>」を入力した結果 |
出力されているHTMLは、次のようになっている。
| <html> <body> ようこそ<script>alert("XSS");</script>さん </body> </html> |
HTML文中に「<script>alert("XSS");</script>」というダイアログボックスを表示するためのスクリプトが入っている。ブラウザはこれをスクリプトと解釈してダイアログボックスを表示している。ここではダイアログボックスを表示するだけの無害なスクリプトを実行させたが、ほかの任意のスクリプトを実行することもできるだろう。これがクロスサイト“スクリプティング”と呼ばれる理由の1つである。
これだけだと自分が入力したスクリプトを自分が実行するだけであるので何の問題もないだろう。しかし他人が作成したスクリプトを実行させられるとしたら脅威となることが分かっていただけるだろう。実際このように簡単に実現することができる。
このアプリケーションを例に取って考えてみる。先ほどのダイアログボックスが表示されていた画面のURL欄を見ていただきたい。
 |
| 図5 図4でXSSと書かれたダイアログボックスが表示されたときのURL欄に注目（拡大） |
URLの部分に「name=%3Cscript%3Ealert%28%22XSS%22%29%3B%3C%2Fscript%3E」と表示されているのが分かる。これはURLエンコードという方式でエンコードされた文字列で、デコードしてみると「name=<script>alert("XSS");</script>」となる。このアプリケーションでは、名前入力欄に入力した名前がURLの後ろに追加されてアプリケーションに渡され、アプリケーションはこの文字列を読み取り、出力画面の一部としてブラウザに表示させる、という仕組みを取っている。このURLのパラメータ部分を「name=%3Cscript%3Ealert%28%22Cross Site Scripting%22%29%3B%3C%2Fscript%3E」と書き換えたURLにアクセスすると、図6のように「Cross Site Scripting」と書かれたダイアログボックスが現れる。
 |
| 図6 URLのパラメータ部分を書き換え、そのURLにアクセスすると「Cross Site Scripting」と書かれたダイアログボックスが表示される |
これを利用して攻撃者は、このアプリケーションがあるサイトとは別のサイトに次のようなページを用意する。
| <html> <body bgcolor="black" link="white"> <a href='https://脆弱サイト/hello.cgi?name=<script>alert("XSS");</script>'> ここをクリック</a> </body> </html> |
 |
| 図7 攻撃者のサイトを用意し、ブラウザで表示したところ |
攻撃者はユーザーに対して、このページにアクセスするように仕向ける。攻撃者のサイトにアクセスしたユーザーがこのリンクをクリックすると、
https://脆弱サイト/hello.cgi?name=<script>alert("XSS");</script>というURLにアクセスすることになり、先ほどのスクリプトが実行される。攻撃者のサイトから攻撃対象のサイトというようにサイトをまたがる（クロスする）ことから、“クロスサイト”スクリプティングと呼ばれる。
| XSSの基本的なステップを整理する |
では、これまで説明したXSSの流れをまとめてみよう。
 |
| 図8 今回解説したXSS攻撃の流れ |
- ユーザーが攻撃者の用意したページにアクセスする
- リンクを含んだページがブラウザに表示される
- ユーザーがリンクをクリックする
- ユーザーが（無意識のうちに）攻撃対象のサイトにスクリプトを含んでアクセスする
- スクリプトを含んだページがブラウザに表示される
- ユーザーのブラウザ上でスクリプトが実行される
これが最も基本的な場合のステップであるが、ほかにもさまざまなバリエーションがある。このステップで一番ネックになりそうなのが1と3で、ユーザーが何らかの操作をしなければならないようになっている。しかし、攻撃者は巧妙な仕掛けで無意識のうちにユーザーが1と3の動作をしてしまうような仕組みを作るだろう。
例えば、ユーザーがリンクをクリックするのを待つのではなく、自動的に次のページへ飛ぶような方法がある。「このページは移動しました。○○秒後に自動的に移動します」といったページを見掛けることがよくあるが、原理はそれと同じである。このようなページを作成しておけば、3のステップをユーザーが無意識のうちに行わせてしまうことができる。
また、メールで直接URLを送りつけてしまったり、大勢の人がよく見る掲示板に先ほどの仕掛けを仕込んでおくなどの方法で、簡単に1も実行させられる。
実は今回説明に用いた例ではHTTPSを使っていた。HTTPSでは途中経路が暗号化されているため、暗号化されているデータが流れているネットワークに設置してあるIDSでは、どんなことをしても検知できないだろう。さらにSSLの証明書により、スクリプトが正しいサイトから送られてきていることが保証されるという、皮肉な結果となっている。
今回は、パラメータ値がURLに含まれるGETメソッドでのアクセスを例に挙げたが、パラメータ値がURLに含まれないPOSTメソッドでのアクセスでも同様のことが起こる。POSTメソッドを使うだけでは何の対策にもならないことに注意していただきたい。
◇
次回は、実際にどのような被害が起き得るか、実際のプログラミング工程でどのようなミスをしていて、さらにどのように対策をすればよいかについて説明する。
 |
Security&Trust記事一覧 |
|
||||||
|
||||||
| Profile |
| 国分 裕（こくぶ ゆたか） 三井物産株式会社GTIプロジェクトセンタ勤務。セキュリティコンサルタン トとして、不正アクセス監視やセキュリティ検査 などに従事している。金融機関、官公庁、大手製造業などへのセキュリティシ ステムの導入、セキュリティ 検査などの実績を持つ。 三井物産株式会社GTIプロジェクトセンタ 主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サー ビスも実施中。 |
| 関連記事 | |
| 連載：Webアプリケーションに潜むセキュリティホール | |
| 連載：不正侵入の手口と対策 | |
| 連載：インシデントレスポンスはじめの一歩〜rootkitを検出するために |
ホワイトペーパー（TechTargetジャパン）
- この脆弱性対策エンジンは“永遠に完成しない” （2010/3/9）
パターンファイルに頼らず防御する「要の技術」は、いまも完成にはいたっていない。その理由とは―― - Gumblarがあぶり出す 「空虚なセキュリティ対策」 （2010/3/1）
ガンブラーの脅威は、組織の構造や外部委託問題をあぶり出します。そのセキュリティ対策、建前論になっていませんか？ - 決済アプリのセキュリティ基準、PA-DSSとは （2010/2/24）
“ペイメントアプリケーション”のセキュリティ基準を定めたPA-DSS。厳密に定められた14の要件を、PCI DSSと対比させつつ解説します - 「鍵は“J”の中にあるよ」CTF by ダークナイト解答編 （2010/2/22）
ダークナイトからの挑戦状、いかがだっただろうか。WiresharkにNetworkMiner、WinRARを駆使し、“J”に隠された秘密を解き明かせ！
 |
|
|
|
|
スキルアップ／キャリアアップ（JOB@IT）
スポンサーからのお知らせ
- - PR -
 |
仮想環境の構築とデータ保護の特効薬？！ 実績と信頼性の高いパッケージで安心運用 New！ |
 |
仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
 |
おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
 |
社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
 |
その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
 |
美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
 |
.NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は？ |
 |
進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
 |
運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
- - PR -
お勧め求人情報
*＊先週の人気講座ランキング＊*
〜Java編〜
| ◆ | おばかアプリ選手権、第４弾開催中！！ ムダにカッコよくてくだらない作品求ム！ |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| ◆ | Twitterのアカウントはなぜ突破された？ メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ！ Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ？ 気になる いやし系!! PV急増で「美人時計」がとった手段とは？ |
| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は？ |
| ◆ | 業務効率と情報セキュリティ対策を両立！ 手間なく確実に機密情報を守る方法とは？ |
| ◆ | 直属上司が海外にいるのエンジニアに見る 【実例】場所に捉われないワークスタイル |
| ◆ | 「仮想化工房」のマイスターが選んだのは VMware、Hyper-V、そしてVirtageだった！ |
| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？ |
| ◆ | 【CTC事例】約30の基幹システムを統合！ 膨大なバッジジョブを制御した方法は？ |
| ◆ | 仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？ |
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「＠IT MONOist」「ITmedia」「誠」「BARKS」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。