データ処理装置及びデータ処理方法及びプログラム
【課題】クロスサイト・スクリプティングを有効に防止する。
【解決手段】Ｗｅｂアプリケーション実行装置１００が、特定種類のコードが埋め込まれている可能性のあるデータをクライアント装置２００からのＨＴＴＰリクエストから抽出し、ＨＴＴＰリクエストから抽出したデータと同じデータをＨＴＴＰレスポンスから抽出し、抽出したデータのうちＨＴＴＰレスポンス内で連続した位置に配置されている２以上のデータを連結し、連結されたデータに含まれている特定種類のコードを無効化する。これにより、特定種類のコードの配置がＷｅｂアプリケーション内部で変更された場合や、ＨＴＴＰリクエストにおいて分割されて送信された場合にも、特定種類のコードを無効化することができ、特定種類のコードをクロスサイト・スクリプティングに用いられる不正なコードとすることにより、クロスサイト・スクリプティングを有効に防止することができる。
【解決手段】Ｗｅｂアプリケーション実行装置１００が、特定種類のコードが埋め込まれている可能性のあるデータをクライアント装置２００からのＨＴＴＰリクエストから抽出し、ＨＴＴＰリクエストから抽出したデータと同じデータをＨＴＴＰレスポンスから抽出し、抽出したデータのうちＨＴＴＰレスポンス内で連続した位置に配置されている２以上のデータを連結し、連結されたデータに含まれている特定種類のコードを無効化する。これにより、特定種類のコードの配置がＷｅｂアプリケーション内部で変更された場合や、ＨＴＴＰリクエストにおいて分割されて送信された場合にも、特定種類のコードを無効化することができ、特定種類のコードをクロスサイト・スクリプティングに用いられる不正なコードとすることにより、クロスサイト・スクリプティングを有効に防止することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置からサーバ装置へのリクエストと、サーバ装置からクライアント装置へのレスポンスとを解析して、レスポンスに含まれている特定種類のコードを抽出し、抽出した特定種類のコードを無効化する技術に関する。
【背景技術】
【０００２】
クロスサイト・スクリプティング（以下、ＸＳＳとも表記する）は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）中に外部から入力されたデータを出力する動的生成ページにおいて、悪意のあるスクリプトコードを利用者のクライアント装置で実行させる攻撃である。
悪意のあるスクリプトコードは、撃攻者によって、クライアント装置からサーバ装置へ送信されるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエスト（以下、単にリクエストとも表記する）に混入させられる。
ＸＳＳを防ぐには、リクエストに混入しているスクリプトコードが動作しないようにする必要がある。
これは、サーバ装置のＷｅｂアプリケーション内部でリクエストに含まれる特定の文字を取り除くことで実現できる。
しかし、出力するＨＴＭＬ構文中のどの箇所にスクリプトコードが書き込まれるかより、取り除く文字が異なるため、悪意のあるスクリプトコードが動作しないようにするためには、ＨＴＭＬ構文中の位置ごとに取り除くべき文字を判別する必要がある。
このような対策は開発者が実装しなければならず、開発者の知識不足や不注意などで対策抜けが発生する可能性がある。
ＸＳＳを自動で対策する従来技術としては、リクエストに現れた不正コードがＨＴＴＰレスポンス（以下、単にレスポンスとも表記する）にも現れたときに攻撃に使われる特定の文字を取り除く方法が知られている（例えば、特許文献１）。
なお、ＨＴＭＬ構文の定義は、例えば、非特許文献１に示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−９２５６４号公報
【非特許文献】
【０００４】
【非特許文献１】ＨＴＭＬ ４．０１ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｈｔｍｌ４０１／
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術では、Ｗｅｂアプリケーションへのリクエストに含まれる攻撃データのＨＴＭＬ構造に応じて、不正コードを一旦記憶し、記憶した不正コードがレスポンスにそのまま現れた場合に攻撃に使われる特定の文字を取り除く。
このため、当該不正コードの配置がＷｅｂアプリケーション内部で変更された場合や、リクエストにおいて分割されて送信された場合にはＸＳＳを防ぐことができないという課題がある。
【０００６】
また、特許文献１の技術では、リクエストに含まれる攻撃データのＨＴＭＬ構造に応じて取り除く文字を選択していた。
このため、出力するＨＴＭＬ構文中のどの箇所にスクリプトが書き込まれているかにより、取り除く文字を変更する必要があるＸＳＳを正しく防ぐことができないという課題がある。
【０００７】
さらに、特許文献１の技術では、ＨＴＴＰリクエストのみを対象としている。
このため、データベースやファイルなどに一端保存された後に、別のリクエストで、保存されたデータを読み出す攻撃には対処できない。
例えば、不正コードを一旦データベースに保存し、別のページで再度これを読出す蓄積型ＸＳＳについては対処できないという課題がある。
【０００８】
この発明は、上記の課題を解決することを主な目的としており、クロスサイト・スクリプティングを有効に防止する構成を実現することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るデータ処理装置は、
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力部と、
前記リクエスト入力部により入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出部と、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力部と、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出部と、
前記無効化候補データ抽出部により複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結部と、
前記データ連結部により連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化部とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとしてリクエストから抽出し、レスポンスにおいて埋め込み先候補データと値が一致するデータを無効化候補データとして抽出し、レスポンス内で連続した位置に配置されている２以上の無効化候補データを連結し、連結された連結無効化候補データに含まれている特定種類のコードを無効化する。
このため、特定種類のコードの配置がＷｅｂアプリケーション内部で変更された場合や、特定種類のコードがリクエストにおいて分割されて送信された場合にも、特定種類のコードを無効化することができ、特定種類のコードをクロスサイト・スクリプティングに用いられる不正なコードとすることにより、クロスサイト・スクリプティングを有効に防止することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係るＷｅｂアプリケーション実行装置の構成例を示す図。
【図３】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図４】実施の形態１に係る入力データの例を示す図。
【図５】実施の形態１に係るＷｅｂアプリケーションからの応答の例を示す図。
【図６】実施の形態１に係るＷｅｂアプリケーションからの応答に対する解析の中間結果を示す図。
【図７】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図８】実施の形態１に係るＷｅｂアプリケーションからの応答に対する解析の最終結果を示す図。
【図９】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図１０】実施の形態１に係るＨＴＭＬ要素のレベルを説明する図。
【図１１】実施の形態１に係るＨＴＭＬ構文情報の例を示す図。
【図１２】実施の形態２に係るＷｅｂアプリケーション実行装置の構成例を示す図。
【図１３】実施の形態２に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図１４】実施の形態１及び２に係るＷｅｂアプリケーション実行装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１２】
実施の形態１．
本実施の形態では、Ｗｅｂアプリケーションに脆弱性が存在した場合でも脆弱性への攻撃を防ぐために、ＨＴＴＰリクエストなどの外部からの入力データをすべて記憶して、入力データを使って出力データを解析し、その解析結果に応じて、入力データの混入によって発生するＷｅｂアプリケーションの脆弱性への対策処理を行う構成を説明する。
【００１３】
図１は、実施の形態１に係るＷｅｂアプリケーション実行装置を含むシステムの概略図である。
【００１４】
図１において、本実施の形態に係るシステムは、Ｗｅｂアプリケーション実行装置１００、クライアント装置２００、ネットワーク３００（インターネット等のネットワーク）から構成される。
Ｗｅｂアプリケーション実行装置１００と複数のクライアント装置２００は、ネットワーク３００を介して接続される。
なお、Ｗｅｂアプリケーション実行装置１００は、データ処理装置及びサーバ装置の例である。
【００１５】
図２は、実施の形態１に係るＷｅｂアプリケーション実行装置１００の構成例を示す図である。
図２において、Ｗｅｂアプリケーション実行装置１００は、入力受信部１０１、入力記憶部１０２、Ｗｅｂアプリケーション１０３、出力検査部１０４、出力構文解析部１０５、出力送信部１０６、入力データ一致情報記憶部１０７、対策設定ファイル１０８で構成されている。
【００１６】
入力受信部１０１は、クライアント装置２００から送信されたＨＴＴＰリクエストを受信する。
また、入力受信部１０１は、受信したＨＴＴＰリクエストを解析し、ＨＴＴＰリクエスト内の複数のデータのうち、スクリプトコード（特定種類のコードの例）が埋め込まれている可能性のあるデータを入力データ（埋め込み先候補データに相当）として抽出する。
入力受信部１０１は、リクエスト入力部及び埋め込み先候補データ抽出部の例である。
また、入力受信部１０１により実行される処理が、リクエスト入力ステップ及び埋め込み先候補データ抽出ステップに相当する。
【００１７】
ここで、入力データとは、ＧＥＴメソッド等で与えられるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）ストリング内のパラメータの値（以後、ＧＥＴパラメータ値とよぶ）、ＰＯＳＴメソッドで与えられるパラメータの値（以後、ＰＯＳＴパラメータ値とよぶ）、Ｃｏｏｋｉｅ以外の各ＨＴＴＰヘッダの値（以後、ヘッダ値とよぶ）、Ｃｏｏｋｉｅの値（以後、Ｃｏｏｋｉｅ値とよぶ）である。
なお、ＧＥＴメソッドで与えられるパラメータは、ＨＴＴＰリクエストのリクエストラインに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）中のクエリストリングと呼ばれる部分で指定される。
クエリストリングは、ＵＲＩ内に含めた「？」後の文字列で指定され、パラメータの名前と値とを「＝」で区切った形式で指定する。また複数のパラメータを指定する場合には「＆」で区切る。
ＰＯＳＴメソッドで与えられるパラメータは、ＰＯＳＴメソッドで送信されたＨＴＴＰリクエストのボディ部に格納され、パラメータの名前と値とを「＝」で区切った形式で指定される。複数のパラメータを指定する場合には「＆」や「；」で区切られる。
ヘッダのパラメータは、ＨＴＴＰリクエストのヘッダで指定され、ヘッダの名前と値とを「：」で区切った形式で指定される。各ヘッダは改行で区切られる。
Ｃｏｏｋｉｅは、ＨＴＴＰリクエストのヘッダで指定され、ヘッダの名前が「Ｃｏｏｋｉｅ」となる。
Ｃｏｏｋｉｅの名前と値とを「＝」で区切った形式で指定される。
複数のパラメータを指定する場合には、複数のＣｏｏｋｉｅヘッダで指定するか、１つのヘッダ中で、Ｃｏｏｋｉｅの指定を「；」、「，」で区切る。
【００１８】
入力記憶部１０２は、入力受信部１０１で抽出された入力データを記憶し、Ｗｅｂアプリケーション実行装置１００がＨＴＴＰレスポンスをクライアント装置２００に返すまで保持する。
【００１９】
Ｗｅｂアプリケーション１０３は、受信したＨＴＴＰリクエストに応じた処理を行い、処理結果としてＨＴＴＰレスポンスを出力する。
【００２０】
出力検査部１０４は、Ｗｅｂアプリケーション１０３からＨＴＴＰレスポンスを入力する。
また、出力検査部１０４は、入力したＨＴＴＰレスポンスを解析し、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書に入力データが含まれるかを文字列比較により検査する。
つまり、出力検査部１０４は、ＨＴＴＰレスポンス内のデータのうち、入力データ（埋め込み先候補データ）と値が一致するデータを抽出する。
出力検査部１０４により抽出されたデータは、スクリプトコードが含まれている可能性があり、スクリプトコードを無効にする無効化処理（サニタイジング）の対象になる可能性があり、無効化候補データに相当する。
また、出力検査部１０４は、複数のデータを抽出した場合に、ＨＴＴＰレスポンス内での位置が連続している２以上のデータを検索し、検索の結果抽出した２以上のデータを連結する。
出力検査部１０４により連結されたデータは、連結無効化候補データに相当する。
出力検査部１０４は、レスポンス入力部、無効化候補データ抽出部、データ連結部の例である。
また、出力検査部１０４が実行する処理が、レスポンス入力ステップ、無効化候補データ抽出ステップ、データ連結ステップに相当する。
【００２１】
出力構文解析部１０５は、出力検査部１０４により抽出されたデータにスクリプトコードが含まれているか否かを判断し、また、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書を構文解析し、出力検査部１０４により抽出されたデータが含まれる場所がＨＴＭＬ構造中のどの位置になるかを特定し、その特定した位置に応じてＸＳＳ対策（スクリプトコードの無効化）を行う。
出力構文解析部１０５は、コード無効化部の例である。
また、出力構文解析部１０５により実行される処理が、コード無効化ステップに相当する。
【００２２】
出力送信部１０６は、ＨＴＴＰレスポンスをクライアント装置２００に対して送信する。
Ｗｅｂアプリケーション１０３からのＨＴＴＰレスポンスにスクリプトコードが含まれていたとしても、出力構文解析部１０５によりスクリプトコードが無効化されているので、出力送信部１０６からは無害なＨＴＴＰレスポンスが送信される。
【００２３】
入力データ一致情報記憶部１０７は、出力するＨＴＭＬ文書に含まれている入力データに関する情報を一時的に記録する。
つまり、入力データ一致情報記憶部１０７は、出力検査部１０４により抽出されたデータの情報を一時的に記録する。
なお、記録した情報は、ＨＴＴＰレスポンスのクライアント装置２００への送信とともにクリアされる。
【００２４】
対策設定ファイル１０８は、Ｗｅｂアプリケーション１０３内部で変換される可能性があるデータの変換パターンに関する設定と、出力検査部１０４での検査時に入力データと判定する最低文字数と、出力構文解析部１０５で実施するＸＳＳの脆弱性に対処するための処理内容とが記載されている。
スクリプトコードが含まれているＨＴＭＬ文書内での位置、つまり、スクリプトコードが含まれているデータがどのカテゴリー（開始タグ、終了タグ、要素内、属性値内、コンテンツ内など）に分類されるかにより無効化方式が変化するが、対策設定ファイル１０８における「出力構文解析部１０５で実施するＸＳＳの脆弱性に対処するための処理内容」とは、具体的には、カテゴリーごとのスクリプトコードの無効化方式が記述されている。
このように、対策設定ファイル１０８は、無効化方式情報の例に相当する。
【００２５】
次に、図３を用いて本実施の形態に係るＷｅｂアプリケーション実行装置１００の動作例を説明する。
【００２６】
クライアント装置２００からのＨＴＴＰリクエストがＷｅｂアプリケーション実行装置１００に到達すると、入力受信部１０１がＨＴＴＰリクエストを受信する（Ｓ１０１）。
【００２７】
ＨＴＴＰリクエストを受信した入力受信部１０１は、ＨＴＴＰリクエストに含まれるＧＥＴパラメータ値やＰＯＳＴパラメータ値、ヘッダ値、Ｃｏｏｋｉｅ値を入力データとして抽出し、入力記憶部１０２に記憶する（Ｓ１０２）。
この際に、入力データについて、まったく同じ文字列となるものは１つの入力データとして記憶する。
また、ＧＥＴパラメータについては、各パラメータ値のＵＲＬエンコーディングをデコードしたものを入力データとして記憶する。
入力データの記憶時には、対策設定ファイル１０８の内容に基づいて、特定のデータが変換された場合の文字列も入力データとして追加する（例えば、テキストエリアに記載された文字列の改行コードを＜ＢＲ＞などに変換する）。
入力受信部１０１により抽出され、入力記憶部１０２に記録された入力データは、例えば図４のようになる。
なお、図４の表の１行目は説明のために便宜上つけており実際には必要ない。
【００２８】
次に、入力受信部１０１は、受信したＨＴＴＰリクエストをそのままＷｅｂアプリケーション１０３に渡す（Ｓ１０３）。
ＨＴＴＰリクエストをＷｅｂアプリケーション１０３に渡した後には、Ｗｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３から応答が出力されるのを待つ（Ｓ１０４）。
【００２９】
Ｗｅｂアプリケーション１０３は、受け取ったＨＴＴＰリクエストの処理を行い、その結果をＨＴＴＰレスポンスとして出力する。
出力したＨＴＴＰレスポンスは、出力検査部１０４に渡る。
出力検査部１０４は、Ｗｅｂアプリケーション１０３から受け取ったＨＴＴＰレスポンスのボディがＨＴＭＬ文書であるかを調べる（Ｓ１０５）。
レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダが「ｔｅｘｔ／ｈｔｍｌ」または指定なしの場合には、ＨＴＴＰレスポンスのボディにＨＴＭＬ文書が含まれていると判定する。
ＨＴＭＬ文書が含まれていると判定した場合には、ステップＳ１０６に進む。
含まれていないと判定した場合には、ステップＳ１１１に進む。
【００３０】
ＨＴＴＰレスポンスのボディがＨＴＭＬ文書であると判定した場合には、出力検査部１０４は、ＨＴＴＰレスポンスのＨＴＭＬ文書に入力記憶部１０２に記憶されている各入力データと同じ文字列のデータが含まれるかを、文字列比較によって検査する。
検査の結果、ＨＴＭＬ文書中に入力データと同じ文字列のデータが含まれていた場合には、入力データ一致情報記憶部１０７に一致情報として、入力データと一致したデータ、一致が開始するのがＨＴＭＬ文書の何文字目か（以後、開始位置とよぶ）、および一致が終了するのがＨＴＭＬ文書の何文字目か（以後、終了位置とよぶ）を記憶する（Ｓ１０６）。
例えば、図４に示したデータが入力記憶部１０２に記録され、図５のようなＨＴＭＬ文書がＨＴＴＰレスポンスとして出力された場合には、入力データ一致情報記憶部１０７の記録は図６のようになる。
なお、図６の表の１列目と１行目は説明のため便宜上つけており実際には必要ない。
すべての入力データに対する比較が完了した時点で、入力データ一致情報記憶部１０７に情報を記憶した場合には、ステップＳ１０８に進む。
入力データ一致情報記憶部１０７に情報を記録していない場合、すなわち、入力データと同じ文字列のデータを抽出しなかった場合は、ステップＳ１１１に進む（Ｓ１０７）。
入力データ一致情報記憶部１０７に情報を記録した場合、すなわち、入力データと同じ文字列のデータを抽出した場合は、出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した文字列が連続している箇所を検索し、その情報を入力データ一致情報記憶部１０７に追加する（Ｓ１０８）。
【００３１】
Ｓ１０８の処理詳細を図７で説明する。
【００３２】
まず、出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した一致情報を読込み、一致情報（無効化候補データ）の個数をＮとする（Ｓ２０１）。
一致情報（無効化候補データ）の個数が２つ以上の場合にはＳ２０３に進み、それ以外の場合には処理を終了する（Ｓ２０２）。
次に、一致情報（無効化候補データ）の個数が２つ以上の場合には、本処理の初期化処理として、ループ用の変数をｎ＝１、ｍ＝２とする（Ｓ２０３）。
そして、ｎ≦Ｎの場合にはＳ２０５に進み処理を継続し、それ以外の場合には処理を終了する（Ｓ２０４）。
ｍ≦Ｎの場合にはＳ２０６に進み、それ以外の場合にはＳ２１３に進む（Ｓ２０５）。
そして、ｎ番目とｍ番目の一致情報がＨＴＭＬ文書中でｎ、ｍの順で、連続しているかを判定するために、ｎ番目の一致情報の終了位置（ｎ）＋１とｍ番目の一致情報の終了位置ｓ（ｍ）が等しいことを調べ（Ｓ２０６〜２０７）、等しい場合にはｎ番目の一致情報の入力データとｍ番目の一致情報の入力データをｎ、ｍの順で連結し、入力データ一致情報記憶部１０７に追加する。
なお、追加した一致情報の開始位置は、ｎ番目の一致情報の開始位置、終了位置はｍ番目の一致情報の終了位置となり、ｎは１つ増加する（Ｓ２０８）。
同様にｎ番目とｍ番目の一致情報がｍ、ｎの順で連続しているかを調べ、連続している場合には、ｎ番目の一致情報の入力データとｍ番目の一致情報の入力データをｍ、ｎの順で連結し、同様に入力データ一致情報記憶部１０７に連続している情報を追加する（Ｓ２０９〜Ｓ２１１）。
この場合は、追加した一致情報の開始位置は、ｍ番目の一致情報の開始位置、終了位置はｎ番目の一致情報の終了位置となり、ｎは１つ増加する。
以上の一致情報のｎ番目とｍ番目の一致情報に関する処理が完了したら、ｍを１増分しＳ２０５に戻る（Ｓ２１２）。
また、Ｓ２１３では、ｍがＮより大きい場合には、ｎを増分しｍをｎ＋１にする。
以上の処理を繰返すことで、入力データが連続している箇所を見つけることができる。
【００３３】
なお、Ｓ２０６〜Ｓ２０８でｎ番目とｍ番目の入力データがｎ、ｍの順で連続しているかを調べ、ｎ番目の入力データとｍ番目の入力データをｎ、ｍの順で連結することで、スクリプトコードが分割されている（ｎ番目の入力データとｍ番目の入力データが離間している場合も含む）ＨＴＴＰリクエストが送信された場合にも、有効にスクリプトコードを抽出することができる。
【００３４】
また、Ｓ２０９〜Ｓ２１１でｎ番目とｍ番目の入力データがｍ、ｎの順で連続しているかを調べ、ｎ番目の入力データとｍ番目の入力データをｍ、ｎの順で連結することで、ＨＴＴＰリクエストではｎ番目の入力データが前の位置に配置されｍ番目の入力データが後の位置に配置されていた（ｎ番目の入力データとｍ番目の入力データが離間している場合も含む）ものが、Ｗｅｂアプリケーション１０３によってＨＴＴＰリクエストでの順序とは逆に入力データが配置され、ＨＴＴＰレスポンスではｍ番目の入力データに続いてｎ番目の入力データが配置されるような場合にも、有効にスクリプトコードを抽出することができる。
【００３５】
再び図３に戻りＳ１０９から説明する。
出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した一致情報のうち２つの条件に合致するものを削除する（Ｓ１０９）。
１つ目の条件とは、他の一致情報に包含される一致情報である。
この条件は、各一致情報の開始位置と終了位置を比較することで判定できる。
例えば、ｎ番目の一致情報の開始位置をｓ（ｎ）、終了位置をｅ（ｎ）とする。
この場合に、ｎ番目の一致情報とｍ番目の一致情報を比較し、ｓ（ｎ）≦ｓ（ｍ）かつｅ（ｎ）≧ｅ（ｍ）が成立する時には、ｍ番目の一致情報はｎ番目の一致情報に含まれる。
この条件が成立する場合に、出力検査部１０４は、入力データ一致情報記憶部１０７からｍ番目の一致情報を削除する。
そして、２つ目の条件は、対策設定ファイル１０８で記載に記載された入力データと判定する最低文字数よりも短い一致情報である。
これは、入力データとみなせる文字列が短いため、攻撃データとしては成立しない入力データを削除するために行う。
これらを行った後に、出力検査部１０４は、出力構文解析部１０５にＷｅｂアプリケーションから受け取ったＨＴＴＰレスポンスを渡す。
例えば、図４に示したデータが入力記憶部１０２に記録され、図５のようなＨＴＭＬ文書が出力された場合には、入力データ一致情報記憶部１０７の記録は最終的には図８のようになる。
図８では、図６の３行目の入力データと４行目の入力データが連結されて、図８の４行目の連結データになっている。
なお、図６の３行目の入力データと４行目の入力データは、図８の４行目の連結データに包含されるので、削除されている。
また、図８の表の１列目と１行目は説明のため便宜上つけており実際には必要ない。
【００３６】
次に、出力構文解析部１０５は、出力検査部１０４から受け取ったＨＴＴＰレスポンスのＨＴＭＬ文書の構文を解析し、入力データがＨＴＭＬ構文中の何処に位置するのを特定し、その特定結果によりＸＳＳ対策を行う（Ｓ１１０）。
なお、ＨＴＭＬの構文の定義は非特許文献１で開示されており、この定義に従ってＨＴＭＬ文書の先頭から調べることで、構文解析を行っていく。
詳細は割愛するが、ＨＴＭＬ文書は、プレーンテキストを要素で括って文書をマークアップすることで、文書に構造や意味などを与えるものであり、要素内に要素を入れることが可能であり、構造的に文書を表すことができる。
要素は開始タグ、コンテンツ、終了タグの３つで構成される。
開始タグは、要素名を「＜」と「＞」で囲んだ形式であり、終了タグは要素名を「＜／」と［＞］で囲んだものになる。
また、必要に応じて、要素に属性と呼ばれる特性を付加してもよく、開始タグの内部に、要素名に続けて属性名＝属性値という形で記述する。
なお、内容を含まない要素については、終了タグをもたないものもある（例えば、改行を表す＜ＢＲ＞や入力フォームを表す＜ＩＮＰＵＴ＞など）。
なお、要素名と属性名については大文字と小文字を区別せず、属性値については、属性によって大文字と小文字を区別するかどうかが個別に定められる。
【００３７】
Ｓ１１０での出力構文解析部１０５の処理内容について、図９を使って説明する。
【００３８】
出力構文解析部１０５は、ＨＴＭＬ文書を読み出し、開始タグおよび終了タグとなる文字列パターンを、ＨＴＭＬ文書の先頭から抽出しながら（Ｓ３０１）、タグの文字列・開始位置・終了位置からなる一覧を作成する。
なお、タグの抽出は、正規表現「＜［ａ−ｚＡ−Ｚ／！］［＾＞］＊」などを使ってＨＴＭＬ文書を文字列検索すれば可能である。
なお、＜ＢＲ＞などの終了タグがなく属性もない要素については、抽出結果から除外する。
【００３９】
次に出力構文解析部１０５は、一覧抽出したタグを上から順に解析し、タグの要素名に基づき開始タグと終了タグの関係を解析して、ＨＴＭＬ文書の階層構造を調べる（Ｓ３０２）。
また、各要素が位置するタグ階層上の深さ（以後、レベルと呼ぶ）を算出する。
例えば、図１０のようなＨＴＭＬ文書の場合には、ＨＴＭＬ要素のレベルは０とし、ＢＯＤＹ要素はレベル１、ＤＩＶ要素とＦＯＲＭ要素はレベル２、ＩＮＰＵＴ要素はレベル３とする。
なお、前述したとおりＨＴＭＬに終了タグがない要素や省略できる要素があり、前述した非特許文献１で規定される定義に基づいて調査する。
【００４０】
次に、出力構文解析部１０５は、抽出した開始タグと終了タグの情報をまとめて、レベル、要素名、開始タグの内容、開始タグの開始位置、開始タグの終了位置、終了タグの開始位置、終了タグの終了位置を含む情報を作成する（Ｓ３０３）。
【００４１】
次に、出力構文解析部１０５は、開始タグの内容を要素名、属性名、属性値に分解する。
そして、要素名、属性名、属性値の開始位置、終了位置をそれぞれ算出する（Ｓ３０４）。
なお、属性値は「”」「’」などのクォートも含めたものとする。
そして、これらのＨＴＭＬの構造に関する情報をまとめたＨＴＭＬ構造情報をメモリ上に保持する。
このＨＴＭＬ構造情報は、各エントリが、要素か属性を示す種別（以後、種別とする）、要素または属性の名称、レベル（属性の場合には、その属性が含まれる要素のレベルと同じになる）を含み、さらに要素のエントリの場合には、開始タグの開始位置・終了位置、終了タグの開始位置・終了位置を含む。
属性のエントリの場合には、属性名の開始位置・終了位置、属性値の開始位置、属性値の終了位置を含む。
例えば、ＨＴＭＬ構文情報のイメージは図１１のようになる。
種別の欄の「Ｅ」は要素、「Ａ」は属性、「Ｖ」は属性値であることを示している。
なお、図１１の表の一行目は説明の便宜上のために記載したものであり、実際には必要がない。
また、要素名、属性名についてレベルに応じてインデントしているが、実際には必要がない。
ここまで解析した段階で、入力データ一致情報記憶部１０７の情報および、出力構文解析部１０５で解析したＨＴＭＬ文書の構文情報を使って、ＨＴＭＬ文書に含まれる入力データが、ＨＴＭＬ構文中の何処の領域に含まれるかを特定していく。
【００４２】
出力構文解析部１０５は、入力データ一致情報記憶部１０７に記憶する各データの開始位置、終了位置の情報と、ＨＴＭＬ構文情報の開始位置／終了位置を比較して、各入力データが、開始タグ、終了タグ、要素内、属性値内、属性値内、それら以外（コンテンツ内と呼ぶ）のいずれかの領域に含まれるか、複数の領域に跨るかを判別する（Ｓ３０５）。
【００４３】
以上の手順で特定した入力データが位置する領域に基づき、出力構文解析部１０５は、出力送信部１０６に渡す前に、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書に対して、ＸＳＳ対策を行う（Ｓ３０６）。
各領域でのＸＳＳ対策は、対策設定ファイル１０８で指定されている。
例えば、入力データが属性値やコンテンツに出力されている場合には以下のように対策を行う。
【００４４】
入力データが属性値の場合
ｈｒｅｆとｓｒｃ：入力データがｈｔｔｐ：／／、ｈｔｔｐｓ：／／で始まる場合にのみＵＲＬのみに限定し、出力する場合も、クエリストリングにあたる箇所はＵＲＬエンコーディングする。
ｓｔｙｌｅ：英数字以外は￥ｘＨＨ；形式でエンコードする。
イベントハンドラ：ｓｔｙｌｅの場合と同様
上記以外：入力データをエンティティ表現へ変換する。
【００４５】
入力データがコンテンツ内の場合
ＨＴＭＬ構文情報を確認して、上のレベルにＳＣＲＩＰＴ要素がないかを調べる。
ＳＣＲＩＰＴ要素が上のレベルに存在する場合には、該当する入力データをすべて半角スペースに置換する。
また、上のレベルにＳＣＲＩＰＴ要素が存在しない場合には、該当する入力データをすべてエンティティ表現でエスケープする。
【００４６】
最後に、出力送信部１０６が、出力構文解析部１０５または出力検査部１０４から受け取ったＨＴＴＰレスポンスをクライアント装置２００に送信し、入力記憶部１０２に記憶した入力データをすべてクリアする（ステップＳ１１１）。
【００４７】
以上のように、クライアント装置からＷｅｂアプリケーションへのＨＴＴＰリクエストに含まれる入力データをすべて一旦記憶しておくことで、Ｗｅｂアプリケーションから出力されたＨＴＭＬ文書に入力データが含まれているかを調べることができる。
さらに、出力するＨＴＴＰレスポンスを構文解析してスクリプトコードを抽出し、スクリプトコードの１ステートメント以上に入力データが含まれるかを調べることで、Ｗｅｂアプリケーション内部で出力した文字列が入力データと一致した場合においても、誤って脆弱性対策を施すことを省くことができる。
さらに、入力データが連続する箇所を１つの入力データとして扱うことで、攻撃データが別の入力データとして分割されて、出力時に連結して攻撃データとなる場合についても、攻撃データであることを検知することができる。
【００４８】
本実施の形態では、レスポンスデータにＨＴＭＬ文書が含まれるか否かをレスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダを確認することで行っている。
ただし、ブラウザによってはＣｏｎｔｅｎｔ−Ｔｙｐｅにｉｍａｇｅ／ｇｉｆなどの画像データが指定された場合にでも、データ自体がＨＴＭＬであるとブラウザが判定すると、ＨＴＭＬ文書として表示するブラウザもある。
このため、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダで判定を行わずに、その後のＨＴＭＬ構文解析処理の段階で、ＨＴＭＬか否かを判定しても良い。
【００４９】
本実施の形態では、事前に定められたＸＳＳの対策処理を施したが、ＸＳＳの対策処理の方法をファイルなどで設定し、その設定情報を読込むことで、脆弱性対策の方法を変更することも可能である。
【００５０】
以上、本実施の形態では、
Ｗｅｂアプリケーションで利用するデータについて外部から入力されたデータを記憶し、Ｗｅｂアプリケーションから外部にデータを出力する際に、出力データ中に外部から入力されたデータが含まれている場所を特定し、その場所のデータ構造に応じて、攻撃に対策方法を変更するＷｅｂアプリケーション実行装置を説明した。
【００５１】
また、本実施の形態では、
ＨＴＭＬを構文解析し、ＨＴＭＬ文中に上記パターンが出力される場所を特定し、出力場所に応じて取り除くべき文字を特定するＷｅｂアプリケーション実行装置を説明した。
【００５２】
実施の形態２．
以上の実施の形態１では、ＨＴＴＰリクエストに攻撃データが含まれていた場合に、そのレスポンスに攻撃データが含まれていることを検知するものであるが、次に、ＨＴＴＰリクエストからの攻撃データが一旦データベースなどに保存され、別のリクエストに対するレスポンスに攻撃データが現れる場合（蓄積型ＸＳＳ）に脆弱性対策を行うための実施の形態を示す。
【００５３】
図１２は、この実施の形態に係るＷｅｂアプリケーション実行装置１００の構成図である。
図２において、Ｗｅｂアプリケーション実行装置１００は、実施の形態１の構成要素に加えて、データベース１０９、ＤＢ監視部１１０、ＤＢ監視設定ファイル１１１、外部データ識別ファイル１１２が加わっている。
【００５４】
データベース１０９は、Ｗｅｂアプリケーション１０３が利用するデータベースである。
【００５５】
ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３がデータベース１０９へアクセスする際のＳＱＬ文を監視し、データベース１０９への書込みと読込みを判定する。
Ｗｅｂアプリケーション１０３が、入力記憶部１０２に記録されている入力データ（埋め込み先候補データ）をデータベース１０９に書き込んだ場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３が入力データを書き込んだテーブル名／カラム名を外部データ識別ファイル１１２に記録する。
また、Ｗｅｂアプリケーション１０３が、外部データ識別ファイル１１２に記載されているテーブル名／カラム名のデータをデータベース１０９から読込んだ場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３がデータベース１０９から読込んだデータを入力記憶部１０２に追加する。
ＤＢ監視部１１０は、書き込みアクセス監視部及び読み出しアクセス監視部の例である。
なお、書込み／読込みを判別するための設定情報は、ＤＢ監視設定ファイル１１１に記述されている。
【００５６】
ＤＢ監視設定ファイル１１１は、ＤＢ監視部１１０がＳＱＬ文を監視することで、データベース１０９への書込みや読込みを判定するための設定情報が記載されたファイルである。
例えば、ＵＰＤＡＴＥ文が発行された場合には、書込みと判断し、ＳＥＬＥＣＴ文などが発行された場合には読込みと判定するための設定が含まれている。
【００５７】
外部データ識別ファイル１１２は、Ｗｅｂアプリケーション１０３がデータベース１０９へ外部データ（入力記憶部１０２に記録されている入力データ）を書き込んだとＤＢ監視部１１０が判定した場合に、外部データを書込んだテーブル名とカラム名を記録するためのファイルである。
外部データ識別ファイル１１２に記録される、外部データを書込んだテーブル名とカラム名の情報は、書き込み情報の例である。
【００５８】
次に図１３を使ってデータベース１０９に外部データが書き込まれる場合の動作を説明する。
【００５９】
クライアント装置２００からのＨＴＴＰリクエストがＷｅｂアプリケーション実行装置１００に到達すると、実施の形態１のＳ１０１〜Ｓ１０４と同様に、入力受信部１０１でＨＴＴＰリクエストを受信し、ＨＴＴＰリクエストの入力データを抽出して、入力記憶部１０２に記憶する。
そして、Ｗｅｂアプリケーション１０３にＨＴＴＰリクエストを渡す。
その後、Ｗｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３からの応答を待機する（Ｓ４０１〜Ｓ４０４）。
【００６０】
その後、Ｗｅｂアプリケーション１０３がデータベース１０９にアクセスする（Ｓ４０５）。
ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３からデータベース１０９に送信されるＳＱＬ文を分析し、ＤＢ監視設定ファイル１１１の設定内容に従って、データベース１０９への書込み処理か、読込み処理かを判別する（Ｓ４０６）。
例えば、ＵＰＤＡＴＥ文が発行された場合は書込み、ＳＥＬＥＣＴ文が発行された場合は読込みと判定する。
書込み処理と判定した場合にはＳ４０７に進み、読込み処理と判定した場合にはＳ４０９に進む。
【００６１】
書込み処理と判定した場合には、ＤＢ監視部１１０は、文字列比較によりデータベース１０９へのＳＱＬ文に、入力記憶部１０２に記憶されている入力データと同じものがあるか否か、すなわち、入力データのデータベース１０９への書き込みが行われているか否かを判断し（Ｓ４０７）、入力データの書き込みが行われている場合には、Ｓ４０８に進み、入力データ以外のデータの書き込みが行われている場合はＳ４１２に進む。
【００６２】
入力記憶部１０２に記憶されている入力データがデータベース１０９に書込まれているとＤＢ監視部１１０が判定したら、ＤＢ監視部１１０はＳＱＬ文から入力データを書込むテーブル名、カラム名及び値を抽出し、抽出したテーブル名、カラム名及び値を書き込み情報として外部データ識別ファイル１１２に書込む（Ｓ４０８）。
例えば、以下のＳＱＬ文の場合、ｕｓｅｒＴａｂｌｅをテーブル名、ｎａｍｅ１をカラム名と、Ｔａｎａｋａを値と判断する。
ＵＰＤＡＴＡＥ ｕｓｅｒｔＴａｂｌｅ ＳＥＴ ｎａｍｅ１ ＝ “Ｔａｎａｋａ”；
なお、既に同じテーブル名とカラム名が書込み済みである場合には、テーブル名／カラム名は外部データ識別ファイル１１２に書込む必要がなく、同じテーブル名／カラム名のエントリに値のみを追加する。
また、既に同じテーブル名、カラム名、値が書込み済みである場合には、外部データ識別ファイル１１２に書込む必要がない。
また、データベースアクセスがエラーとなった場合にも、テーブル名／カラム名の情報を書き込む必要はない。
この処理が完了したらＳ４１２に進む。
【００６３】
一方、Ｓ４０６において、Ｗｅｂアプリケーション１０３がデータベース１０９からデータを読込んでいるとＤＢ監視部１１０が判定したら、ＳＱＬ文からデータを読込むテーブル名とカラム名を抽出し、外部データ識別ファイル１１２にそれらテーブル名／カラム名の記載がないかを調べる（Ｓ４０９）。
例えば、以下のＳＱＬ文の場合、テーブル名ｕｓｅｒＴａｂｌｅからカラム名ｎａｍｅ１を読込んでいる。
ＳＥＬＥＣＴ ｎａｍｅ１ ＦＲＯＭ ｕｓｅｒｔＴａｂｌｅ；
外部データ識別ファイル１１２に記載があるテーブル名／カラム名からデータを読込んだと判定した場合には、Ｓ４１０に進み、異なるテーブル名／カラム名からデータを読込んだと判定した場合にはＳ４１２に進む。
【００６４】
Ｗｅｂアプリケーション１０３が外部データ識別ファイル１１２に記載があるテーブル名／カラム名からデータを読込んだ場合には、ＤＢ監視部１１０は、外部データ識別ファイル１１２のテーブル名／カラム名のエントリに記載された値と同じデータが読込みのＳＱＬ文のレスポンスに含まれていないかを調べる（Ｓ４１０）。
つまり、Ｗｅｂアプリケーション１０３により読み出されたデータが外部データ識別ファイル１１２に記述されている入力データと一致するか否かを判断する。
データがＳＱＬ文のレスポンスに含まれている場合にはＳ４１１に進み、含まれていない場合にはＳ４１２に進む。
【００６５】
ＳＱＬ文のレスポンスに外部データ識別ファイル１１２に記載の値と同じデータが含まれている場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３が読込んだデータを入力記憶部１０２に追加する（Ｓ４１１）。
なお、ＤＢ監視部１１０が入力記憶部１０２に追加したデータの情報は、読み出し情報に相当する。
【００６６】
Ｓ４１２では、実施の形態１の図３記載のＳ１０５〜Ｓ１１１と同じ処理を行う。
つまり、出力検査部１０４は、ＨＴＴＰレスポンス内のＨＴＭＬ文書に対して、入力受信部１０１がＨＴＴＰリクエストから抽出し入力記憶部１０２に記録した入力データと一致するデータを検索するとともに、ＤＢ監視部１１０が入力記憶部１０２に記録したデータ（Ｗｅｂアプリケーション１０３がデータベース１０９から読み込んだデータ）と一致するデータも検索する。
【００６７】
以上のように、本実施の形態では、Ｗｅｂアプリケーションによるデータベースへの書き込みを監視して、データベースへの外部入力データの書き込みを監視することで、攻撃データをＨＴＴＰリクエストで送信し、一旦データベース等に蓄積された後に、別のＨＴＴＰリクエストでその蓄積された攻撃データを読込んでＨＴＭＬに出力することで発生する蓄積型ＸＳＳを防ぐことができる。
【００６８】
以上、本実施の形態では、
Ｗｅｂアプリケーションで利用するデータが、外部入力のデータであることを記憶し、入力データを利用する各処理の実行時に、処理内容に応じて、適切なサニタイズ処理を動的に選択するＷｅｂアプリケーション実行装置を説明した。
【００６９】
また、本実施の形態では、
Ｗｅｂアプリケーションに外部入力がＤＢへの書込まれるＤＢのテーブル名とカラム名と値を記憶しておき、当該テーブル／カラムから読込まれたデータから書込んだ値と同じ値が含まれている場合には、外部入力データとみなして脆弱性の検査対象に加えるＷｅｂアプリケーション実行装置を説明した。
【００７０】
なお、実施の形態１及び２に係るＷｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３を実行するサーバ機能と、ＨＴＴＰリクエストから入力データを抽出し、ＨＴＴＰレスポンスに入力データと一致するデータが含まれているかを検査するフィルタ機能の双方を有することになっている。
実施の形態１及び２に示した構成の他に、Ｗｅｂアプリケーション１０３を実行する装置をサーバ装置とし、フィルタ処理を実行する装置をデータ処理装置として分離し、データ処理装置をクライアント装置２００とサーバ装置の間に介在させる構成としてもよい。
この場合は、データ処理装置は、実施の形態１の構成では、例えば、入力受信部１０１、入力記憶部１０２、出力検査部１０４、出力構文解析部１０５、出力送信部１０６で構成される。
また、実施の形態２の構成では、例えば、入力受信部１０１、入力記憶部１０２、出力検査部１０４、出力構文解析部１０５、出力送信部１０６、ＤＢ監視部１１０、ＤＢ監視設定ファイル１１１、外部データ識別ファイル１１２で構成される。
【００７１】
最後に、実施の形態１及び２に示したＷｅｂアプリケーション実行装置１００のハードウェア構成例について説明する。
図１４は、実施の形態１及び２に示すＷｅｂアプリケーション実行装置１００のハードウェア資源の一例を示す図である。
なお、図１４の構成は、あくまでもＷｅｂアプリケーション実行装置１００のハードウェア構成の一例を示すものであり、Ｗｅｂアプリケーション実行装置１００のハードウェア構成は図１４に記載の構成に限らず、他の構成であってもよい。
【００７２】
図１４において、Ｗｅｂアプリケーション実行装置１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１及び２で説明した「入力記憶部１０２」、「入力データ一致情報記憶部１０７」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
また、実施の形態２で説明した「データベース１０９」は、例えば、磁気ディスク装置９２０により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００７３】
通信ボード９１５は、図１に示すように、ネットワークに接続されている。
通信ボード９１５は、インターネットの他、例えば、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。
【００７４】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００７５】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００７６】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
Ｗｅｂアプリケーション実行装置１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００７７】
上記プログラム群９２３には、実施の形態１及び２の説明において「〜部」（「入力記憶部１０２」、「入力データ一致情報記憶部１０７」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００７８】
ファイル群９２４には、実施の形態１及び２の説明において、「〜の判断」、「〜の判定」、「〜の解析」、「〜の比較」、「〜の検索」、「〜の抽出」、「〜の追加」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の監視」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１及び２で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００７９】
また、実施の形態１及び２の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１及び２で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「データ処理方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１及び２の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１及び２の「〜部」の手順や方法をコンピュータに実行させるものである。
【００８０】
このように、実施の形態１及び２に示すＷｅｂアプリケーション実行装置１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００８１】
１００ Ｗｅｂアプリケーション実行装置、１０１ 入力受信部、１０２ 入力記憶部、１０３ Ｗｅｂアプリケーション、１０４ 出力検査部、１０５ 出力構文解析部、１０６ 出力送信部、１０７ 入力データ一致情報記憶部、１０８ 対策設定ファイル、１０９ データベース、１１０ ＤＢ監視部、１１１ ＤＢ監視設定ファイル、１１２ 外部データ識別ファイル、２００ クライアント装置、３００ ネットワーク。
【技術分野】
【０００１】
本発明は、クライアント装置からサーバ装置へのリクエストと、サーバ装置からクライアント装置へのレスポンスとを解析して、レスポンスに含まれている特定種類のコードを抽出し、抽出した特定種類のコードを無効化する技術に関する。
【背景技術】
【０００２】
クロスサイト・スクリプティング（以下、ＸＳＳとも表記する）は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）中に外部から入力されたデータを出力する動的生成ページにおいて、悪意のあるスクリプトコードを利用者のクライアント装置で実行させる攻撃である。
悪意のあるスクリプトコードは、撃攻者によって、クライアント装置からサーバ装置へ送信されるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエスト（以下、単にリクエストとも表記する）に混入させられる。
ＸＳＳを防ぐには、リクエストに混入しているスクリプトコードが動作しないようにする必要がある。
これは、サーバ装置のＷｅｂアプリケーション内部でリクエストに含まれる特定の文字を取り除くことで実現できる。
しかし、出力するＨＴＭＬ構文中のどの箇所にスクリプトコードが書き込まれるかより、取り除く文字が異なるため、悪意のあるスクリプトコードが動作しないようにするためには、ＨＴＭＬ構文中の位置ごとに取り除くべき文字を判別する必要がある。
このような対策は開発者が実装しなければならず、開発者の知識不足や不注意などで対策抜けが発生する可能性がある。
ＸＳＳを自動で対策する従来技術としては、リクエストに現れた不正コードがＨＴＴＰレスポンス（以下、単にレスポンスとも表記する）にも現れたときに攻撃に使われる特定の文字を取り除く方法が知られている（例えば、特許文献１）。
なお、ＨＴＭＬ構文の定義は、例えば、非特許文献１に示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−９２５６４号公報
【非特許文献】
【０００４】
【非特許文献１】ＨＴＭＬ ４．０１ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｈｔｍｌ４０１／
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の技術では、Ｗｅｂアプリケーションへのリクエストに含まれる攻撃データのＨＴＭＬ構造に応じて、不正コードを一旦記憶し、記憶した不正コードがレスポンスにそのまま現れた場合に攻撃に使われる特定の文字を取り除く。
このため、当該不正コードの配置がＷｅｂアプリケーション内部で変更された場合や、リクエストにおいて分割されて送信された場合にはＸＳＳを防ぐことができないという課題がある。
【０００６】
また、特許文献１の技術では、リクエストに含まれる攻撃データのＨＴＭＬ構造に応じて取り除く文字を選択していた。
このため、出力するＨＴＭＬ構文中のどの箇所にスクリプトが書き込まれているかにより、取り除く文字を変更する必要があるＸＳＳを正しく防ぐことができないという課題がある。
【０００７】
さらに、特許文献１の技術では、ＨＴＴＰリクエストのみを対象としている。
このため、データベースやファイルなどに一端保存された後に、別のリクエストで、保存されたデータを読み出す攻撃には対処できない。
例えば、不正コードを一旦データベースに保存し、別のページで再度これを読出す蓄積型ＸＳＳについては対処できないという課題がある。
【０００８】
この発明は、上記の課題を解決することを主な目的としており、クロスサイト・スクリプティングを有効に防止する構成を実現することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るデータ処理装置は、
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力部と、
前記リクエスト入力部により入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出部と、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力部と、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出部と、
前記無効化候補データ抽出部により複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結部と、
前記データ連結部により連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化部とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとしてリクエストから抽出し、レスポンスにおいて埋め込み先候補データと値が一致するデータを無効化候補データとして抽出し、レスポンス内で連続した位置に配置されている２以上の無効化候補データを連結し、連結された連結無効化候補データに含まれている特定種類のコードを無効化する。
このため、特定種類のコードの配置がＷｅｂアプリケーション内部で変更された場合や、特定種類のコードがリクエストにおいて分割されて送信された場合にも、特定種類のコードを無効化することができ、特定種類のコードをクロスサイト・スクリプティングに用いられる不正なコードとすることにより、クロスサイト・スクリプティングを有効に防止することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係るＷｅｂアプリケーション実行装置の構成例を示す図。
【図３】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図４】実施の形態１に係る入力データの例を示す図。
【図５】実施の形態１に係るＷｅｂアプリケーションからの応答の例を示す図。
【図６】実施の形態１に係るＷｅｂアプリケーションからの応答に対する解析の中間結果を示す図。
【図７】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図８】実施の形態１に係るＷｅｂアプリケーションからの応答に対する解析の最終結果を示す図。
【図９】実施の形態１に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図１０】実施の形態１に係るＨＴＭＬ要素のレベルを説明する図。
【図１１】実施の形態１に係るＨＴＭＬ構文情報の例を示す図。
【図１２】実施の形態２に係るＷｅｂアプリケーション実行装置の構成例を示す図。
【図１３】実施の形態２に係るＷｅｂアプリケーション実行装置の動作例を示すフローチャート図。
【図１４】実施の形態１及び２に係るＷｅｂアプリケーション実行装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１２】
実施の形態１．
本実施の形態では、Ｗｅｂアプリケーションに脆弱性が存在した場合でも脆弱性への攻撃を防ぐために、ＨＴＴＰリクエストなどの外部からの入力データをすべて記憶して、入力データを使って出力データを解析し、その解析結果に応じて、入力データの混入によって発生するＷｅｂアプリケーションの脆弱性への対策処理を行う構成を説明する。
【００１３】
図１は、実施の形態１に係るＷｅｂアプリケーション実行装置を含むシステムの概略図である。
【００１４】
図１において、本実施の形態に係るシステムは、Ｗｅｂアプリケーション実行装置１００、クライアント装置２００、ネットワーク３００（インターネット等のネットワーク）から構成される。
Ｗｅｂアプリケーション実行装置１００と複数のクライアント装置２００は、ネットワーク３００を介して接続される。
なお、Ｗｅｂアプリケーション実行装置１００は、データ処理装置及びサーバ装置の例である。
【００１５】
図２は、実施の形態１に係るＷｅｂアプリケーション実行装置１００の構成例を示す図である。
図２において、Ｗｅｂアプリケーション実行装置１００は、入力受信部１０１、入力記憶部１０２、Ｗｅｂアプリケーション１０３、出力検査部１０４、出力構文解析部１０５、出力送信部１０６、入力データ一致情報記憶部１０７、対策設定ファイル１０８で構成されている。
【００１６】
入力受信部１０１は、クライアント装置２００から送信されたＨＴＴＰリクエストを受信する。
また、入力受信部１０１は、受信したＨＴＴＰリクエストを解析し、ＨＴＴＰリクエスト内の複数のデータのうち、スクリプトコード（特定種類のコードの例）が埋め込まれている可能性のあるデータを入力データ（埋め込み先候補データに相当）として抽出する。
入力受信部１０１は、リクエスト入力部及び埋め込み先候補データ抽出部の例である。
また、入力受信部１０１により実行される処理が、リクエスト入力ステップ及び埋め込み先候補データ抽出ステップに相当する。
【００１７】
ここで、入力データとは、ＧＥＴメソッド等で与えられるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）ストリング内のパラメータの値（以後、ＧＥＴパラメータ値とよぶ）、ＰＯＳＴメソッドで与えられるパラメータの値（以後、ＰＯＳＴパラメータ値とよぶ）、Ｃｏｏｋｉｅ以外の各ＨＴＴＰヘッダの値（以後、ヘッダ値とよぶ）、Ｃｏｏｋｉｅの値（以後、Ｃｏｏｋｉｅ値とよぶ）である。
なお、ＧＥＴメソッドで与えられるパラメータは、ＨＴＴＰリクエストのリクエストラインに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）中のクエリストリングと呼ばれる部分で指定される。
クエリストリングは、ＵＲＩ内に含めた「？」後の文字列で指定され、パラメータの名前と値とを「＝」で区切った形式で指定する。また複数のパラメータを指定する場合には「＆」で区切る。
ＰＯＳＴメソッドで与えられるパラメータは、ＰＯＳＴメソッドで送信されたＨＴＴＰリクエストのボディ部に格納され、パラメータの名前と値とを「＝」で区切った形式で指定される。複数のパラメータを指定する場合には「＆」や「；」で区切られる。
ヘッダのパラメータは、ＨＴＴＰリクエストのヘッダで指定され、ヘッダの名前と値とを「：」で区切った形式で指定される。各ヘッダは改行で区切られる。
Ｃｏｏｋｉｅは、ＨＴＴＰリクエストのヘッダで指定され、ヘッダの名前が「Ｃｏｏｋｉｅ」となる。
Ｃｏｏｋｉｅの名前と値とを「＝」で区切った形式で指定される。
複数のパラメータを指定する場合には、複数のＣｏｏｋｉｅヘッダで指定するか、１つのヘッダ中で、Ｃｏｏｋｉｅの指定を「；」、「，」で区切る。
【００１８】
入力記憶部１０２は、入力受信部１０１で抽出された入力データを記憶し、Ｗｅｂアプリケーション実行装置１００がＨＴＴＰレスポンスをクライアント装置２００に返すまで保持する。
【００１９】
Ｗｅｂアプリケーション１０３は、受信したＨＴＴＰリクエストに応じた処理を行い、処理結果としてＨＴＴＰレスポンスを出力する。
【００２０】
出力検査部１０４は、Ｗｅｂアプリケーション１０３からＨＴＴＰレスポンスを入力する。
また、出力検査部１０４は、入力したＨＴＴＰレスポンスを解析し、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書に入力データが含まれるかを文字列比較により検査する。
つまり、出力検査部１０４は、ＨＴＴＰレスポンス内のデータのうち、入力データ（埋め込み先候補データ）と値が一致するデータを抽出する。
出力検査部１０４により抽出されたデータは、スクリプトコードが含まれている可能性があり、スクリプトコードを無効にする無効化処理（サニタイジング）の対象になる可能性があり、無効化候補データに相当する。
また、出力検査部１０４は、複数のデータを抽出した場合に、ＨＴＴＰレスポンス内での位置が連続している２以上のデータを検索し、検索の結果抽出した２以上のデータを連結する。
出力検査部１０４により連結されたデータは、連結無効化候補データに相当する。
出力検査部１０４は、レスポンス入力部、無効化候補データ抽出部、データ連結部の例である。
また、出力検査部１０４が実行する処理が、レスポンス入力ステップ、無効化候補データ抽出ステップ、データ連結ステップに相当する。
【００２１】
出力構文解析部１０５は、出力検査部１０４により抽出されたデータにスクリプトコードが含まれているか否かを判断し、また、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書を構文解析し、出力検査部１０４により抽出されたデータが含まれる場所がＨＴＭＬ構造中のどの位置になるかを特定し、その特定した位置に応じてＸＳＳ対策（スクリプトコードの無効化）を行う。
出力構文解析部１０５は、コード無効化部の例である。
また、出力構文解析部１０５により実行される処理が、コード無効化ステップに相当する。
【００２２】
出力送信部１０６は、ＨＴＴＰレスポンスをクライアント装置２００に対して送信する。
Ｗｅｂアプリケーション１０３からのＨＴＴＰレスポンスにスクリプトコードが含まれていたとしても、出力構文解析部１０５によりスクリプトコードが無効化されているので、出力送信部１０６からは無害なＨＴＴＰレスポンスが送信される。
【００２３】
入力データ一致情報記憶部１０７は、出力するＨＴＭＬ文書に含まれている入力データに関する情報を一時的に記録する。
つまり、入力データ一致情報記憶部１０７は、出力検査部１０４により抽出されたデータの情報を一時的に記録する。
なお、記録した情報は、ＨＴＴＰレスポンスのクライアント装置２００への送信とともにクリアされる。
【００２４】
対策設定ファイル１０８は、Ｗｅｂアプリケーション１０３内部で変換される可能性があるデータの変換パターンに関する設定と、出力検査部１０４での検査時に入力データと判定する最低文字数と、出力構文解析部１０５で実施するＸＳＳの脆弱性に対処するための処理内容とが記載されている。
スクリプトコードが含まれているＨＴＭＬ文書内での位置、つまり、スクリプトコードが含まれているデータがどのカテゴリー（開始タグ、終了タグ、要素内、属性値内、コンテンツ内など）に分類されるかにより無効化方式が変化するが、対策設定ファイル１０８における「出力構文解析部１０５で実施するＸＳＳの脆弱性に対処するための処理内容」とは、具体的には、カテゴリーごとのスクリプトコードの無効化方式が記述されている。
このように、対策設定ファイル１０８は、無効化方式情報の例に相当する。
【００２５】
次に、図３を用いて本実施の形態に係るＷｅｂアプリケーション実行装置１００の動作例を説明する。
【００２６】
クライアント装置２００からのＨＴＴＰリクエストがＷｅｂアプリケーション実行装置１００に到達すると、入力受信部１０１がＨＴＴＰリクエストを受信する（Ｓ１０１）。
【００２７】
ＨＴＴＰリクエストを受信した入力受信部１０１は、ＨＴＴＰリクエストに含まれるＧＥＴパラメータ値やＰＯＳＴパラメータ値、ヘッダ値、Ｃｏｏｋｉｅ値を入力データとして抽出し、入力記憶部１０２に記憶する（Ｓ１０２）。
この際に、入力データについて、まったく同じ文字列となるものは１つの入力データとして記憶する。
また、ＧＥＴパラメータについては、各パラメータ値のＵＲＬエンコーディングをデコードしたものを入力データとして記憶する。
入力データの記憶時には、対策設定ファイル１０８の内容に基づいて、特定のデータが変換された場合の文字列も入力データとして追加する（例えば、テキストエリアに記載された文字列の改行コードを＜ＢＲ＞などに変換する）。
入力受信部１０１により抽出され、入力記憶部１０２に記録された入力データは、例えば図４のようになる。
なお、図４の表の１行目は説明のために便宜上つけており実際には必要ない。
【００２８】
次に、入力受信部１０１は、受信したＨＴＴＰリクエストをそのままＷｅｂアプリケーション１０３に渡す（Ｓ１０３）。
ＨＴＴＰリクエストをＷｅｂアプリケーション１０３に渡した後には、Ｗｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３から応答が出力されるのを待つ（Ｓ１０４）。
【００２９】
Ｗｅｂアプリケーション１０３は、受け取ったＨＴＴＰリクエストの処理を行い、その結果をＨＴＴＰレスポンスとして出力する。
出力したＨＴＴＰレスポンスは、出力検査部１０４に渡る。
出力検査部１０４は、Ｗｅｂアプリケーション１０３から受け取ったＨＴＴＰレスポンスのボディがＨＴＭＬ文書であるかを調べる（Ｓ１０５）。
レスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダが「ｔｅｘｔ／ｈｔｍｌ」または指定なしの場合には、ＨＴＴＰレスポンスのボディにＨＴＭＬ文書が含まれていると判定する。
ＨＴＭＬ文書が含まれていると判定した場合には、ステップＳ１０６に進む。
含まれていないと判定した場合には、ステップＳ１１１に進む。
【００３０】
ＨＴＴＰレスポンスのボディがＨＴＭＬ文書であると判定した場合には、出力検査部１０４は、ＨＴＴＰレスポンスのＨＴＭＬ文書に入力記憶部１０２に記憶されている各入力データと同じ文字列のデータが含まれるかを、文字列比較によって検査する。
検査の結果、ＨＴＭＬ文書中に入力データと同じ文字列のデータが含まれていた場合には、入力データ一致情報記憶部１０７に一致情報として、入力データと一致したデータ、一致が開始するのがＨＴＭＬ文書の何文字目か（以後、開始位置とよぶ）、および一致が終了するのがＨＴＭＬ文書の何文字目か（以後、終了位置とよぶ）を記憶する（Ｓ１０６）。
例えば、図４に示したデータが入力記憶部１０２に記録され、図５のようなＨＴＭＬ文書がＨＴＴＰレスポンスとして出力された場合には、入力データ一致情報記憶部１０７の記録は図６のようになる。
なお、図６の表の１列目と１行目は説明のため便宜上つけており実際には必要ない。
すべての入力データに対する比較が完了した時点で、入力データ一致情報記憶部１０７に情報を記憶した場合には、ステップＳ１０８に進む。
入力データ一致情報記憶部１０７に情報を記録していない場合、すなわち、入力データと同じ文字列のデータを抽出しなかった場合は、ステップＳ１１１に進む（Ｓ１０７）。
入力データ一致情報記憶部１０７に情報を記録した場合、すなわち、入力データと同じ文字列のデータを抽出した場合は、出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した文字列が連続している箇所を検索し、その情報を入力データ一致情報記憶部１０７に追加する（Ｓ１０８）。
【００３１】
Ｓ１０８の処理詳細を図７で説明する。
【００３２】
まず、出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した一致情報を読込み、一致情報（無効化候補データ）の個数をＮとする（Ｓ２０１）。
一致情報（無効化候補データ）の個数が２つ以上の場合にはＳ２０３に進み、それ以外の場合には処理を終了する（Ｓ２０２）。
次に、一致情報（無効化候補データ）の個数が２つ以上の場合には、本処理の初期化処理として、ループ用の変数をｎ＝１、ｍ＝２とする（Ｓ２０３）。
そして、ｎ≦Ｎの場合にはＳ２０５に進み処理を継続し、それ以外の場合には処理を終了する（Ｓ２０４）。
ｍ≦Ｎの場合にはＳ２０６に進み、それ以外の場合にはＳ２１３に進む（Ｓ２０５）。
そして、ｎ番目とｍ番目の一致情報がＨＴＭＬ文書中でｎ、ｍの順で、連続しているかを判定するために、ｎ番目の一致情報の終了位置（ｎ）＋１とｍ番目の一致情報の終了位置ｓ（ｍ）が等しいことを調べ（Ｓ２０６〜２０７）、等しい場合にはｎ番目の一致情報の入力データとｍ番目の一致情報の入力データをｎ、ｍの順で連結し、入力データ一致情報記憶部１０７に追加する。
なお、追加した一致情報の開始位置は、ｎ番目の一致情報の開始位置、終了位置はｍ番目の一致情報の終了位置となり、ｎは１つ増加する（Ｓ２０８）。
同様にｎ番目とｍ番目の一致情報がｍ、ｎの順で連続しているかを調べ、連続している場合には、ｎ番目の一致情報の入力データとｍ番目の一致情報の入力データをｍ、ｎの順で連結し、同様に入力データ一致情報記憶部１０７に連続している情報を追加する（Ｓ２０９〜Ｓ２１１）。
この場合は、追加した一致情報の開始位置は、ｍ番目の一致情報の開始位置、終了位置はｎ番目の一致情報の終了位置となり、ｎは１つ増加する。
以上の一致情報のｎ番目とｍ番目の一致情報に関する処理が完了したら、ｍを１増分しＳ２０５に戻る（Ｓ２１２）。
また、Ｓ２１３では、ｍがＮより大きい場合には、ｎを増分しｍをｎ＋１にする。
以上の処理を繰返すことで、入力データが連続している箇所を見つけることができる。
【００３３】
なお、Ｓ２０６〜Ｓ２０８でｎ番目とｍ番目の入力データがｎ、ｍの順で連続しているかを調べ、ｎ番目の入力データとｍ番目の入力データをｎ、ｍの順で連結することで、スクリプトコードが分割されている（ｎ番目の入力データとｍ番目の入力データが離間している場合も含む）ＨＴＴＰリクエストが送信された場合にも、有効にスクリプトコードを抽出することができる。
【００３４】
また、Ｓ２０９〜Ｓ２１１でｎ番目とｍ番目の入力データがｍ、ｎの順で連続しているかを調べ、ｎ番目の入力データとｍ番目の入力データをｍ、ｎの順で連結することで、ＨＴＴＰリクエストではｎ番目の入力データが前の位置に配置されｍ番目の入力データが後の位置に配置されていた（ｎ番目の入力データとｍ番目の入力データが離間している場合も含む）ものが、Ｗｅｂアプリケーション１０３によってＨＴＴＰリクエストでの順序とは逆に入力データが配置され、ＨＴＴＰレスポンスではｍ番目の入力データに続いてｎ番目の入力データが配置されるような場合にも、有効にスクリプトコードを抽出することができる。
【００３５】
再び図３に戻りＳ１０９から説明する。
出力検査部１０４は、入力データ一致情報記憶部１０７に記憶した一致情報のうち２つの条件に合致するものを削除する（Ｓ１０９）。
１つ目の条件とは、他の一致情報に包含される一致情報である。
この条件は、各一致情報の開始位置と終了位置を比較することで判定できる。
例えば、ｎ番目の一致情報の開始位置をｓ（ｎ）、終了位置をｅ（ｎ）とする。
この場合に、ｎ番目の一致情報とｍ番目の一致情報を比較し、ｓ（ｎ）≦ｓ（ｍ）かつｅ（ｎ）≧ｅ（ｍ）が成立する時には、ｍ番目の一致情報はｎ番目の一致情報に含まれる。
この条件が成立する場合に、出力検査部１０４は、入力データ一致情報記憶部１０７からｍ番目の一致情報を削除する。
そして、２つ目の条件は、対策設定ファイル１０８で記載に記載された入力データと判定する最低文字数よりも短い一致情報である。
これは、入力データとみなせる文字列が短いため、攻撃データとしては成立しない入力データを削除するために行う。
これらを行った後に、出力検査部１０４は、出力構文解析部１０５にＷｅｂアプリケーションから受け取ったＨＴＴＰレスポンスを渡す。
例えば、図４に示したデータが入力記憶部１０２に記録され、図５のようなＨＴＭＬ文書が出力された場合には、入力データ一致情報記憶部１０７の記録は最終的には図８のようになる。
図８では、図６の３行目の入力データと４行目の入力データが連結されて、図８の４行目の連結データになっている。
なお、図６の３行目の入力データと４行目の入力データは、図８の４行目の連結データに包含されるので、削除されている。
また、図８の表の１列目と１行目は説明のため便宜上つけており実際には必要ない。
【００３６】
次に、出力構文解析部１０５は、出力検査部１０４から受け取ったＨＴＴＰレスポンスのＨＴＭＬ文書の構文を解析し、入力データがＨＴＭＬ構文中の何処に位置するのを特定し、その特定結果によりＸＳＳ対策を行う（Ｓ１１０）。
なお、ＨＴＭＬの構文の定義は非特許文献１で開示されており、この定義に従ってＨＴＭＬ文書の先頭から調べることで、構文解析を行っていく。
詳細は割愛するが、ＨＴＭＬ文書は、プレーンテキストを要素で括って文書をマークアップすることで、文書に構造や意味などを与えるものであり、要素内に要素を入れることが可能であり、構造的に文書を表すことができる。
要素は開始タグ、コンテンツ、終了タグの３つで構成される。
開始タグは、要素名を「＜」と「＞」で囲んだ形式であり、終了タグは要素名を「＜／」と［＞］で囲んだものになる。
また、必要に応じて、要素に属性と呼ばれる特性を付加してもよく、開始タグの内部に、要素名に続けて属性名＝属性値という形で記述する。
なお、内容を含まない要素については、終了タグをもたないものもある（例えば、改行を表す＜ＢＲ＞や入力フォームを表す＜ＩＮＰＵＴ＞など）。
なお、要素名と属性名については大文字と小文字を区別せず、属性値については、属性によって大文字と小文字を区別するかどうかが個別に定められる。
【００３７】
Ｓ１１０での出力構文解析部１０５の処理内容について、図９を使って説明する。
【００３８】
出力構文解析部１０５は、ＨＴＭＬ文書を読み出し、開始タグおよび終了タグとなる文字列パターンを、ＨＴＭＬ文書の先頭から抽出しながら（Ｓ３０１）、タグの文字列・開始位置・終了位置からなる一覧を作成する。
なお、タグの抽出は、正規表現「＜［ａ−ｚＡ−Ｚ／！］［＾＞］＊」などを使ってＨＴＭＬ文書を文字列検索すれば可能である。
なお、＜ＢＲ＞などの終了タグがなく属性もない要素については、抽出結果から除外する。
【００３９】
次に出力構文解析部１０５は、一覧抽出したタグを上から順に解析し、タグの要素名に基づき開始タグと終了タグの関係を解析して、ＨＴＭＬ文書の階層構造を調べる（Ｓ３０２）。
また、各要素が位置するタグ階層上の深さ（以後、レベルと呼ぶ）を算出する。
例えば、図１０のようなＨＴＭＬ文書の場合には、ＨＴＭＬ要素のレベルは０とし、ＢＯＤＹ要素はレベル１、ＤＩＶ要素とＦＯＲＭ要素はレベル２、ＩＮＰＵＴ要素はレベル３とする。
なお、前述したとおりＨＴＭＬに終了タグがない要素や省略できる要素があり、前述した非特許文献１で規定される定義に基づいて調査する。
【００４０】
次に、出力構文解析部１０５は、抽出した開始タグと終了タグの情報をまとめて、レベル、要素名、開始タグの内容、開始タグの開始位置、開始タグの終了位置、終了タグの開始位置、終了タグの終了位置を含む情報を作成する（Ｓ３０３）。
【００４１】
次に、出力構文解析部１０５は、開始タグの内容を要素名、属性名、属性値に分解する。
そして、要素名、属性名、属性値の開始位置、終了位置をそれぞれ算出する（Ｓ３０４）。
なお、属性値は「”」「’」などのクォートも含めたものとする。
そして、これらのＨＴＭＬの構造に関する情報をまとめたＨＴＭＬ構造情報をメモリ上に保持する。
このＨＴＭＬ構造情報は、各エントリが、要素か属性を示す種別（以後、種別とする）、要素または属性の名称、レベル（属性の場合には、その属性が含まれる要素のレベルと同じになる）を含み、さらに要素のエントリの場合には、開始タグの開始位置・終了位置、終了タグの開始位置・終了位置を含む。
属性のエントリの場合には、属性名の開始位置・終了位置、属性値の開始位置、属性値の終了位置を含む。
例えば、ＨＴＭＬ構文情報のイメージは図１１のようになる。
種別の欄の「Ｅ」は要素、「Ａ」は属性、「Ｖ」は属性値であることを示している。
なお、図１１の表の一行目は説明の便宜上のために記載したものであり、実際には必要がない。
また、要素名、属性名についてレベルに応じてインデントしているが、実際には必要がない。
ここまで解析した段階で、入力データ一致情報記憶部１０７の情報および、出力構文解析部１０５で解析したＨＴＭＬ文書の構文情報を使って、ＨＴＭＬ文書に含まれる入力データが、ＨＴＭＬ構文中の何処の領域に含まれるかを特定していく。
【００４２】
出力構文解析部１０５は、入力データ一致情報記憶部１０７に記憶する各データの開始位置、終了位置の情報と、ＨＴＭＬ構文情報の開始位置／終了位置を比較して、各入力データが、開始タグ、終了タグ、要素内、属性値内、属性値内、それら以外（コンテンツ内と呼ぶ）のいずれかの領域に含まれるか、複数の領域に跨るかを判別する（Ｓ３０５）。
【００４３】
以上の手順で特定した入力データが位置する領域に基づき、出力構文解析部１０５は、出力送信部１０６に渡す前に、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書に対して、ＸＳＳ対策を行う（Ｓ３０６）。
各領域でのＸＳＳ対策は、対策設定ファイル１０８で指定されている。
例えば、入力データが属性値やコンテンツに出力されている場合には以下のように対策を行う。
【００４４】
入力データが属性値の場合
ｈｒｅｆとｓｒｃ：入力データがｈｔｔｐ：／／、ｈｔｔｐｓ：／／で始まる場合にのみＵＲＬのみに限定し、出力する場合も、クエリストリングにあたる箇所はＵＲＬエンコーディングする。
ｓｔｙｌｅ：英数字以外は￥ｘＨＨ；形式でエンコードする。
イベントハンドラ：ｓｔｙｌｅの場合と同様
上記以外：入力データをエンティティ表現へ変換する。
【００４５】
入力データがコンテンツ内の場合
ＨＴＭＬ構文情報を確認して、上のレベルにＳＣＲＩＰＴ要素がないかを調べる。
ＳＣＲＩＰＴ要素が上のレベルに存在する場合には、該当する入力データをすべて半角スペースに置換する。
また、上のレベルにＳＣＲＩＰＴ要素が存在しない場合には、該当する入力データをすべてエンティティ表現でエスケープする。
【００４６】
最後に、出力送信部１０６が、出力構文解析部１０５または出力検査部１０４から受け取ったＨＴＴＰレスポンスをクライアント装置２００に送信し、入力記憶部１０２に記憶した入力データをすべてクリアする（ステップＳ１１１）。
【００４７】
以上のように、クライアント装置からＷｅｂアプリケーションへのＨＴＴＰリクエストに含まれる入力データをすべて一旦記憶しておくことで、Ｗｅｂアプリケーションから出力されたＨＴＭＬ文書に入力データが含まれているかを調べることができる。
さらに、出力するＨＴＴＰレスポンスを構文解析してスクリプトコードを抽出し、スクリプトコードの１ステートメント以上に入力データが含まれるかを調べることで、Ｗｅｂアプリケーション内部で出力した文字列が入力データと一致した場合においても、誤って脆弱性対策を施すことを省くことができる。
さらに、入力データが連続する箇所を１つの入力データとして扱うことで、攻撃データが別の入力データとして分割されて、出力時に連結して攻撃データとなる場合についても、攻撃データであることを検知することができる。
【００４８】
本実施の形態では、レスポンスデータにＨＴＭＬ文書が含まれるか否かをレスポンスのＣｏｎｔｅｎｔ−Ｔｙｐｅヘッダを確認することで行っている。
ただし、ブラウザによってはＣｏｎｔｅｎｔ−Ｔｙｐｅにｉｍａｇｅ／ｇｉｆなどの画像データが指定された場合にでも、データ自体がＨＴＭＬであるとブラウザが判定すると、ＨＴＭＬ文書として表示するブラウザもある。
このため、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダで判定を行わずに、その後のＨＴＭＬ構文解析処理の段階で、ＨＴＭＬか否かを判定しても良い。
【００４９】
本実施の形態では、事前に定められたＸＳＳの対策処理を施したが、ＸＳＳの対策処理の方法をファイルなどで設定し、その設定情報を読込むことで、脆弱性対策の方法を変更することも可能である。
【００５０】
以上、本実施の形態では、
Ｗｅｂアプリケーションで利用するデータについて外部から入力されたデータを記憶し、Ｗｅｂアプリケーションから外部にデータを出力する際に、出力データ中に外部から入力されたデータが含まれている場所を特定し、その場所のデータ構造に応じて、攻撃に対策方法を変更するＷｅｂアプリケーション実行装置を説明した。
【００５１】
また、本実施の形態では、
ＨＴＭＬを構文解析し、ＨＴＭＬ文中に上記パターンが出力される場所を特定し、出力場所に応じて取り除くべき文字を特定するＷｅｂアプリケーション実行装置を説明した。
【００５２】
実施の形態２．
以上の実施の形態１では、ＨＴＴＰリクエストに攻撃データが含まれていた場合に、そのレスポンスに攻撃データが含まれていることを検知するものであるが、次に、ＨＴＴＰリクエストからの攻撃データが一旦データベースなどに保存され、別のリクエストに対するレスポンスに攻撃データが現れる場合（蓄積型ＸＳＳ）に脆弱性対策を行うための実施の形態を示す。
【００５３】
図１２は、この実施の形態に係るＷｅｂアプリケーション実行装置１００の構成図である。
図２において、Ｗｅｂアプリケーション実行装置１００は、実施の形態１の構成要素に加えて、データベース１０９、ＤＢ監視部１１０、ＤＢ監視設定ファイル１１１、外部データ識別ファイル１１２が加わっている。
【００５４】
データベース１０９は、Ｗｅｂアプリケーション１０３が利用するデータベースである。
【００５５】
ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３がデータベース１０９へアクセスする際のＳＱＬ文を監視し、データベース１０９への書込みと読込みを判定する。
Ｗｅｂアプリケーション１０３が、入力記憶部１０２に記録されている入力データ（埋め込み先候補データ）をデータベース１０９に書き込んだ場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３が入力データを書き込んだテーブル名／カラム名を外部データ識別ファイル１１２に記録する。
また、Ｗｅｂアプリケーション１０３が、外部データ識別ファイル１１２に記載されているテーブル名／カラム名のデータをデータベース１０９から読込んだ場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３がデータベース１０９から読込んだデータを入力記憶部１０２に追加する。
ＤＢ監視部１１０は、書き込みアクセス監視部及び読み出しアクセス監視部の例である。
なお、書込み／読込みを判別するための設定情報は、ＤＢ監視設定ファイル１１１に記述されている。
【００５６】
ＤＢ監視設定ファイル１１１は、ＤＢ監視部１１０がＳＱＬ文を監視することで、データベース１０９への書込みや読込みを判定するための設定情報が記載されたファイルである。
例えば、ＵＰＤＡＴＥ文が発行された場合には、書込みと判断し、ＳＥＬＥＣＴ文などが発行された場合には読込みと判定するための設定が含まれている。
【００５７】
外部データ識別ファイル１１２は、Ｗｅｂアプリケーション１０３がデータベース１０９へ外部データ（入力記憶部１０２に記録されている入力データ）を書き込んだとＤＢ監視部１１０が判定した場合に、外部データを書込んだテーブル名とカラム名を記録するためのファイルである。
外部データ識別ファイル１１２に記録される、外部データを書込んだテーブル名とカラム名の情報は、書き込み情報の例である。
【００５８】
次に図１３を使ってデータベース１０９に外部データが書き込まれる場合の動作を説明する。
【００５９】
クライアント装置２００からのＨＴＴＰリクエストがＷｅｂアプリケーション実行装置１００に到達すると、実施の形態１のＳ１０１〜Ｓ１０４と同様に、入力受信部１０１でＨＴＴＰリクエストを受信し、ＨＴＴＰリクエストの入力データを抽出して、入力記憶部１０２に記憶する。
そして、Ｗｅｂアプリケーション１０３にＨＴＴＰリクエストを渡す。
その後、Ｗｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３からの応答を待機する（Ｓ４０１〜Ｓ４０４）。
【００６０】
その後、Ｗｅｂアプリケーション１０３がデータベース１０９にアクセスする（Ｓ４０５）。
ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３からデータベース１０９に送信されるＳＱＬ文を分析し、ＤＢ監視設定ファイル１１１の設定内容に従って、データベース１０９への書込み処理か、読込み処理かを判別する（Ｓ４０６）。
例えば、ＵＰＤＡＴＥ文が発行された場合は書込み、ＳＥＬＥＣＴ文が発行された場合は読込みと判定する。
書込み処理と判定した場合にはＳ４０７に進み、読込み処理と判定した場合にはＳ４０９に進む。
【００６１】
書込み処理と判定した場合には、ＤＢ監視部１１０は、文字列比較によりデータベース１０９へのＳＱＬ文に、入力記憶部１０２に記憶されている入力データと同じものがあるか否か、すなわち、入力データのデータベース１０９への書き込みが行われているか否かを判断し（Ｓ４０７）、入力データの書き込みが行われている場合には、Ｓ４０８に進み、入力データ以外のデータの書き込みが行われている場合はＳ４１２に進む。
【００６２】
入力記憶部１０２に記憶されている入力データがデータベース１０９に書込まれているとＤＢ監視部１１０が判定したら、ＤＢ監視部１１０はＳＱＬ文から入力データを書込むテーブル名、カラム名及び値を抽出し、抽出したテーブル名、カラム名及び値を書き込み情報として外部データ識別ファイル１１２に書込む（Ｓ４０８）。
例えば、以下のＳＱＬ文の場合、ｕｓｅｒＴａｂｌｅをテーブル名、ｎａｍｅ１をカラム名と、Ｔａｎａｋａを値と判断する。
ＵＰＤＡＴＡＥ ｕｓｅｒｔＴａｂｌｅ ＳＥＴ ｎａｍｅ１ ＝ “Ｔａｎａｋａ”；
なお、既に同じテーブル名とカラム名が書込み済みである場合には、テーブル名／カラム名は外部データ識別ファイル１１２に書込む必要がなく、同じテーブル名／カラム名のエントリに値のみを追加する。
また、既に同じテーブル名、カラム名、値が書込み済みである場合には、外部データ識別ファイル１１２に書込む必要がない。
また、データベースアクセスがエラーとなった場合にも、テーブル名／カラム名の情報を書き込む必要はない。
この処理が完了したらＳ４１２に進む。
【００６３】
一方、Ｓ４０６において、Ｗｅｂアプリケーション１０３がデータベース１０９からデータを読込んでいるとＤＢ監視部１１０が判定したら、ＳＱＬ文からデータを読込むテーブル名とカラム名を抽出し、外部データ識別ファイル１１２にそれらテーブル名／カラム名の記載がないかを調べる（Ｓ４０９）。
例えば、以下のＳＱＬ文の場合、テーブル名ｕｓｅｒＴａｂｌｅからカラム名ｎａｍｅ１を読込んでいる。
ＳＥＬＥＣＴ ｎａｍｅ１ ＦＲＯＭ ｕｓｅｒｔＴａｂｌｅ；
外部データ識別ファイル１１２に記載があるテーブル名／カラム名からデータを読込んだと判定した場合には、Ｓ４１０に進み、異なるテーブル名／カラム名からデータを読込んだと判定した場合にはＳ４１２に進む。
【００６４】
Ｗｅｂアプリケーション１０３が外部データ識別ファイル１１２に記載があるテーブル名／カラム名からデータを読込んだ場合には、ＤＢ監視部１１０は、外部データ識別ファイル１１２のテーブル名／カラム名のエントリに記載された値と同じデータが読込みのＳＱＬ文のレスポンスに含まれていないかを調べる（Ｓ４１０）。
つまり、Ｗｅｂアプリケーション１０３により読み出されたデータが外部データ識別ファイル１１２に記述されている入力データと一致するか否かを判断する。
データがＳＱＬ文のレスポンスに含まれている場合にはＳ４１１に進み、含まれていない場合にはＳ４１２に進む。
【００６５】
ＳＱＬ文のレスポンスに外部データ識別ファイル１１２に記載の値と同じデータが含まれている場合には、ＤＢ監視部１１０は、Ｗｅｂアプリケーション１０３が読込んだデータを入力記憶部１０２に追加する（Ｓ４１１）。
なお、ＤＢ監視部１１０が入力記憶部１０２に追加したデータの情報は、読み出し情報に相当する。
【００６６】
Ｓ４１２では、実施の形態１の図３記載のＳ１０５〜Ｓ１１１と同じ処理を行う。
つまり、出力検査部１０４は、ＨＴＴＰレスポンス内のＨＴＭＬ文書に対して、入力受信部１０１がＨＴＴＰリクエストから抽出し入力記憶部１０２に記録した入力データと一致するデータを検索するとともに、ＤＢ監視部１１０が入力記憶部１０２に記録したデータ（Ｗｅｂアプリケーション１０３がデータベース１０９から読み込んだデータ）と一致するデータも検索する。
【００６７】
以上のように、本実施の形態では、Ｗｅｂアプリケーションによるデータベースへの書き込みを監視して、データベースへの外部入力データの書き込みを監視することで、攻撃データをＨＴＴＰリクエストで送信し、一旦データベース等に蓄積された後に、別のＨＴＴＰリクエストでその蓄積された攻撃データを読込んでＨＴＭＬに出力することで発生する蓄積型ＸＳＳを防ぐことができる。
【００６８】
以上、本実施の形態では、
Ｗｅｂアプリケーションで利用するデータが、外部入力のデータであることを記憶し、入力データを利用する各処理の実行時に、処理内容に応じて、適切なサニタイズ処理を動的に選択するＷｅｂアプリケーション実行装置を説明した。
【００６９】
また、本実施の形態では、
Ｗｅｂアプリケーションに外部入力がＤＢへの書込まれるＤＢのテーブル名とカラム名と値を記憶しておき、当該テーブル／カラムから読込まれたデータから書込んだ値と同じ値が含まれている場合には、外部入力データとみなして脆弱性の検査対象に加えるＷｅｂアプリケーション実行装置を説明した。
【００７０】
なお、実施の形態１及び２に係るＷｅｂアプリケーション実行装置１００は、Ｗｅｂアプリケーション１０３を実行するサーバ機能と、ＨＴＴＰリクエストから入力データを抽出し、ＨＴＴＰレスポンスに入力データと一致するデータが含まれているかを検査するフィルタ機能の双方を有することになっている。
実施の形態１及び２に示した構成の他に、Ｗｅｂアプリケーション１０３を実行する装置をサーバ装置とし、フィルタ処理を実行する装置をデータ処理装置として分離し、データ処理装置をクライアント装置２００とサーバ装置の間に介在させる構成としてもよい。
この場合は、データ処理装置は、実施の形態１の構成では、例えば、入力受信部１０１、入力記憶部１０２、出力検査部１０４、出力構文解析部１０５、出力送信部１０６で構成される。
また、実施の形態２の構成では、例えば、入力受信部１０１、入力記憶部１０２、出力検査部１０４、出力構文解析部１０５、出力送信部１０６、ＤＢ監視部１１０、ＤＢ監視設定ファイル１１１、外部データ識別ファイル１１２で構成される。
【００７１】
最後に、実施の形態１及び２に示したＷｅｂアプリケーション実行装置１００のハードウェア構成例について説明する。
図１４は、実施の形態１及び２に示すＷｅｂアプリケーション実行装置１００のハードウェア資源の一例を示す図である。
なお、図１４の構成は、あくまでもＷｅｂアプリケーション実行装置１００のハードウェア構成の一例を示すものであり、Ｗｅｂアプリケーション実行装置１００のハードウェア構成は図１４に記載の構成に限らず、他の構成であってもよい。
【００７２】
図１４において、Ｗｅｂアプリケーション実行装置１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１及び２で説明した「入力記憶部１０２」、「入力データ一致情報記憶部１０７」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
また、実施の形態２で説明した「データベース１０９」は、例えば、磁気ディスク装置９２０により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００７３】
通信ボード９１５は、図１に示すように、ネットワークに接続されている。
通信ボード９１５は、インターネットの他、例えば、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。
【００７４】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００７５】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００７６】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
Ｗｅｂアプリケーション実行装置１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００７７】
上記プログラム群９２３には、実施の形態１及び２の説明において「〜部」（「入力記憶部１０２」、「入力データ一致情報記憶部１０７」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００７８】
ファイル群９２４には、実施の形態１及び２の説明において、「〜の判断」、「〜の判定」、「〜の解析」、「〜の比較」、「〜の検索」、「〜の抽出」、「〜の追加」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の監視」、「〜の生成」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１及び２で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００７９】
また、実施の形態１及び２の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１及び２で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「データ処理方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１及び２の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１及び２の「〜部」の手順や方法をコンピュータに実行させるものである。
【００８０】
このように、実施の形態１及び２に示すＷｅｂアプリケーション実行装置１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００８１】
１００ Ｗｅｂアプリケーション実行装置、１０１ 入力受信部、１０２ 入力記憶部、１０３ Ｗｅｂアプリケーション、１０４ 出力検査部、１０５ 出力構文解析部、１０６ 出力送信部、１０７ 入力データ一致情報記憶部、１０８ 対策設定ファイル、１０９ データベース、１１０ ＤＢ監視部、１１１ ＤＢ監視設定ファイル、１１２ 外部データ識別ファイル、２００ クライアント装置、３００ ネットワーク。
【特許請求の範囲】
【請求項１】
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力部と、
前記リクエスト入力部により入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出部と、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力部と、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出部と、
前記無効化候補データ抽出部により複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結部と、
前記データ連結部により連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化部とを有することを特徴とするデータ処理装置。
【請求項２】
前記データ連結部は、
無効化候補データの間の前後関係が、前記リクエスト内での埋め込み先候補データの配置の順序と一致している２以上の無効化候補データを前記レスポンス内で検索するとともに、
無効化候補データの間の前後関係が、前記リクエスト内での埋め込み先候補データの配置の順序と逆になっている２以上の無効化候補データを前記レスポンス内で検索することを特徴とするデータ処理装置。
【請求項３】
前記レスポンス入力部は、
包含されている複数のデータが複数種類のカテゴリーのうちのいずれかに分類されるレスポンスを入力し、
前記コード無効化部は、
カテゴリーごとに特定種類のコードの無効化方式が定義されている無効化方式情報を管理しており、
前記データ連結部により連結された連結無効化候補データのカテゴリーを判断し、前記無効化方式情報に基づき、前記連結無効化候補データのカテゴリーに対応する無効化方式にて前記連結無効化候補データに含まれている特定種類のコードを無効化することを特徴とする請求項１又は２に記載のデータ処理装置。
【請求項４】
前記コード無効化部は、
前記連結無効化候補データに特定種類のコードが含まれているか否かを判断するとともに、連結されなかった無効化候補データに特定種類のコードが含まれているか否かを判断し、連結されなかった無効化候補データに特定種類のコードが含まれている場合に、連結されなかった無効化候補データに含まれている特定種類のコードを無効化することを特徴とする請求項１〜３のいずれかに記載のデータ処理装置。
【請求項５】
前記データ処理装置は、更に、
前記サーバ装置による所定のデータベースへのデータ書き込みアクセスを監視し、データ書き込みアクセスを検知した場合に、埋め込み先候補データの書き込みが行われているか否かを判断し、埋め込み先候補データの書き込みが行われている場合に、書き込み対象の埋め込み先候補データ及び埋め込み先候補データの書き込み先を特定する情報を書き込み情報として生成する書き込みアクセス監視部と、
前記サーバ装置による前記データベースへのデータ読み出しアクセスを監視し、データ読み込みアクセスを検知した場合に、読み出されたデータの読み出し元が前記書き込み情報に記述されている書き込み先と一致し、読み出されたデータが前記書き込み情報に記述されている埋め込み先候補データと一致するか否かを判断し、読み出されたデータの読み出し元が前記書き込み情報に記述されている書き込み先と一致し、読み出されたデータが前記書き込み情報に記述されている埋め込み先候補データと一致する場合に、当該埋め込み先候補データが示される情報を読み出し情報として生成する読み出しアクセス監視部とを有し、
前記無効化候補データ抽出部は、
前記リクエスト入力部によりリクエストが入力され、前記埋め込み先候補データ抽出部により埋め込み先候補データが抽出され、前記レスポンス入力部により前記リクエストに対するレスポンスが入力された後に、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、前記埋め込み先候補データ抽出部により抽出された埋め込み先候補データと値が一致するデータと、前記読み出し情報に示されている埋め込み先候補データと値が一致するデータを無効化候補データとして抽出することを特徴とする請求項１〜４のいずれかに記載のデータ処理装置。
【請求項６】
前記埋め込み先候補データ抽出部は、
前記リクエスト内の複数のデータのうち、スクリプトコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出し、
前記コード無効化部は、
前記データ連結部により連結された連結無効化候補データにスクリプトコードが含まれているか否かを判断し、前記連結無効化候補データにスクリプトコードが含まれている場合に、前記連結無効化候補データに含まれているスクリプトコードを無効化することを特徴とする請求項１〜５のいずれかに記載のデータ処理装置。
【請求項７】
コンピュータが、クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力ステップと、
前記コンピュータが、前記リクエスト入力ステップにより入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出ステップと、
前記コンピュータが、前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力ステップと、
前記コンピュータが、前記レスポンス入力ステップにより入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出ステップと、
前記コンピュータが、前記無効化候補データ抽出ステップにより複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結ステップと、
前記コンピュータが、前記データ連結ステップにより連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化ステップとを有することを特徴とするデータ処理方法。
【請求項８】
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力ステップと、
前記リクエスト入力ステップにより入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出ステップと、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力ステップと、
前記レスポンス入力ステップにより入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出ステップと、
前記無効化候補データ抽出ステップにより複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結ステップと、
前記データ連結ステップにより連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化ステップとをコンピュータに実行させることを特徴とするプログラム。
【請求項１】
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力部と、
前記リクエスト入力部により入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出部と、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力部と、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出部と、
前記無効化候補データ抽出部により複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結部と、
前記データ連結部により連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化部とを有することを特徴とするデータ処理装置。
【請求項２】
前記データ連結部は、
無効化候補データの間の前後関係が、前記リクエスト内での埋め込み先候補データの配置の順序と一致している２以上の無効化候補データを前記レスポンス内で検索するとともに、
無効化候補データの間の前後関係が、前記リクエスト内での埋め込み先候補データの配置の順序と逆になっている２以上の無効化候補データを前記レスポンス内で検索することを特徴とするデータ処理装置。
【請求項３】
前記レスポンス入力部は、
包含されている複数のデータが複数種類のカテゴリーのうちのいずれかに分類されるレスポンスを入力し、
前記コード無効化部は、
カテゴリーごとに特定種類のコードの無効化方式が定義されている無効化方式情報を管理しており、
前記データ連結部により連結された連結無効化候補データのカテゴリーを判断し、前記無効化方式情報に基づき、前記連結無効化候補データのカテゴリーに対応する無効化方式にて前記連結無効化候補データに含まれている特定種類のコードを無効化することを特徴とする請求項１又は２に記載のデータ処理装置。
【請求項４】
前記コード無効化部は、
前記連結無効化候補データに特定種類のコードが含まれているか否かを判断するとともに、連結されなかった無効化候補データに特定種類のコードが含まれているか否かを判断し、連結されなかった無効化候補データに特定種類のコードが含まれている場合に、連結されなかった無効化候補データに含まれている特定種類のコードを無効化することを特徴とする請求項１〜３のいずれかに記載のデータ処理装置。
【請求項５】
前記データ処理装置は、更に、
前記サーバ装置による所定のデータベースへのデータ書き込みアクセスを監視し、データ書き込みアクセスを検知した場合に、埋め込み先候補データの書き込みが行われているか否かを判断し、埋め込み先候補データの書き込みが行われている場合に、書き込み対象の埋め込み先候補データ及び埋め込み先候補データの書き込み先を特定する情報を書き込み情報として生成する書き込みアクセス監視部と、
前記サーバ装置による前記データベースへのデータ読み出しアクセスを監視し、データ読み込みアクセスを検知した場合に、読み出されたデータの読み出し元が前記書き込み情報に記述されている書き込み先と一致し、読み出されたデータが前記書き込み情報に記述されている埋め込み先候補データと一致するか否かを判断し、読み出されたデータの読み出し元が前記書き込み情報に記述されている書き込み先と一致し、読み出されたデータが前記書き込み情報に記述されている埋め込み先候補データと一致する場合に、当該埋め込み先候補データが示される情報を読み出し情報として生成する読み出しアクセス監視部とを有し、
前記無効化候補データ抽出部は、
前記リクエスト入力部によりリクエストが入力され、前記埋め込み先候補データ抽出部により埋め込み先候補データが抽出され、前記レスポンス入力部により前記リクエストに対するレスポンスが入力された後に、
前記レスポンス入力部により入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、前記埋め込み先候補データ抽出部により抽出された埋め込み先候補データと値が一致するデータと、前記読み出し情報に示されている埋め込み先候補データと値が一致するデータを無効化候補データとして抽出することを特徴とする請求項１〜４のいずれかに記載のデータ処理装置。
【請求項６】
前記埋め込み先候補データ抽出部は、
前記リクエスト内の複数のデータのうち、スクリプトコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出し、
前記コード無効化部は、
前記データ連結部により連結された連結無効化候補データにスクリプトコードが含まれているか否かを判断し、前記連結無効化候補データにスクリプトコードが含まれている場合に、前記連結無効化候補データに含まれているスクリプトコードを無効化することを特徴とする請求項１〜５のいずれかに記載のデータ処理装置。
【請求項７】
コンピュータが、クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力ステップと、
前記コンピュータが、前記リクエスト入力ステップにより入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出ステップと、
前記コンピュータが、前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力ステップと、
前記コンピュータが、前記レスポンス入力ステップにより入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出ステップと、
前記コンピュータが、前記無効化候補データ抽出ステップにより複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結ステップと、
前記コンピュータが、前記データ連結ステップにより連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化ステップとを有することを特徴とするデータ処理方法。
【請求項８】
クライアント装置からサーバ装置に対して送信された、複数のデータが包含されているリクエストを入力するリクエスト入力ステップと、
前記リクエスト入力ステップにより入力されたリクエストを解析し、前記リクエスト内の複数のデータのうち、特定種類のコードが埋め込まれている可能性のあるデータを埋め込み先候補データとして抽出する埋め込み先候補データ抽出ステップと、
前記リクエストに対する応答として生成された、複数のデータが包含されているレスポンスを入力するレスポンス入力ステップと、
前記レスポンス入力ステップにより入力されたレスポンスを解析し、前記レスポンス内の複数のデータのうち、埋め込み先候補データと値が一致するデータを無効化候補データとして抽出する無効化候補データ抽出ステップと、
前記無効化候補データ抽出ステップにより複数の無効化候補データが抽出された場合に、前記レスポンス内で連続した位置に配置されている２以上の無効化候補データを検索し、検索の結果抽出された２以上の無効化候補データを連結するデータ連結ステップと、
前記データ連結ステップにより連結された連結無効化候補データに前記特定種類のコードが含まれているか否かを判断し、前記連結無効化候補データに前記特定種類のコードが含まれている場合に、前記連結無効化候補データに含まれている前記特定種類のコードを無効化するコード無効化ステップとをコンピュータに実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−１７４１３８（Ｐ２０１２−１７４１３８Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３７５３１（Ｐ２０１１−３７５３１）
【出願日】平成２３年２月２３日（２０１１．２．２３）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月２３日（２０１１．２．２３）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]