(57)【特許請求の範囲】
【請求項１】
ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための方法であって、
クライアントにおいて展開される前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、前記提供したセキュリティ・ルール・サブセットに基づいて前記前検証コンポーネントによって前記クライアント側でユーザ入力のセキュリティ検証を可能とするステップと、
前記保護手段のセキュリティ・ルールに基づいて前記ユーザ入力を検証するステップと、
違反ユーザ入力、および、違反のあったセキュリティ・ルールが前記前検証コンポーネントに提供されていないことの検出に応答して、前記ユーザを第１のクラスのユーザの一人と判定するステップと、
違反ユーザ入力、および、違反のあったセキュリティ・ルールが前記前検証コンポーネントに提供されていることの検出に応答して、前記ユーザを第２のクラスのユーザの一人と判定するステップと、
前記判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行するステップと、
を含み、前記判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行する前記ステップが、
前記第２のクラスのユーザに対して、全ての以降の要求を強制的にブロックするセキュリティ保護アクションを実行するステップと、
前記第１のクラスのユーザに対して、前記ネットワーク・アプリケーションに対するアクセスを維持するセキュリティ保護アクションを実行するステップと、
を含む、方法。
【請求項２】
前記前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行するステップを更に含み、
セキュリティ・ルール・サブセットが、前記サーバ側保護手段のセキュリティ・ルールの前記セキュリティ・ルール・サブセットを前記前検証コンポーネントに提供する前記ステップにおいて、および、前記前検証コンポーネントに提供された前記セキュリティ・ルール・サブセットに動的な更新を非同期で実行する前記ステップにおいて、前記保護手段のセキュリティ・ルール・セットからスクリーニングされる、請求項１に記載の方法。
【請求項３】
ポリシーが、
高い違反率を有するセキュリティ・ルールを選択することと、
前記セキュリティ・ルール・セットにおいて全てのネガティブ・ルールを除外することと、
前記セキュリティ・ルール・セットにおいて高リスクのセキュリティ・ルールを除外することと、
の１つ以上を含む、請求項２に記載の方法。
【請求項４】
入力フィールドにおいてｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントを検出するステップを更に含み、前記前検証コンポーネントが、提供されたセキュリティ・ルール・サブセットに基づいて前記クライアント側でユーザ入力を検証する、請求項３に記載の方法。
【請求項５】
ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための装置であって、
クライアントにおいて展開される前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、前記提供したセキュリティ・ルール・サブセットに基づいて前記前検証コンポーネントによって前記クライアント側でユーザ入力のセキュリティ検証を可能とする手段と、
前記保護手段のセキュリティ・ルールに基づいて前記ユーザ入力を検証する手段と、
違反ユーザ入力、および、違反のあったセキュリティ・ルールが前記前検証コンポーネントに提供されていないことの検出に応答して、前記ユーザを第１のクラスのユーザの一人と判定する手段と、
違反ユーザ入力、および、違反のあったセキュリティ・ルールが前記前検証コンポーネントに提供されていることの検出に応答して、前記ユーザを第２のクラスのユーザの一人と判定する手段と、
前記判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行する手段と、
を含み、前記判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行する前記手段が、
前記第２のクラスのユーザに対して、全ての以降の要求を強制的にブロックするセキュリティ保護アクションを実行する手段と、
前記第１のクラスのユーザに対して、前記ネットワーク・アプリケーションに対するアクセスを維持するセキュリティ保護アクションを実行手段と、
を含む、装置。
【請求項６】
前記前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行する手段を更に含み、
クライアントにおいて前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、前記提供したセキュリティ・ルール・サブセットに基づいて前記前検証コンポーネントによって前記クライアント側でユーザ入力のセキュリティ検証を可能とする前記手段、および、前記前検証コンポーネントに提供された前記セキュリティ・ルール・サブセットに動的な更新を非同期で実行する前記手段が、ポリシーに従って前記保護手段のセキュリティ・ルール・セットから前記セキュリティ・ルール・サブセットをスクリーニングする、請求項５に記載の装置。
【請求項７】
ポリシーが、
高い違反率を有するセキュリティ・ルールを選択することと、
前記セキュリティ・ルール・セットにおいて全てのネガティブ・ルールを除外することと、
前記セキュリティ・ルール・セットにおいて高リスクのセキュリティ・ルールを除外することと、
の１つ以上を含む、請求項５又は６に記載の装置。
【請求項８】
入力フィールドにおいてｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントを検出することを更に含み、前記前検証コンポーネントが前記提供されたセキュリティ・ルール・サブセットに基づいて前記クライアント側でユーザ入力のセキュリティを検証する、請求項７に記載の装置。
【請求項９】
コンピュータ・システムにロードされて実行された場合に前記コンピュータ・システムに請求項１から４のいずれか１項に記載の方法の全てのステップを実行させるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・セキュリティのためのソリューションに関し、更に具体的には、ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための方法および装置に関する。
【背景技術】
【０００２】
今日、ウェブ・アプリケーションにおけるセキュリティの脆弱性は急速に増している。ネットワーク・アプリケーションは、ＸＳＳ（Ｃｒｏｓｓ−Ｓｉｔｅ  Ｓｃｒｉｐｔｉｎｇ：クロス・サイト・スクリプティング）、ＳＱＬインジェクション、ＬＤＡＰインジェクション、コマンド・アクセス、ＰＨＰインジェクション等を含む攻撃を受けやすい。統計によると、攻撃の７５％はアプリケーション・レイヤをねらったものであり、サイトの９０％はネットワーク・アプリケーション攻撃に対して弱いことが示されている。
【０００３】
ウェブ・アプリケーション・セキュリティのための従来のソリューションの中で、一方ではクライアント側でウェブ・アプリケーション・レビュー・ツール・チェック・コードが用いられ、他方ではウェブ・アプリケーション・サーバ側でウェブ・アプリケーション・ファイアウォールが用いられて、悪質な入力をフィルタリングしブロックする。悪質なユーザはクライアント側のウェブ・アプリケーション・ビュー・ツールを迂回して直接ウェブ・アプリケーション・サーバに悪質なコードまたはスクリプトをインジェクト（注入）し得るので、ウェブ・アプリケーション・サーバ側でユーザの入力を更に検証することが極めて必要である。
【０００４】
ウェブ・アプリケーション・サーバ側に適用されるトランスペアレントな保護機構であるウェブ・アプリケーション・ファイアウォールは、少なくとも以下の機能を有するように構成されている。すなわち、既定のセキュリティ・ルールに基づいてユーザの入力を検証すること、セキュリティ・ルールに違反したユーザの入力に対して適切なセキュリティ保護アクションをとることであり、これは例えばＩＰのブロック、要求の拒絶、ログの発生、またはペイロードの書き換え等を含む。
【０００５】
オンライン・ウェブ・アプリケーションを観察することによって、サーバ側の保護手段により検出されるセキュリティ・ルール違反は、以下の２つの環境から誘発される場合があることがわかっている。
【０００６】
１．悪意のないユーザが、セキュリティ・ルールに違反する何らかの値の入力でミスをする。
２．悪質なユーザが、クライアント側のユーザ入力検証機構を迂回し、何らかのツールを用いることによってウェブ・アプリケーション・サーバに悪質な入力をインジェクトする。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、ユーザ入力検証のための既存のソリューションは、悪意のないユーザおよび悪質なユーザを効果的に識別することができず、保護手段が適切かつ妥当なセキュリティ保護アクションをとることはほとんど不可能である。例えば、単に入力でミスをした悪意のないユーザに対して、ＩＰのブロックまたは要求の拒絶のようなアクションをとった場合、ウェブ・アプリケーションのこれらのユーザの経験に対して重大な影響を及ぼす。また、悪質なユーザまたは悪意のないユーザにかかわらず、ユーザからの要求が違反の間に拒絶され、ユーザ・フレンドリな方法でセキュリティ・ヒントが与えられた場合には、セキュリティ検証システムの性能の消費が著しく増大する。
【０００８】
従って、悪意のないユーザおよび悪質なユーザを効果的に識別するネットワーク・アプリケーションのためのセキュリティ検証スキームが必要とされている。
【課題を解決するための手段】
【０００９】
従来技術における欠点を解消するため、本発明は、ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための方法を提案する。この方法は、クライアントにおいて展開される前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、提供したセキュリティ・ルール・サブセットに基づいて前検証コンポーネントによってクライアント側でユーザ入力のセキュリティ検証を可能とするようにするステップと、保護手段のセキュリティ・ルールに基づいてユーザ入力を検証するステップと、違反ユーザ入力、および、違反のあったセキュリティ・ルールが前検証コンポーネントに提供されていないことの検出に応答して、ユーザを第１のクラスのユーザの一人と判定するステップと、違反ユーザ入力、および、違反のあったセキュリティ・ルールが前検証コンポーネントに提供されていることの検出に応答して、ユーザを第２のクラスのユーザの一人と判定するステップと、を含む。
【００１０】
好ましくは、本発明が提供する方法は、前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行するステップを更に含み、セキュリティ・ルール・サブセットは、前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供するステップにおいて、および、前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行するステップにおいて、保護手段のセキュリティ・ルール・セットからスクリーニングされる。
【００１１】
好ましくは、本発明が提供する方法において、前検証コンポーネントは、クライアント・ブラウザ上で動作することができるスタンドアロンのＪａｖａＳｃｒｉｐｔコンポーネントである。
【００１２】
好ましくは、本発明が提供する方法は、判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行するステップを更に含む。
【００１３】
好ましくは、本発明が提供する方法において、判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行するステップが、第２のクラスのユーザに対して、全ての以降の要求を強制的にブロックするようなセキュリティ保護アクションを実行するステップと、第１のクラスのユーザに対して、その良い経験を維持するのに役立つセキュリティ保護アクションを実行するステップと、を含む。
【００１４】
好ましくは、本発明が提供する方法において、ポリシーが、高い違反率を有するセキュリティ・ルールを選択することと、セキュリティ・ルール・セットにおいて全てのネガティブ・ルールを除外することと、セキュリティ・ルール・セットにおいて高リスクのセキュリティ・ルールを除外することと、の１つ以上を含む。
【００１５】
好ましくは、本発明が提供する方法においては、入力フィールドにおけるｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントに応答して、前検証コンポーネントが、提供されたセキュリティ・ルール・サブセットに基づいてクライアント側でユーザ入力のセキュリティを検証する。
【００１６】
本発明は更に、ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための装置を提案する。この装置は、クライアントにおいて展開される前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、提供したセキュリティ・ルール・サブセットに基づいて前検証コンポーネントによってクライアント側でユーザ入力のセキュリティ検証を可能とするようにするための手段と、保護手段のセキュリティ・ルールに基づいてユーザ入力を検証するための手段と、違反ユーザ入力、および、違反のあったセキュリティ・ルールが前検証コンポーネントに提供されていないことの検出に応答して、ユーザを第１のクラスのユーザの一人と判定するための手段と、違反ユーザ入力、および、違反のあったセキュリティ・ルールが前検証コンポーネントに提供されていることの検出に応答して、ユーザを第２のクラスのユーザの一人と判定するための手段と、を含む。
【００１７】
好ましくは、本発明が提供する装置は、前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行するための手段を更に含み、クライアントにおいて前検証コンポーネントにサーバ側保護手段のセキュリティ・ルールのセキュリティ・ルール・サブセットを提供して、提供したセキュリティ・ルール・サブセットに基づいて前検証コンポーネントによってクライアント側でユーザ入力のセキュリティ検証を可能とするようにするための手段、および、前検証コンポーネントに提供されたセキュリティ・ルール・サブセットに動的な更新を非同期で実行するための手段が、あるポリシーに従って保護手段のセキュリティ・ルール・セットからセキュリティ・ルール・サブセットをスクリーニングする。
【００１８】
好ましくは、本発明が提供する装置において、前検証コンポーネントは、クライアント・ブラウザ上で動作することができるスタンドアロンのＪａｖａＳｃｒｉｐｔコンポーネントである。
【００１９】
好ましくは、本発明が提供する装置は、判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行するための手段を更に含む。
【００２０】
好ましくは、本発明が提供する装置において、判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを実行するための手段が、第２のクラスのユーザに対して、全ての以降の要求を強制的にブロックするようなセキュリティ保護アクションを実行するための手段と、第１のクラスのユーザに対して、その良い経験を維持するのに役立つセキュリティ保護アクションを実行するための手段と、
を含む。
【００２１】
好ましくは、本発明が提供する装置において、ポリシーが、高い違反率を有するセキュリティ・ルールを選択することと、セキュリティ・ルール・セットにおいて全てのネガティブ・ルールを除外することと、セキュリティ・ルール・セットにおいて高リスクのセキュリティ・ルールを除外することと、の１つ以上を含む。
【００２２】
好ましくは、本発明が提供する装置においては、入力フィールドにおけるｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントに応答して、前検証コンポーネントが、提供されたセキュリティ・ルール・サブセットに基づいてクライアント側でユーザ入力のセキュリティを検証する。
【００２３】
本発明は更に、ネットワーク・アプリケーションにおけるユーザ入力のセキュリティ検証のための装置を含むセキュリティ検証システムに関する。
【００２４】
本発明の技術的ソリューションによれば、「第２のクラスのユーザ」および「第１のクラスのユーザ」を効果的に区別することができる。第２のクラスのユーザおよび第１のクラスのユーザについて異なるソリューションを構成することができ、これによって検証プロセスの妥当性を向上させる。本発明の一実施形態によれば、「第１のクラスのユーザ」のためにウェブ・アプリケーションのユーザ経験をできる限り確保し、無意味なシステム性能の消費を最大限に回避することができる。更に、サーバ側の保護手段の作業負荷を軽減し、従って検証システム全体の性能が向上する。
【００２５】
本発明についてより良く理解すれば、本発明の他の目的および効果は、以下の説明を図面と共に参照することから、いっそう明らかとなり、いっそう理解されよう。
【００２６】
図面全体を通して、同様の番号は同一、同様、または対応する特徴または機能を表す。
【図面の簡単な説明】
【００２７】
【図１】本発明の一実施形態を実施可能であるシステム構造を概略的に示す。
【図２】本発明の一実施形態に従ったユーザ入力のセキュリティ検証のための方法のフローチャートを示す。
【図３】本発明の一実施形態に従ったサーバ側保護手段およびクライアント側前検証コンポーネントのワークフロー・チャートを示す。
【図４】本発明の一実施形態に従ったセキュリティ検証システムのモジュール間のインタラクションの図を概略的に示す。
【発明を実施するための形態】
【００２８】
図１は、本発明の一実施形態を実施可能であるシステム構造を概略的に示す。参照番号１１は、クライアント側のクライアント・ブラウザを表し、これはユーザのＨＴＴＰ要求をウェブ・アプリケーション・サーバに送信すると共にウェブ・アプリケーション・サーバから対応する応答を受信するためのものである。参照番号１２はネットワークを表し、ウェブ・アプリケーション・サーバはこれを介して、ユーザがクライアント・ブラウザによって送信した要求に応答することができる。参照番号１０はウェブ・アプリケーション・サーバ側の保護手段を表し、これはサーバ側でユーザ要求における入力値を検証すると共にセキュリティ保護をウェブ・アプリケーション・サーバに与えるためのものである。参照番号１３はウェブ・アプリケーション・サーバを表す。
【００２９】
図１に示すように、ユーザは、入力値を有する要求を、クライアント側のクライアント・ブラウザ１１によって、ネットワーク１２を介してウェブ・アプリケーション・サーバ１３に送信する。ウェブ・アプリケーションのセキュリティを保証するように、このユーザの入力値を検証する必要がある。通常のユーザは、クライアント側で論理コード（例えばＪａｖａＳｃｒｉｐｔ論理）等の悪質な値を入力することはないが、潜在的な悪質ユーザは、サーバを攻撃するため、他のユーザの私的な情報を盗むため等の目的で、ウェブ・アプリケーション・サーバ１３に悪質な論理コードをインジェクションすることがある。ＪａｖａＳｃｒｉｐｔのようなこれらの悪質なコードは、サーバによってクライアントのブラウザに送信されるとクライアントの機密情報を盗む。クライアント側でウェブ・アプリケーション・レビュー・ツール（図示せず）を構成してユーザの入力値を検出することができるが、悪質なユーザは何らかのツールを用いることでウェブ・アプリケーション・レビュー・ツールを迂回して、スクリプティング・インジェクション・ツールを用いて直接ウェブ・アプリケーション・サーバ１３に悪質な値をインジェクションする場合がある。従って、サーバ側のアプリケーション・ファイアウォールのような保護手段１０は、既定のセキュリティ・ルールを用いて構成しなければならず、これに基づいて保護手段１０はユーザの入力値を検証する。保護手段１０がこのセキュリティ・ルールに違反するユーザ入力値を検出した場合、潜在的な隠された危険を取り除くように、このユーザに対して適切なセキュリティ保護対策を講じる。表１は、保護手段１０が採用し得る例示的なセキュリティ・ルールを示す。
【００３０】
【表１】
0005543611.tif 000002
【００３１】
表１に示すようなセキュリティ・ルールの例は、アプリケーションに固有のルールおよびネガティブ・ルールを含む。アプリケーションに固有のルールは、「名前」および「年齢」を表すフィールドにおいて可能なユーザ入力値に関する情報等、特定のアプリケーションによって決定される様々な入力フィールドに関するセキュリティ・ルール情報を規定する。例えば、「名前」により可能である入力値は、「安全なテキスト」の正規表現によって定義される。「年齢」により可能である入力値は、「整数」の正規表現によって定義される。アプリケーションに固有のルールは更に、このルールに違反する攻撃タイプが「ＭＡＬＦＯＲＭＥＤ（不正）」であり、行うべきセキュリティ保護アクションが「拒否」であることを規定する。ネガティブ・ルールは、ユーザ入力の負の値を規定する。すなわち、「ＸＳＳ（クロス・サイト・スクリプティング）」に合致する全ての正規表現の全てのユーザ入力値をネゲートする。ネガティブ・ルールは更に、このルールに違反する攻撃タイプが「ＸＳＳ（クロス・サイト・スクリプティング）」であり、行うべきセキュリティ保護アクションが「拒否」であることを規定する。
【００３２】
表１は保護手段１０において構成されたセキュリティ・ルールの一例を示すが、保護手段におけるセキュリティ・ルールは他の形態を含む場合がある。実際、以下に行う記述から、セキュリティ・ルールの具体的な形態および内容は本発明を限定するものではないことは当業者には理解されよう。
【００３３】
ウェブ・アプリケーションに備えられたセキュリティ検証スキームにおいては、既定のセキュリティ・ポリシーに違反した値の入力でミスを犯した悪意のないユーザに対して、保護手段１０が、ウェブ・アプリケーションのユーザ経験に大きく影響するＩＰのブロックおよび要求の拒絶等のセキュリティ保護アクションを単にセキュリティ・ポリシーに基づいて行うことを防ぐような対応をしなければならない。更に、悪質なコードをインジェクトした悪質なユーザに対して、保護手段１０が、システム性能の消費を増大させるユーザ・フレンドリなセキュリティ・ヒントの送信、更にはペイロードの書き換え等のセキュリティ保護アクションを行うことを防ぐような対応をしなければならない。本発明に従ったセキュリティ検証スキームにおいては、保護手段１０は、セキュリティ・ルールに違反したユーザのクラスを効果的に区別して、違反者であるユーザに対して適切かつ妥当なセキュリティ保護アクションを実行することを可能とする。すなわち、第１のクラスのユーザ（悪意のないユーザとして判定される傾向がある）のユーザ経験を保証し、第２のクラスのユーザ（悪質なユーザとして判定される傾向がある）のために貴重なシステム性能を無駄にすることはない。
【００３４】
第１のクラスのユーザは、ユーザ入力値がセキュリティ・ルールに合致するまで、システムが与えるセキュリティ・ヒントに従って違反入力を訂正する傾向があることに留意すべきである。しかしながら、第２のクラスのユーザは、ウェブ・アプリケーション・サーバ１３に悪質な値をインジェクトする意図があり、その入力は検証プロセスにおけるユーザ・フレンドリなインタラクションにおいてセキュリティ・ルールに合致しない。従って、本発明が提案する設計では、保護手段１０がクライアント・ブラウザ１１上で前検証コンポーネントを展開し、この前検証コンポーネントは、保護手段１０が与える何らかのセキュリティ・ルールに従ってクライアント側でユーザ入力を前検証させられる。保護手段１０は、既定のセキュリティ・ルールに従ってユーザ入力を検証し、クライアント側の前検証およびそれ自身が実行する検証に従ってユーザが第１のクラスのユーザまたは第２のクラスのユーザのどちらに属するかを判定し、それに基づいて行うべきセキュリティ保護アクションが選択される。
【００３５】
図２は、本発明の一実施形態に従ったユーザ入力のセキュリティ検証方法のフローチャートを示す。
【００３６】
この方法はステップＳ２００において開始する。
【００３７】
ステップＳ２１０において、クライアント上で展開される前検証コンポーネントに、サーバ側の保護手段におけるセキュリティ・ルールのサブセットを提供する。これによって前検証コンポーネントは、提供されたセキュリティ・ルールのサブセットに基づいてクライアント側でユーザ入力値のセキュリティを検証する。
【００３８】
クライアント上の前検証コンポーネントは、保護手段によってクライアント上に展開することができ、または、クライアントのプラグインによってネットワークを介して保護手段から取得することができる。例えば、前検証コンポーネントはスタンドアロンのＪａｖａＳｃｒｉｐｔコンポーネントとすることができる。一実施において、保護手段はＪａｖａＳｃｒｉｐｔ前検証コンポーネントをアプリケーション応答ページ内に挿入し、前検証コンポーネントがクライアント・ブラウザによって動作されるようにする。
【００３９】
保護手段によってクライアント側の前検証コンポーネントに提供されるセキュリティ・ルールは、好ましくは、保護手段におけるセキュリティ・ルールの適切なサブセットである。セキュリティ・ルールを示すセキュリティ・ポリシー・ファイルを前検証コンポーネントに提供することができる。クライアント側の前検証コンポーネントにおいて定義された正規表現がサーバ側保護手段において定義された正規表現と互換性がある限り、セキュリティ・ポリシー・ファイルは、簡単に言うと、クライアント側で前検証コンポーネントにより監視されるエイリアス（例えば電子メール、ＵＲＬ、安全なテキスト、ＸＳＳ等）、フィールド名、ＵＲＩを含むことができる。
【００４０】
ステップＳ２２０において、違反ユーザ入力値が検出されると、違反のあったセキュリティ・ルールがクライアント側の前検証コンポーネントに提供されているか否かが判定される。
【００４１】
ステップＳ２２０において、違反のあったセキュリティ・ルールがクライアント側の前検証コンポーネントに提供されていると判定された場合、これが意味するのは、サーバ側保護手段が、クライアント側の前検証モジュールによって解決されるべきであったセキュリティ問題を検出しており、違反者であるユーザは、例えば添付ツールによってクライアント側の前検証機構を迂回した後に直接ウェブ・アプリケーションに悪質な値をインジェクションしたということである。従って、ステップＳ２３０において、違反者は「第２のクラスのユーザ」の一人と判定される。第２のクラスのユーザは悪質なユーザと判定される傾向がある。
【００４２】
一方、ステップＳ２２０において、違反のあったセキュリティ・ルールがクライアント側の前検証コンポーネントに提供されていないと判定された場合には、ステップＳ２４０において、違反者であるユーザは「第１のクラスのユーザ」の一人と判定される。第１のクラスのユーザは悪意のないユーザと判定される傾向がある。
【００４３】
好ましくは、ステップＳ２５０において、前検証コンポーネントに提供されるセキュリティ・ルールのサブセットを非同期で更新する。「非同期で」更新を行うというのは、更新ステップが検証プロセス全体に対して独立して実行されるということを意味する。例えば一実施において、更新プロセスは、背景でＡＪＡＸ（非同期ＪａｖａＳｃｒｉｐｔおよびＸＭＬ）技法を用いて実施することができる。この更新ステップは定期的または不定期的に実行することができ、保護手段は、あるポリシーに従ったセキュリティ・ルール・セット全体から、前検証コンポーネントに提供されるべきセキュリティ・ルールのサブセットをスクリーニングする。保護手段は、セキュリティ検証ログの統計データによる違反率に従って各セキュリティ・ルールにランク付けし、高い違反率を有するセキュリティ・ルールをクライアント側の前検証コンポーネントに提供するためにスクリーニングすることができる。例えば、第２のクラスのユーザは、入力値に対するクライアント側の前検証コンポーネントの応答（例えば様々なセキュリティ・ヒント等）を分析することによって、前検証コンポーネントにおけるセキュリティ・ルールに関する情報を取得することができるので、いくつかの特定のルールについては制限を設けながら前検証コンポーネントのためのセキュリティ・ルール・サブセットをスクリーニングすることを、更に注記することができる。好適な実施形態において、スクリーニングされるセキュリティ・ルール・サブセットは以下の条件の１つ以上を満足させることができる。
【００４４】
１．各々が高い違反率を有するセキュリティ・ルールを選択する。
２．セキュリティ・ルール・セットにおいて全てのネガティブ・ルールを除外する。
３．高リスクのセキュリティ・ルール、すなわちいったん違反されるとシステム・セキュリティに重大な脅威となるルールを除外する。
【００４５】
クライアント側の前検証コンポーネントのためのセキュリティ・ルール・サブセットを動的に更新することによって、前検証機構がカバーすることのできるセキュリティ・ルールの範囲が拡大し、第２のクラスのユーザが入力を試みてセキュリティ・ルールに関する情報を取得することは難しくなる。なぜなら、更新アクションおよび更新された内容は完全にサーバ側の保護手段に依存するからである。このようにして、前検証の精度およびシステムのセキュリティが向上する。
【００４６】
この方法はステップＳ２６０において終了する。
【００４７】
本発明に従った技術的ソリューションはユーザのクラスを効果的に区別することができるので、保護手段は、判定された「第１のクラスのユーザ」および「第２のクラスのユーザ」に対して異なるセキュリティ保護アクションを実行するように構成することができる。「悪質なユーザ」と判定される傾向がある「第２のクラスのユーザ」に対しては、例えば、ＩＰのブロック等、以降の入力要求の全てを強制的にブロックするようなセキュリティ保護アクションを行うことができる。「悪意のないユーザ」と判定される傾向がある「第１のクラスのユーザ」に対しては、例えば、要求の拒絶、およびユーザ・フレンドリなセキュリティ・ヒントの送信またはペイロードの書き換えあるいはその両方等、彼らの良い経験の維持に役立つセキュリティ保護アクションを行う。
【００４８】
この後、サーバ側およびクライアント側のコンポーネント間でのワークフローおよびインタラクションを示す一例により、本発明に従った技術的ソリューションについて更に詳細に説明する。
【００４９】
図３は、本発明の一実施形態に従ったサーバ側保護手段およびクライアント側前検証コンポーネントのワークフロー・チャートを示す。
【００５０】
図３に示すように、ステップＳ３０１では、保護手段１０において既定セキュリティ・ルール・セットをセットアップする。セキュリティ・ルール・セットは、アプリケーションに固有のルールおよびネガティブ・ルールを含む。このステップは、ユーザ入力プロセスと非同期で実行され、通常は保護手段１０の展開中に実行されることは理解されよう。
【００５１】
ステップＳ３０２において、保護手段１０は、スタンドアロンのＪａｖａＳｃｒｉｐｔの前検証コンポーネントをアプリケーション応答ページ内に挿入するように、アプリケーション応答ページを書き換える。本発明の一実施によれば、ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは表２におけるコードによって実施することができる。
【００５２】
【表２】
0005543611.tif 000003
【００５３】
ステップＳ３０３では、クライアント・ブラウザ１１においてＪａｖａＳｃｒｉｐｔ前検証コンポーネントが動作される。
【００５４】
ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは、ページの各ユーザ入力フィールドにｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントのためのモニタを追加し、ユーザ入力フィールドにおけるｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントを監視することによってユーザ入力のための前検証プロセスを活性化するようになっている。ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは更に、保護手段１０からセキュリティ・ポリシー・ファイルを取得するための手段を提供する。セキュリティ・ポリシー・ファイルは、保護手段１０におけるセキュリティ・ルールのルール・サブセットを表す。
【００５５】
【表３】
0005543611.tif 000004
【００５６】
ステップＳ３０４において、保護手段１０は、クライアント・ブラウザ１１におけるＪａｖａＳｃｒｉｐｔ前検証コンポーネントにセキュリティ・ポリシー・ファイルを更新または送信する。保護手段１０によって検出された違反ログの統計データに従って、保護手段１０におけるセキュリティ・ルール・セット全体から、セキュリティ・ポリシー・ファイルに含まれるセキュリティ・ルール・サブセットをスクリーニングする。セキュリティ・ポリシー・ファイルは、違反率の高い入力フィールドおよび対応するパターンのリストを含むことができる。
【００５７】
ステップＳ３０５において、ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは、クライアント・ブラウザ１１においてサーバ側保護手段１０からセキュリティ・ポリシー・ファイルを取得する。
【００５８】
ステップＳ３０６では、ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは、クライアント・ブラウザ１１において、入力フィールドのｏｎＰｒｏｐｅｒｔｙＣｈａｎｇｅイベントに応答して、セキュリティ・ポリシー・ファイルにおけるセキュリティ・ルールに基づいてユーザ入力フィールドを検証する。一実施において、前検証を可能とする機能は表４のコードによって実施することができる。
【００５９】
【表４】
0005543611.tif 000005
【００６０】
ユーザ入力値の違反が検出された場合、ユーザにフレンドリ・ヒントが提供される。例えば、正しい入力値の一例を与え、現在の入力値における問題を示すので、ユーザはこのヒントに従って入力フィールドに対する正しい入力を完了することができる。
【００６１】
ステップ３０７において、クライアント・ブラウザ１１は、ユーザのＨＴＴＰ要求をサーバ側保護手段１０に送信する。ＪａｖａＳｃｒｉｐｔ前検証コンポーネントは、セキュリティ・ポリシー・ファイルに基づいて入力フィールドの一部のみまたはセキュリティ・ルールの一部のみを検証することができ、ＪａｖａＳｃｒｉｐｔ前検証コンポーネントによってユーザ入力値の全てが前検証されるわけではないことに留意すべきである。換言すると、クライアント・ブラウザ１１によって保護手段１０に送信されたユーザのＨＴＴＰ要求は、前検証されたユーザ入力値またはまだ前検証されていないユーザ入力値を含むことができる。前検証されたユーザ入力値はセキュリティ・ルールに合致するが、前検証されていないユーザ入力値はセキュリティ・ルールに違反している可能性があることは理解されよう。
【００６２】
この点に鑑み、ステップＳ３０８においてサーバ側保護手段１０は、既定のセキュリティ・ポリシーに基づいてＨＴＴＰ要求に含まれる全てのユーザ入力値を検証する。
【００６３】
ステップＳ３０９において、違反が検出された場合、違反のあったセキュリティ・ルールがクライアント側ＪａｖａＳｃｒｉｐｔ前検証コンポーネントに更新されているか否かを判定する。
【００６４】
保護手段１０が違反を検出した場合、違反のあったセキュリティ・ルールがクライアント側ＪａｖａＳｃｒｉｐｔ前検証コンポーネントに更新されていないならば、ステップＳ３１１において対応するユーザは「第１のクラスのユーザ」の一人と判定される。第１のクラスのユーザは悪意のないユーザと判定される傾向がある。
【００６５】
ステップＳ３１２において、判定された「第１のクラスのユーザ」に対して、ユーザの良い経験を維持するのに役立つセキュリティ保護アクションを実行する。例えば、要求を再構成し（書き換え要求）、この要求をアプリケーション・サーバに送信する。第１のクラスのユーザは悪意のないユーザと判定される傾向がある。
【００６６】
保護手段１０が違反を検出した場合、違反のあったセキュリティ・ルールがクライアント側ＪａｖａＳｃｒｉｐｔ前検証コンポーネントに更新されているならば、ステップＳ３１３において対応するユーザは「第２のクラスのユーザ」の一人と判定される。これは、ユーザが、ツールを用いてクライアント・ブラウザにおける前検証機構を迂回した後に、セキュリティ・ルールに違反する悪質な値を直接アプリケーション・サーバにインジェクトしているからである。
【００６７】
ステップＳ３１４において、判定された「第２のクラスのユーザ」に対して、この後の全ての要求を強制的にブロックするセキュリティ保護アクションを行う。例えば、ＩＰをブロックする。
【００６８】
異なるウェブ・アプリケーションでは、判定された「第２のクラスのユーザ」または「第１のクラスのユーザ」に対して異なるセキュリティ保護アクションを実行可能であることは、当業者には認められよう。それらは、具体的なアプリケーション要求に従って異なる格付けまたは異なる特徴によってセキュリティ保護アクションを設定し、これらのセキュリティ保護アクションを、判定された「第２のクラスのユーザ」または「第１のクラスのユーザ」に割り当てることができる。
【００６９】
図３において本発明の特定の実施形態を説明するために一例としてＪａｖａＳｃｒｉｐｔ前検証コンポーネントを用いたが、前検証コンポーネントを実施するために、ＶＢｓｃｒｉｐｔ等、ウェブ・アプリケーションと互換性のある他のいずれかのコード言語を使用可能であることを記載するべきであろう。更に、当業者は、いかなる既知の方法でもクライアントにおいて前検証コンポーネントを展開することができる。更に別の実施は、例えば、前検証コンポーネントをアクティブに取得するようにクライアントにおける特定のプラグインの提供を含むことができる。従って、前検証コンポーネントの具体的な実施は本発明を限定しない。
【００７０】
図４は、本発明の一実施形態に従ったセキュリティ検証システムの機能ブロック図を概略的に示す。
【００７１】
図４に示すように、クライアント・ブラウザ１１は、ＨＴＴＰ要求をウェブ・アプリケーション・サーバ１３に送信し、ウェブ・アプリケーション・サーバ１３から対応した応答を取得する。サーバ側保護手段１０は、既定のセキュリティ・ルール・セットに基づいてユーザからの要求に入力検証を実行して、ウェブ・アプリケーション・サーバ１３のセキュリティを保証するようにする。
【００７２】
保護手段１０は、クライアント・ブラウザにおいて前検証コンポーネントを展開するための任意の展開手段１０１と、クライアント側前検証コンポーネントにセキュリティ・ルール・サブセットを提供または更新するための更新手段１０２と、既定セキュリティ・ルール・セットに基づいてユーザからの要求に入力検証を実行するための検証手段１０３と、悪意のないユーザと判定される傾向がある「第１のクラスのユーザ」または悪質なユーザと判定される傾向がある「第２のクラスのユーザ」として違反者ユーザのクラスを判定するための判定手段１０４と、を含む。
【００７３】
保護手段１０において、あるいは、展開手段１０１は、アプリケーション応答ページを書き換えることによってＪａｖａＳｃｒｉｐｔコンポーネントをアプリケーション応答ページ内に挿入し、クライアント・ブラウザ１１において前検証コンポーネント１１０を展開する。更新手段１０２は、定期的または不定期的にクライアント・ブラウザ１１における前検証コンポーネント１１０にセキュリティ・ポリシー・ファイルを送信または更新する。この場合、保護手段１０により検出された違反ログの統計データに従って、保護手段１０におけるセキュリティ・ルール・セット全体から、セキュリティ・ポリシー・ファイルに含まれるセキュリティ・ルール・サブセットをスクリーニングする。
【００７４】
前検証コンポーネント１１０は、クライアント・ブラウザ１１において動作され、サーバ側保護手段１０からセキュリティ・ポリシー・ファイルを取得し、セキュリティ・ポリシー・ファイルにおけるセキュリティ・ルールに基づいてユーザ入力フィールドを検証して、ユーザ入力が現在のセキュリティ・ルール・サブセットに違反しないことを確実とする。クライアント・ブラウザ１１はユーザのＨＴＴＰ要求をウェブ・アプリケーション・サーバ１３に送信する。
【００７５】
保護手段１０における検証手段１０３は、既定のセキュリティ・ポリシー・セットに基づいてユーザからのＨＴＴＰ要求における全てのユーザ入力値を検証する。違反を検出すると、判定手段１０４は、違反のあったセキュリティ・ルールがクライアント・ブラウザ１１における前検証コンポーネント１１０に更新されているか否かを判定する。違反のあったセキュリティ・ルールがクライアント・ブラウザ１１における前検証コンポーネント１１０に更新されていない場合、判定手段１０４は、ユーザを「第１のクラスのユーザ」の一人と判定する。違反のあったセキュリティ・ルールがクライアント・ブラウザ１１における前検証コンポーネント１１０に更新されている場合、判定手段１０４は、ユーザを「第２のクラスのユーザ」の一人と判定する。保護手段は、判定された第１のクラスのユーザおよび第２のクラスのユーザに対して異なるセキュリティ保護アクションを行うように構成することができる。例えば、判定された第１のクラスのユーザに対して、要求の書き換え（書き換え要求）等、ユーザの良い経験を維持するのに役立つセキュリティ保護アクションを行う。判定された第２のクラスのユーザに対して、ＩＰのブロック等、以降の要求を全て強制的にブロックするセキュリティ保護アクションを行う。
【００７６】
本発明のセキュリティ検証スキームに従って、ウェブ・アプリケーション・サーバ側の保護手段は、クライアントに前検証コンポーネントを展開し、前検証コンポーネントに前検証セキュリティ・ルールを提供し、好ましくは、前検証セキュリティ・ルールを動的に更新する。従って、違反ユーザ入力値を検出すると、保護手段は、違反のあったルールがクライアント側の前検証コンポーネントによって検証されているか否かを決定することによって、このユーザが「第２のクラスのユーザ」であるか否か、すなわち、ユーザが何らかの不法手段によってクライアント側の前検証機構を迂回することで直接ウェブ・アプリケーション・サーバに悪質な論理コードを送信したか否かを判定することができる。明らかに、本発明の技術的なソリューションに従って「第２のクラスのユーザ」および「第１のクラスのユーザ」を効果的に区別することができるので、異なるユーザに対して異なるソリューションを実行する、すなわち異なるセキュリティ保護アクションを実行するように保護手段を構成することができる。本発明の一実施形態によれば、「第１のクラスのユーザ」のためにウェブ・アプリケーションのユーザ経験をできる限り確保し、無意味なシステム性能の消費を最大限に回避することができる。更に、クライアント側に前検証機構を配置することによりクライアント側で検証プロセスの一部を実行することができ、これによってサーバ側の保護手段の作業負荷を軽減し、従って検証システム全体の性能を向上させることに役立つ。
【００７７】
具体的な実施形態の前述の記載から当業者に容易に明らかになるように、前述の方法、装置、および対応するシステムは、プロセッサに含まれるコンピュータ実行可能命令または制御コードあるいはその両方を用いて実施可能である。例えば、かかるコードは、磁気ディスク、ＣＤまたはＤＶＤ−ＲＯＭ、読み取り専用メモリ（ファームウェア）等のプログラマブル・メモリ、または光もしくは電子信号担体等のデータ担体のような搬送媒体上に提供される。本発明の実施形態における手段およびユニットは、ＶＬＳＩもしくはゲート・アレイ、論理チップおよびトランジスタのような半導体、またはフィールド・プログラマブル・ゲート・アレイおよびプログラマブル論理デバイス等のプログラマブル・ハードウェア・デバイス等のハードウェア回路によって、または様々なタイプのプロセッサにより実行されるソフトウェアによって、またはハードウェア回路およびソフトウェア回路の組み合わせによって実施可能である。
【００７８】
本発明の明細書は、例示および記載の目的のために提示したものであり、開示した形態における本発明を網羅することも限定することは意図していない。当業者には多くの変更および変形が明らかであろう。
【００７９】
従って、本発明の原理、実際の適用を最良に説明するため、更に、本発明の範囲から逸脱することなく行われるあらゆる変更および変形を当業者が理解することを可能とするために、実施形態を選択し記載した。
【図１】
0005543611.tif 000006
【図２】
0005543611.tif 000007
【図３】
0005543611.tif 000008
【図４】
0005543611.tif 000009