最終更新日：2002年 3月 7日

変更履歴
Webサイトにおけるクロスサイト スクリプティング脆弱性に関する情報
http://www.ipa.go.jp/security/ciadr/20011023css.html

- ユーザーのセッションが奪われる可能性 -

情報処理振興事業協会
セキュリティセンター
2001年10月23日

現在稼動中の多くの webサービス(ショッピングサイト、銀行など)におけるクロスサイト スクリプティング脆弱性の問題に対する対策が不十分なため、これを 攻略する攻撃の可能性が指摘されています。

クロスサイト スクリプティング脆弱性は 2000年 2月に CERT/CC と Microsoft社により報告されたアドバイザリ(※注)により広く知られるものとなっています。 しかし、依然として多くのサイトにおいて対策が取られていない現状にあることが、産業技術総合研究所 高木 浩光 氏らの調査により明らかになりました。 この脆弱性を用いることにより、対策のとられていない webサイトにアクセスすることで、ユーザーの cookie が第三者に送信される可能性があります。 この cookie が認証やセッション管理に用いられていた場合、第三者がユーザになりすまして webサイトにアクセスできることから、クレジットカード番号などの重要な情報が漏洩する恐れがあります。

※注） 本脆弱性はMicrosoft社のサーバに限定されるものではありません。

Webサーバーシステムのインテグレーター、サーバー管理者、サービス運営者においては、早急にクロスサイト スクリプティング脆弱性を解消する対策をとることが 望まれます。

またユーザにおいても、ブラウザの cookieマネージャ等で cookie の利用状況を把握すると共に、サービス利用後にセッションを終了させるなど、自衛に努めてください。

クロスサイト スクリプティング
Web サーバーシステムのインテグレーターおよび web サイト管理者向けの技術情報

概要

クロスサイトスクリプティング (cross-site scripting) は、web ページとして動的に HTMLやXML等のマークアップ言語のソースを生成する仕組みを設けている場合に、セキュリティ上の問題となるものです。あるサイトに書かれているスクリプトが別のサイトへとまたがって（クロスして）実行されることから、クロスサイト スクリプティングと呼ばれています。

ページの自動生成過程において、悪意ある者がそのページを構成する部分を記述できてしまう状態にあると想定します。 例えば、攻撃者はアクセスしてきた読者に意識させることなく他のサイトにある悪意あるプログラムをダウンロードさせるスクリプトを記述するように事前に処理させ たとします。そのページにアクセスした読者は、そのスクリプトが示す悪意あるプログラムによって侵害されます。別の例を挙げるならば、アクセスしに来る読者の cookie 情報を操作するスクリプトを記述するように 、事前に処理させて待ち構えていることも考えられます。

Webサーバーシステムで web ページを自動生成するプログラムを開発する際には、いかなる入力に基づいても、ページの生成処理過程で発信することを望まないスクリプトを含まないことを検証する機能が必要です。

背景・前提知識

大部分の webブラウザは、webサーバーからダウンロードされる webページに埋め込まれたスクリプトを解釈する機能を持っています。このようなスクリプトは各種スクリプト言語で書かれており 、ブラウザにより実行されます。大部分のブラウザは、デフォルトでスクリプトを実行してしまいます。例を掲げます。

1. フォーム等において書き込まれる悪意あるスクリプティング タグ

Webサーバーで掲示板を運営するサイトでは、悪意ある HTMLタグが書き込まれて、それがそのまま発信されることがあります。例えば、侵入者は以下のようなメッセージを投稿します。

Hello message board. This is a message.
＜ＳＣＲＩＰＴ＞悪意あるコード＜／ＳＣＲＩＰＴ＞
This is the end of my message.

スクリプト実行を有効にしているブラウザでこのメッセージを読み出すと、悪意あるプログラムが意に反して実行されます。このように埋め込み型のスクリプティング タグには ＜ＳＣＲＩＰＴ＞， ＜ＯＢＪＥＣＴ＞， ＜ＡＰＰＬＥＴ＞， ＜ＥＭＢＥＤ＞ 等があります。

2. 他のタグの悪用

スクリプティング タグ以外にも、＜ＦＯＲＭ＞ のような他の HTML タグは攻撃者に悪用される可能性があります。例えば、悪意ある ＜ＦＯＲＭ＞ タグを適当な場所に置き、既存のフォーム動作を書換え、ユーザの重要な情報を表示させるでことができます。他の HTMLタグを使って、ページの内容を書き換えたり、意図していたものと は異なるページを表示させることができてしまいます。

3. Cookie

Webサービスにおいて Cookie が用いられるのは、HTTPプロトコルがセッション管理をサポートしていないからです。HTTP におけるユーザ認証の仕組み(HTML Basic)には、ユーザIDとパスワードによるユーザ認証の仕組みがありますが、ログアウト等をサポートしていないため、複数ページに跨るようなセッションを管理 することができません。このセッション管理を行うために用いられる方法には、URLにセッション情報を含める方法や、セッション情報を格納した cookie を用いる方法 があります。

Cookie は、webサイトが作成するユーザやセッションに関する情報を含むデータで、ユーザの webブラウザに格納されます。この cookie は、cookie を作成した webサイトだけが利用できるため、通常であれば他のwebサイトに、特定のサイト用の cookie が漏洩する可能性はありません。

クロスサイト スクリプティング問題

対象となるサーバーシステム

入力値について、発信することを望まないスクリプティングがないことについての検証を行わずに動的にページを自動生成する webサーバーシステム

問題点： セッションにおける信頼の破綻

インターネット商取引のサイトを想定しましょう。次の例は、example.co.jp サイトとのセッションにおいて本人認証のセキュリティが処理されている場合を想定します。このページには、関連する 2つのサイトの URL が含まれてしまっています。

＜Ａ HREF="http://example.co.jp/comment.cgi? mycomment=SRC='http://bad-site/badfile'>＜／ＳＣＲＩＰＴ＞”＞ ここをクリック！＜／Ａ＞

この例の問題は、スクリプトまたは HTML タグに、そのセキュリティ関係外の URL があり、本人認証で処理したかった信頼が横取りされていることにあります。

＜ＳＣＲＩＰＴ＞ タグ中の SRC の属性には、悪意あるサイトとおぼしき場所からのコードが書かれています。この例はスクリプティングセキュリティモデルに最も重要な 「同一のソースを使用する規則」に反しています。

ほかの場所から送られるコードをある場所のページへ挿入していることから、「クロスサイト（"cross-site"）」スクリプティングの弱点と呼ばれています。

影響

悪意ある者がクロスサイト スクリプティングを webサーバーシステムに記述させた場合、様々な情報セキュリティ侵害が可能となってしまいます。いくつかを例示します。

1. SSL/TLS 接続におけるリスク

悪意あるスクリプトタグは SSL や TLS による接続がクライアントとサーバー間で確立される前に組み込まれます。SSL/TLS は、この接続が確立された後、悪意あるコードも例外とせずにデータを暗号化し、送受信します。SSL/TLS はクライアントとサーバ ー間の通信が盗聴されないことを保証しますが、送信されるデータの妥当性までは検証しません。

クライアントとサーバー間に正当な通信が行われているので、SSL/TLS は問題なしと処理します。悪意あるコードが非 SSL の URL へ接続しようとすると警告メッセージが表示されますが、攻撃者は単に SSL が実行されている webサーバーに変更することでこの警告を避けることができてしまいます。

2. 不正な cookie により攻撃を継続

本物のサイトから来たように見せかけた悪意あるコードを実行した場合、攻撃を継続させるように cookie が改ざんされる場合があります。とりわけ、脆弱な webサイトが動的に生成するページに cookie のフィールドを使用する場合、攻撃者は悪意あるコードに書き換えた cookie を含めます。次回、その webサイト（信頼しているリンクを通じて）へアクセスしようとすると、書き換えられた cookie を要求し、コードを含むcookie のフィールドに基づいてページを表示します。

3. サイトで設定するドメインのセキュリティポリシー回避

ブラウザの設定をホストやドメインからのスクリプト言語を実行可能にしていると、他からのアクセスを制限していても攻撃者はこのポリシーを違反することができてしまいます。

スクリプトを実行可能にしているサーバーへ送られたリクエストに悪意あるスクリプト タグを埋め込めば、攻撃者は特権を獲得することも可能です。

4. 一般的でない文字コード使用によるリスク

Webサーバーから返されるページに文字コードが特別指定されていない場合、ユーザが選択した文字コードでブラウザは情報を解釈します。しかし、ほとんどの web サイトでは文字コードを特別指定していないので（ISO-8859-1でエンコードした場合でさえ）代わりの文字コードを使用するユーザを危険にさせます。

5. フォームの動作を変えることができてしまう

環境によっては、攻撃者はフォームの動作を変更させて異なる結果を生成させることができます。

Webサーバーシステムのインテグレーターと webサイト管理者が意識すべき対策

1. ページを生成する際にメタキャラクタのエスケープ処理を怠らない

動的に生成されたページ中に意図しないタグが含まれないようにすることで、この問題を防ぐことができます。このためには、入力内容からメタキャラクタを削除する方法と、出力時にメタキャラクタをエスケープする方法があります。前者では他のリスクを伴う場合があるため、後者の方法を採ることをお薦めします。エスケープする必要のあるメタキャラクタは、HTMLのどの部分を生成しているかによって異なるからです。例えば、

＜Ａ HREF="どこか">

の「どこか」部分を生成する時点では、文字「"」をエスケープする（「"」に置き換える）必要がありますし、

＜Ａ HREF='どこか'>

の場合には、文字「'」をエスケープする必要があります。

この他に、「＜」は「<」、「>」は「>」、「&」は「&」にエスケープします。

また、動的に生成される web ページで設定される文字コードを定義することが推奨されます。

参考文献：
Understanding Malicious Content Mitigation for Web Developers
http://www.cert.org/tech_tips/malicious_code_mitigation.html

2. Webサーバー／Web アプリケーションのベンダー情報をチェック

Webサーバーのいくつかの製品はデフォルト インストールの場合、動的に生成されたページが含まれます。自らは動的なページを開発しなかったとしても、webサーバーの動的なページ生成機能に欠陥があった場合、この問題から逃れることはできません。

例えば、サーバー上で作られた「404 Not Found」のページに悪意あるコードが含まれているかもしません。各 web サーバーについて、ベンダーからの該当情報がないかをチェックしておく必要があります。
Web サーバー：
Apache： Cross Site Scripting Info
マイクロソフト： 「IIS クロスサイト スクリプティング」に対する脆弱性を解決する修正プログラム (MS00-060)

アプリケーションサーバー：
アイ・ティ・フロンティア： JRun クロスサイト スクリプティング問題に関する情報
日本BEAシステムズ： WebLogic Server におけるクロスサイト・スクリプティングの脆弱性について
日本IBM： WebSphere Cross-Site Scripting問題とその対処方法のお知らせ
富士通： Cross-Site Scripting 問題に関する INTERSTAGE の対応
ロータス： ドミノ Web サーバーにおけるクロスサイトスクリプティングの脆弱性問題

Web アプリケーション：
Namazu： Namazu セキュリティフィックスリリース

3. Cookie の漏洩に備えて

クロスサイト スクリプティング脆弱性を攻略することで、特定サイトの cookie が他のサイトに漏洩する可能性があります。従って webサーバーシステムの設計者は、万が一 cookie が漏洩した場合に備えて、以下の点に留意する必要があります。：
ユーザ認証に係る情報は極力 cookie には含めない (ユーザID、パスワード)
セッションID はセッション毎にランダムな値を生成することで、推測できないようにする
また、クロスサイト スクリプティング脆弱性とは直接の関係はありませんが、以下のような対策をとることで、よりセキュアに cookie の利用が可能になります。
Cookie の発行処理の設計において secure フラグの利用を検討する

参考文献

本件に関する詳細は、産業技術総合研究所 高木 浩光 氏らによる報告を参照ください。
「クロスサイトスクリプティング攻撃に対する電子商取引サイトの脆弱さの実態とその対策」
http://securit.etl.go.jp/research/paper/css2001-takagi-dist.pdf

CERT/CCによるアドバイザリ
「CA-2000-02: Malicious HTML Tags Embedded in Client Requests」
http://www.cert.org/advisories/CA-2000-02.html

CERT/CCによる概要説明

Cross-Site Scripting Vulnerabilities
http://www.cert.org/archive/pdf/cross_site_scripting.pdf

Microsoft社による情報は以下の通りです。
「クロスサイト スクリプティングのセキュリティ上の脆弱性に関する情報」
http://www.microsoft.com/JAPAN/technet/security/crssite.asp

注) 本脆弱性はMicrosoft社のサーバに限定されるものではありません。

この他「セキュアプログラミング」採択企業：セントラルコンピュータサービス社のコンテンツもあります。

セキュアWebプログラミング
http://www.trusnet.com/secinfo/docs/webprog1/index.html

更新履歴
2002年 3月 7日 参考文献として、CERT/CC の文書を追記
2001年12月27日 「2. Webサーバー／Web アプリケーションのベンダー情報をチェック」に情報追加。
2001年12月25日 「1. ページを生成する際にメタキャラクタのエスケープ処理を怠らない」、「2. Webサーバーのベンダー情報をチェック」に追記。
　 　
2001年11月 1日 Web サーバーシステムのインテグレーターおよび web サイト管理者向けの技術情報として追記
2001年10月31日 Webページの開発者とWebサイト管理者に対する対策に追記
2001年10月29日 Web サーバーシステムインテグレーター向けの技術情報を追記
2001年10月23日 掲載

問い合わせ先

IPA(情報処理振興事業協会)セキュリティセンター
e-mail: crack@ipa.go.jp

　次へ 　前へ

テスト７掲示板へ

フォローアップ:

• Re: テスト クエスチョン 2004/3/04 21:17:59 (0)

　

　

　

拍手はせず、拍手一覧を見る

---

★登録無しでコメント可能。今すぐ反映　通常 ｜動画・ツイッター等 ｜htmltag可（熟練者向）
（タグCheck ｜タグに'だけを使っている場合のcheck ｜checkしない）（各説明）

（←ペンネーム新規登録ならチェック）
↓ペンネーム（2023/11/26から必須）

↓パスワード（ペンネームに必須）

（ペンネームとパスワードは初回使用で記録、次回以降にチェック。パスワードはメモすべし。）
↓画像認証
（ 上画像文字を入力）
ルール確認＆失敗対策
画像の URL (任意):

投稿コメント全ログ 　コメント即時配信 　スレ建て依頼 　削除コメント確認方法

---

★阿修羅♪　http://www.asyura2.com/ 　since 1995
　題名には必ず「阿修羅さんへ」と記述してください。
掲示板,ＭＬを含むこのサイトすべての
一切の引用、転載、リンクを許可いたします。確認メールは不要です。
引用元リンクを表示してください。