JP2018190378A - システム、プログラム、およびヒューリスティック - Google Patents

Abstract

【課題】ネットワークを介して要求の起点を検証するためのシステムおよび方法が提供される。【解決手段】このシステムは、ネットワークを介して1つまたは複数のデータベースおよびサーバーと通信するパーソナル電子デバイスを含む。サーバーは、特定のユーザーを識別するために使用されるセッションＩＤおよびセッション確認パッケージを生成するように構成される。セッション確認パッケージは、パーソナル電子デバイスのＩＰアドレスおよびブラウザエージェントを含む。その後、サーバーおよびデータベースは、ユーザーのセッションごとにセッション検証キーを生成するように構成される。セッション検証キーは、アクセスと検証ごとに自動的に更新される。セッション検証キーは、第三者の装置がコピーされた検証キーおよびＩＤを用いてネットワークにアクセスするときに、パーソナル電子装置上で更新される。このため第三者の装置は、新しい更新セッション検証キーの受信に失敗し、アクセスが拒否される。【選択図】図１６

Description

本発明は、承認されていないコンピュータへの不用意な情報の転送を防止するために、コンピュータネットワーク内のリクエストの起点を確認するためのシステム、プログラム、およびヒューリスティックに関する。
２．関連技術の説明

ｈｔｔｐ（HyperText Transfer Protocol）は、ネットワークを介してメディアを送信するためのプロトコルであり、インターネット上で使用される最も一般的なプロトコルの１つである。情報は、特定のＩＰアドレスを持つクライアントコンピュータから、同じネットワーク上のＩＰアドレスを持つホストコンピュータに要求される。場合によっては、ホストコンピュータが有効な署名として認識するユーザー名やパスワード、またはその他のパラメータなど、ホストコンピュータから何らかの形式の検証が要求されることがある。
ネットワークを介して認証されたコンピュータとの間でリクエストを識別するために、ホストコンピュータはしばしばＣｏｏｋｉｅとして知られているものを生成する。Ｃｏｏｋｉｅは、文字と数字のセットがネットワーク上の他のコンピュータによって容易に偽造されないように、十分にランダムに生成された文字と数字のセットであることが最も一般的である。これらのＣｏｏｋｉｅは、ホストコンピュータから発行され、クライアントコンピュータからのすべてのリクエストのｈｅａｄｅｒに挿入され送信される。

特開平１１−０９８１３４号公報

Ｃｏｏｋｉｅに関する一つの問題は、それらがｈｔｔｐリクエストのｈｅａｄｅｒに含まれるので、クライアントおよびソースコンピュータのネットワーク上のコンピュータがそれらを読み取ることができることである。クロスサイトスクリプティング攻撃のような場合には、クライアントコンピュータは、クライアントコンピュータのリクエストに添付されたＣｏｏｋｉｅを用いて、ネットワーク上の第三者コンピュータにｈｔｔｐリクエストを送信させる実行コードに、騙される。クライアントコンピュータがホストコンピュータに対して自身を認証するために使用するＣｏｏｋｉｅまたは文字と数字のランダムセットを取得すると、第三者はこのＣｏｏｋｉｅをｈｔｔｐリクエストに添付してクライアントコンピュータとして偽装することが可能となる。

ネットワーク内のセキュリティを高める技術が進んでいるものの、まだ欠点が残っている。認証されるコンピュータが実際にリクエストを行うコンピュータであることを保証するためのシステムおよび方法が必要である。言い換えれば、ログイン（すなわち、おそらくＣｏｏｋｉｅによる）を確認するだけでなく、ログインの起点がログインしたコンピュータのものと同じであることを確認するシステムが必要である。

上記目的を達成するために、開示のシステムが提供される。このシステムは、ネットワーク経由の要求の起点(の正当性)を検証するために、下記を有するシステムであり、ネットワークを介してデータを検索し、処理し、送信するために構成されたプロセッサ、メモリ記憶装置、入力／出力インタフェースと、を有するパーソナル電子装置と、ネットワークを介して前記パーソナル電子装置と通信する１つまたは複数のデータベースと、ネットワークを介してパーソナル電子デバイスと通信する１台または複数台のサーバーであって、前記１つまたは複数のデータベースとの間で情報の送信を制御し、継続して利用するユーザーを特定するために、一意的なセッションＩＤを生成する１台または複数台のサーバーと、ＩＰアドレス、セッションＩＤ、およびブラウザエージェント、１つまたは複数のデータベース上のファイルへのアクセスを制限するために構成された１台または複数のサーバーによって生成され、ネットワークを介して１台または複数のサーバーと、１つまたは複数のデータベースへの継続的なアクセスを保証する一意性を識別するセッション確認パッケージを有している。

本願の実施形態によるネットワーク内の要求の起点を検証するためのシステムの図である。

図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。 図１の要求元を検証するためにシステムにログインするプロセスを示す図である。

図１の要求の起点を確認するためにシステムからログアウトするプロセスを示す図である。 図１の要求の起点を確認するためにシステムからログアウトするプロセスを示す図である。 図１の要求の起点を確認するためにシステムからログアウトするプロセスを示す図である。 図１の要求の起点を確認するためにシステムからログアウトするプロセスを示す図である。

複数のセッションおよび複数の接続を有する図１の要求の起点を検証するためのシステムの例示的な動作を示す図である。 複数のセッションおよび複数の接続を有する図１の要求の起点を検証するためのシステムの例示的な動作を示す図である。 複数のセッションおよび複数の接続を有する図１の要求の起点を検証するためのシステムの例示的な動作を示す図である。

ユーザーが図１の要求元を検証するためにシステムからログアウトしなかった場合にセッションが終了するプロセスの図である。

本出願の特徴と考えられる新規の特徴は、添付の特許請求の範囲に記載している。しかしながら、アプリケーション自体、ならびに好ましい使用モードおよびさらなる目的および利点は、添付の図面と併せて読むと以下の詳細な説明を参照することによって最もよく理解される。
本出願のシステムおよび方法は、様々な修正および代替形態が可能であるが、それらの特定の実施形態は、図面の例として示されており、本明細書において詳細に記載されている。しかしながら、特定の実施形態に関する本明細書の記載は、本出願を開示された特定の実施形態に限定することを意図するものではなく、むしろ、本発明の精神および範囲内に入る全ての変更、均等物、添付の特許請求の範囲によって規定されるような本出願のプロセスの一部である。

以下、好ましい実施形態の例示的な実施形態について説明する。説明を容易にするため、実際の実装のすべての機能がこの仕様で記述されているわけではない。そのような実際の実施形態の開発においては、システム関連およびビジネス関連制約への遵守など、開発者の特定の目標を達成するために多数の実装固有の決定が行われなければならないことはもちろんである。さらに、そのような開発努力は、複雑で時間がかかるが、それにもかかわらず、本開示の恩恵を受ける当業者にとって日常的な仕事であることが理解される。

本明細書では、様々な構成要素間の空間的関係と、その装置が添付の図面に示されているように、構成要素の様々な態様の空間的な向きを参照することができる。しかし、本出願を完全に読んだ後に当業者に認識されるように、本明細書に記載の装置、部材、装置などは、任意の所望の方向に配置することができる。したがって、様々な構成要素間の空間的関係を記述するため、またはそのような構成要素の態様の空間的方向を記述するために用語を使用することは、構成要素間の相対的関係またはそのような構成要素の態様の空間的方向を、デバイスは、任意の所望の方向に向けることができる。

本出願によるシステムおよび方法は、従来のドア用のセキュリティ装置に一般的に関連する上述の問題の１つまたは複数を克服する。特に、システムは、ログインしたコンピュータのログイン元と同じであるだけでなく、ログインしているユーザーまたはコンピュータを確認するための多層認証プロトコルを提供するように構成されている。システムを使用して、機密情報を配布する前に、ネットワーク上のユーザーとコンピュータを認証する。さらに、システムは、後続のコンピュータの接続時にネットワーク上の既存のコンピュータのセッション確認キーを自動的に更新して、後続のコンピュータが正確で更新されたセッション確認キーを検索できないように構成されている。装置のこれらの及び他の独特の特徴は、添付図面に示し、以下に説明する。

システムおよびその手法は、添付の記述と併せて、添付図面からその構造および動作が理解される。この装置のいくつかの実施形態を本明細書に提示する。異なる実施形態の様々な構成要素、部分、および特徴は、すべての変形および特定の実施形態が示されているわけではないが、それらの全てが本出願の範囲内にある、相互に組み合わせおよび／または相互交換されてもよいことを理解されたい。図面では、特徴、要素、および／または機能の混合およびマッチングは、本明細書において明白に企図されているので、事業者は、本特許開示から、特徴、要素および／または機能他に記載がない限り、適切な別の実施形態に組み込むことができる。

本出願のシステムおよびその手法は、添付の図面に示される。このシステムは、情報を転送するための任意の数のサーバーおよび／またはデータベースとネットワークを介して通信する１つまたは複数のコンピュータを含む。システムは、ネットワークを介してユーザーとコンピュータの多層確認を提供するように構成されている。装置の追加の特徴および機能は、添付図面に図示し、以下に説明される。

関連する図に記載される本出願のシステムは、ネットワークを介して通信するように構成された１つ以上の様々な電子デバイスを含むことができる。これらのデバイスのいずれも、適切な通信および実行可能データの転送を容易にするために、入出力（I/O）インターフェース、プロセッサ、データベース、およびメンテナンス・インタフェースの少なくともいずれかを含むことができる。システムの実施形態は、以下に説明するタスクを実行するように構成された１つまたは複数のプロセッサおよびメモリを含む１つまたは複数のコンピュータを含むことができる。これは、例えば、中央処理装置（ＣＰＵ）と、本明細書で説明するタスクの少なくとも一部を実行するようＣＰＵに命令するためのソフトウェア命令を記憶する不揮発性メモリとを有するコンピュータを含むことができる。これは、例えば、コンピュータネットワークを介して通信する２台以上のコンピュータを含み、1台以上のコンピュータがＣＰＵおよび不揮発性メモリを含み、1台以上のコンピュータの不揮発性メモリがソフトウェア本明細書に記載のタスクのいずれかを実行するようにＣＰＵのいずれかに指示する命令。したがって、例示的な実施形態は、離散的なマシンに関して説明されているが、この説明は非限定的であり、本説明は、いずれかの方法で分散されたタスクを実行する１つまたは複数のマシンを含む多数の他の構成に等しく適用される、１つまたは複数のマシンである。また、そのようなマシンは、本明細書で説明するタスクを実行するために専用である必要はなく、他のタスクを実行するのに適したコンピュータワークステーションなどの多目的マシンでもよいことと理解される。さらに、コンピュータは、一時的および非一時的な形態のコンピュータ可読媒体を使用することができる。非一時的なコンピュータ可読媒体は、一時的な伝播信号であることを除いて、すべてのコンピュータ可読媒体を含むと解釈される。

I/Oインターフェースは、外部ユーザー、システム、およびデータソースとシステムのコンポーネントとの間の通信リンクを提供する。I/Oインターフェースは、１人または複数のユーザーが任意の既知の入力デバイスを介してシステムに情報を入力できるように構成することができる。例としては、キーボード、マウス、タッチスクリーン、マイクロフォン、および/または任意の他の所望の入力装置を挙げることができる。I/Oインターフェースは、１人または複数のユーザーが任意の既知の出力装置を介してシステムから情報を出力することを可能にするように構成することができる。例としては、ディスプレイモニタ、プリンタ、スピーカ、および／または任意の他の所望の出力デバイスを含めることができる。I/Oインターフェースは、他のシステムがシステムと通信できるように構成することができる。例えば、I/Oインターフェースは、１つまたは複数のリモートコンピュータが情報にアクセスし、情報を入力し、および／または本明細書に記載された１つまたは複数のタスクを実行するためにシステムに遠隔指示することを可能にすることができる。 I/Oインターフェースは、１つまたは複数のリモートデータソースとの通信を可能にするように構成できる。例えば、I/Oインターフェースは、１つまたは複数のリモートデータソースが情報にアクセスし、情報を入力し、および／または本明細書に記載された１つまたは複数のタスクを実行するためにシステムに遠隔指示することが可能である。

データベースは、システムのための持続的なデータ記憶装置を提供する。用語「データベース」が主に使用されるが、メモリまたは他の適切なデータ記憶装置がデータベースの機能性を提供してもよい。別の実施形態では、データベースは、システムと一体であっても、システムとは別のものであってもよく、１つ以上のコンピュータ上で動作することができる。データベースは、好ましくは、図に関連して以下に説明する様々なタイプのデータを含む、システムの動作をサポートするのに適した任意の情報の不揮発性データ記憶を提供する。

保守用インターフェースは、ユーザーがシステムの所望の動作を維持できるように構成されている。いくつかの実施形態では、メンテナンス・インタフェースは、データベースに格納されたデータを見直しおよび／または改訂すること、および／またはデータベース管理に共通して関連する任意の適切な管理タスクを実行することを可能にするように構成することができる。これは、例えば、データベース管理ソフトウェアの更新、セキュリティ設定の改訂、および／またはデータバックアップ操作の実行を含むことができる。いくつかの実施形態では、メンテナンス・インタフェースは、プロセッサおよび／またはI/Oインターフェースのメンテナンスを可能にするように構成することができる。これは、例えば、ソフトウェア更新および／またはセキュリティ管理および／または特定の許容差設定の調整などの管理タスクを含むことが可能である。

ここで図面を参照すると、同様の参照符号は、いくつかの図を通して形態および機能において対応するまたは類似の要素を識別する。図１には、ネットワーク内の要求の起点を検証するためのシステム９９が示されている。図１は、本出願の全体的な構造を示す。システム９９は、電子デバイス１０１（すなわち、パーソナルコンピュータ）および一連のデータベースおよび／またはサーバー３０１〜３０５を含む。デバイス１０１は、プロセッサ、メモリの何らかの方法、不揮発性記憶装置、ネットワーキング、入出力を含む。図示されたパーソナルコンピュータ以外の他の装置は、システム９９内で動作可能であってもよい。例えば、装置１０１は、スマートフォン、タブレットまたはその他のスマート装置のような機能的に類似の任意の装置を含むことができる。

ウェブブラウザ１０２は、デバイス１０１上で動作可能であり、データとしてインターネット２０１（一連のネットワーク）を介してＴＣＰリクエストを送受信することができる。さらに、データを画面上のイメージとして表示したり、ネットワーク上のホストからダウンロードしたコードを実行したり、ｈｔｔｐプロトコルを使用して要求を送信または受信したりすることも可能である。装置１０１のファイルシステム１０３は、ウェブブラウザ１０２と通信し、選択された情報を記憶することができる。ファイルシステム１０３は、ウェブブラウザ１０２が利用するためにキャッシュされたウェブサイト、画像、Ｃｏｏｋｉｅ、および他の情報などのデータを保存するために使用される。

インターネット２０１は、しばしばクラウドと呼ばれる。これは、ネットワークアドレス変換やＩＰアドレスルーティングなどのさまざまなメカニズムを使用して地球をカバーするネットワークシステムであり、ネットワークの一方のコンピュータから要求を受け取り、ネットワーク上の別のコンピュータに転送してから、元の要求を行ったコンピュータに返信する。

リバースプロキシサーバー３０１は、インターネットにおいてエンドポイントとして機能し、リバースプロキシサーバー３０１が接続されているインターネットとは別のネットワーク上の他のコンピュータにトラフィックを転送するコンピュータである。これにより、複数のサーバーを単一のドメインポリシーを必要とするウェブクライアントの１つのエンドポイントとして表示することができます。本出願における分離の理由は、これにより、リバースプロキシサーバー３０１は、処理されるネットワーク上の他のサーバーにリバースプロキシサーバー３０１を渡す前に、サーバーへの要求のチェックのセットを実行することが可能になる。

３０２はウェブソケットサーバーである。ウェブソケット３０２は、ｈｔｔｐプロトコルに追加されたものである。それらは接続をアクティブに保つために一定の間隔で両方のコンピュータがｐｉｎｇを送信することを必要とするＴＣＰ接続です。ウェブソケット接続を共有する２台のコンピュータのうちの１台が所定の時間内にｐｉｎｇを送信できない場合、その接続は反対側のコンピュータ接続によって切断されたと判断される。このプロトコルは、接続を確立するためのハンドシェイク、接続を終了するための方法、およびこれらの接続を介してバイナリまたはテキストデータを送信するための方法も定義する。

３０３はアプリケーションサーバーである。アプリケーションサーバー３０３は、クライアントからの要求を受け取り、所与の要求の許可レベルに応じていくつかの設定された条件に基づいて動作することができるネットワークベースのサーバーに本出願が使用する用語である。たとえば、クライアントはデータベースから一連の値を要求したり、一連の値をデータベースに書き込んだり、要求の内容に基づいてクライアントから要求を実行したりすることがある。一般に、アプリケーションサーバー３０３は、アプリケーションを実行するように構成される。

３０４はデータストアサーバーである。データストアサーバー３０４は、データベースサーバーと同様の機能を果たすが、別の機能を実行する。データストアサーバー３０４は、所与のキーの所与の値のリストを格納するネットワーク指向のサーバーである。また、多くの場合、デバイスのメモリ内で実行され、デバイスのファイルシステムでは実行されない。その結果、セッションデータを管理する主要な機能を持つサーバーが実現する。ユーザーがウェブアプリケーションにログインすると、ウェブアプリケーションは、クライアントコンピュータのブラウザエージェントまたはＩＰアドレスがペアになっているなどの情報のためのランダムセッションキーを作成する。このような値は、データストアサーバー３０４のメモリに格納され、ネットワーク上の他のサーバーがアクセスできるようになっている。

３０５はデータベースサーバーである。データベースサーバー３０５は、テーブルまたは他の構造にデータを格納し、検索し、そして書き込む主要な機能を有するサーバーである。ネットワーク上の適切な認証を持つ他のサーバーは、このサーバーに要求を送信して、ハードドライブに格納されたデータにアクセスできる。

４０１は、ネットワーク、またはネットワーク上のサーバー間で信号を送信するために使用される物理的媒体である。

ここで図面の図２〜９を参照すると、要求の起点を確認するためにシステム９９にログインするプロセスを示す図が示される。特に、図２を参照すると、ステップ７０１において、ウェブアプリケーションのＵＲＬがウェブブラウザ１０２のアドレスバー５０１に入力される。この時点で（ステップ７０２）、ウェブブラウザ１０２は、ｈｔｔｐ要求をリバースプロキシサーバー３０１に送信し、ログイン。リバースプロキシサーバー３０１は、ログインのためのファイルを読み取り（ステップ７０３）、その後、ウェブブラウザ１０２に戻るｈｔｔｐ応答を返す（ステップ７０４）。ステップ７０４において、ウェブブラウザ１０２はｈｔｔｐ応答からログインページをレンダリングする（ステップ７０５）。

図３を参照すると、本出願のログイン画面が示されている。ログイン画面は、２つの入力、すなわちユーザー名５０２とパスワード５０３の２つの入力が提出ボタン５０４と共に存在する共通の設計に従う。本出願は、記載されたログイン画面の設計には何も主張していない。それら画面は、どのユーザーがアプリケーションへのアクセスを要求しているかを確立するために提供され、前記ユーザーは、アプリケーションに認証されるべきパスワードのような何らかの形のデジタル署名を必要とする。このようなフォームには、ユーザーがサーバーによって検証されるように詳細を入力したことを示すために使用される送信ボタン５０４も含まれる。

図４を参照すると、一連のステップが実行される。ステップ７０６で、意図されたユーザー名とパスワード（ユーザー識別データ）がそれぞれユーザー名５０２とパスワード５０３の入力フィールドに入力され、送信ボタン５０４がクリックされる。ステップ７０７で、ウェブブラウザ１０２は、リクエストの本体に含まれるユーザー名フィールド５０２とパスワードフィールド５０３に入力されたユーザー名とパスワードを用いて、リバースプロキシサーバー３０１にＰＯＳＴリクエストを送信する。リバースプロキシサーバー３０１は、ウェブブラウザ１０２から提供されたユーザー名とパスワードを検索するために、ステップ／リクエスト７０７からＰＯＳＴデータを解析する（ステップ７０８）。リバースプロキシサーバー３０１は、データベースサーバー３０５にリクエストを送る（ステップ７０９）。ウェブクライアントから提供されたユーザー名を持つユーザーを照会するには、データベース内のすべてのユーザーと照合する。

このとき、データベースサーバー３０５は、ユーザー名の問い合わせを実行する（ステップ７１０）。データベースサーバー３０５は、ユーザー名クエリの結果をリバースプロキシサーバー３０１に返す（ステップ７１１参照）。ステップ７１２で、リバースプロキシ３０１は、データベースサーバー３０５によって提供される結果の数をチェックする。データベースにマッチがない場合、リバースプロキシサーバー３０１は、認証を停止する。リバースプロキシサーバー３０１は、ウェブブラウザ１０２によって提供されたデジタル署名の完全性をチェックする（ステップ７１３）。殆どの場合、この操作はデータベースサーバー３０５に格納されたハッシュに対して一連の文字または数字をチェックすることを中心に実行される。

図５を参照すると、一連のステップが実行される。ステップ７１４において、リバースプロキシサーバー３０１は、ウェブブラウザ１０２からの後続のリクエストを識別するためのセッションキーを作成する。セッションキーは、十分にランダムであると考えられる一連の文字および数字であり、第三者によって 本出願は、たとえば「l3e6u8s48xebnk1302d」のような値を使い、この値がセッションキー・アイコンとともに使用される図を示す。たとえば、数字の吹き出し１１５で示されるキーアイコンを参照のこと。

ステップ７１５において、リバースプロキシサーバー３０１は、ウェブブラウザ１０２のセッションキー、ブラウザエージェント、および起点ＩＰアドレスをログに保存するために、クエリをデータベースサーバー３０５に送信する。これはブール代数値で実施できる。ブール代数値は、最初はｆａｌｓｅで、ユーザーがまだログアウトしていないことを示す。後で確認のために要求することが可能である。ステップ７１６において、データベースサーバー３０５は、ファイルシステムへの書き込み操作を実行する。ステップ７１７で、データベースサーバー３０５は、リバースプロキシサーバー３０１に確認応答を返す。この時点で、リバースプロキシサーバー３０１は、このアプリケーションが「セッション確認パッケージ」６０２と呼ぶものを作成する（ステップ７１８参照）。セッション確認パッケージ６０２は、ＪＳＯＮまたはＸＭＬまたは同様のフォーマットのようなデータ構造であり、ステップ７１４からのウェブブラウザ１０２、ウェブブラウザのブラウザエージェント、およびセッションキー１１５の起点ＩＰアドレスを格納し、ストリングを作成する後で解析が可能である。セッション確認パッケージのＪＳＯＮの例を以下に示す。
```
`{
“ip_address” : “104.131.30.5”,
“session_key” : “l3e6u8s48xebnk1302d”,
“browser_agent” : “Mozilla/5.0 (Windows NT x.y; rv:10.0) Gecko/20100101 Firefox/10.0”
}`
```

ステップ７１９において、リバースプロキシサーバー３０１は、リバースプロキシサーバー３０１に格納されている共通キー６０４でセッション確認パッケージ６０２を暗号化し、暗号化確認パッケージ６０３を作成する。 たとえば、キー：37586153414011199397で暗号化されたステップ７１８のＪＳＯＮテキストの例は、以下のテキストの結果になる。
```
B65A75841793DD4612D9CB3B1F8E1B5048B2A59144E11F10D3B13AC2CDE1CBFD
F317A4F9004D1CCBC6BFE47D758E85B011667741E4D31E35AE12154F69A491A8
2DB119001D4762C8D78BCB005B770379B82D1B6BC91DE27C019057BE3473B8E5
0BDEDC139BC754783E89284EA1636D9E4C799AE7656755528C4A7D752EFBE1CA
F390F2848F21CA4938C4DF2501B1975D9C2A362B45702858E3974F385E4CB4CB
D19712A8DB471C02
```

ステップ７２０では、セッションキー６０１、および暗号化確認パッケージ６０３がウェブブラウザ１０２へのリダイレクト応答で返される。リダイレクト応答は、リバースプロキシサーバー３０１が有効なデジタル署名で認証されたことを示し、サーバーからのアプリケーションウェブブラウザ１０２は、セッションキー６０１と暗号化セッション確認パッケージ６０３をパーソナルコンピュータ１０１のファイルシステム１０３に保存する（ステップ７２１参照）。

ここで図面の図６を参照すると、一連のステップが実行される。ステップ７２２において、ウェブブラウザ１０２は、リバースプロキシサーバー３０１からのリダイレクト応答を認識し、それに応じてアドレスバー５０１を変更して、意図された位置の変化を示す。その後、ウェブブラウザ１０２は、ウェブアプリケーションを実行するために必要なファイルについてリバースプロキシサーバー３０１に要求（ステップ７２３）を送信する。セッションキー６０１と暗号化セッション確認パッケージ６０３がリクエストに含まれる。

ステップ７２４において、リバースプロキシサーバー３０１は、元のセッション確認パッケージ６０２を取り出すためにサーバー上に記憶された対称キー６０４を用いてセッション確認パッケージ６０３を暗号化する。リバースプロキシサーバー３０１は、アドレスの発信元ＩＰが、セッション確認パッケージ６０２に含まれるＩＰアドレスの発信元ＩＰと一致し、ブラウザエージェントが現在の要求のものと一致することを確認し、要求は、セッション確認パッケージ６０３内のものと一致する。これら３つの値のいずれかが異なる場合、逆プロキシサーバー３０１はエラー応答を返す。

リバースプロキシサーバー３０１は、その要求をアプリケーションサーバー３０３に転送する（ステップ７２５）。アプリケーションサーバー３０３は、要求されたファイルをサーバーのファイルシステムから読み出し（ステップ７２６）、リバースプロキシサーバー３０１への応答のファイルを返す（ステップ７２７）。次に、ステップ７２８において、リバースプロキシサーバー３０１は、ウェブブラウザ１０２への応答のファイルを返す。

図７を参照すると、一連のステップが実行される。ステップ７２９で、ウェブブラウザ１０２は、アプリケーションサーバー３０３から提供されたアプリケーション情報のファイルを解析しレンダリングする.１０２ウェブブラウザがファイルのレンダリングを終了して画面上に要素を表示すると（ステップ７３０）、ウェブブラウザ１０２はアプリケーションサーバー３０３によって提供されるスクリプトファイルを実行する。スクリプトが解析されて実行され始めると、ウェブブラウザ１０２はウェブソケット接続要求をリバースプロキシサーバー３０１に送信するよう指示される。

ウェブブラウザ１０２は、リバースプロキシサーバー３０１にウェブソケット接続要求を送信することに進む（ステップ７３１）。要求のｈｅａｄｅｒには、要求のｈｅａｄｅｒにあるセッションキー６０１と暗号化セッション確認パッケージ６０３が含まれる。ステップ７３２において、リバースプロキシサーバー３０１は、元のセッション確認パッケージ６０２を取り出すためにサーバー上に記憶された対称キー６０４を用いて暗号化セッション確認パッケージ６０３を暗号化する。リバースプロキシサーバー３０１は、アドレスの発信元ＩＰが、セッション確認パッケージ６０２に含まれるＩＰアドレスの発信元ＩＰと一致し、ブラウザエージェントが現在の要求のものと一致することを確認し、要求は、セッション確認パッケージ６０２内のものと一致する。これら３つの値のいずれかが異なる場合、逆プロキシサーバー３０１はエラー応答を返す。

次に、リバースプロキシサーバー３０１は、ウェブソケットサーバー３０２にリクエストを転送する（ステップ７３３）。ステップ７３４において、ウェブソケットサーバー３０２は、リクエストからセッションキー６０１を分離する。その後、ウェブソケットサーバー３０２は、セッションキー６０１がログアウトされたかどうかを確認するために、データベースサーバー３０５へのクエリを準備する。その後、データベースサーバー３０５はクエリを実行する（ステップ７３５）。データベースサーバー３０５は、クエリの結果を返す（ステップ７３６）。ステップ７３７において、ウェブソケットサーバー３０２は、セッションキー６０１がログアウトされていないことを確認する。現在の要求の起点およびブラウザエージェントのＩＰアドレスを、ステップ７１６でデータベースサーバーに格納されているものとともに現在の要求の二次照合のために二重にチェックする。

ここで図８を参照すると、一連のステップが実行される。ステップ７３８において、ウェブソケットサーバー３０２は、セッション検証キー６０５を生成する。セッション検証キー６０５は、元のセッションキー６０１と同様の構造である。それは第三者によって容易に偽造されないように、一連の文字と十分にランダムな数である。本出願は、個のセッション検証キー６０５に対して「VnpGSMNZEa3phHZEtNN3」のサンプル値を使用する。ステップ７３９において、ウェブソケットサーバー３０２は、セッションキー６０１、セッション検証キー６０５、ウェブブラウザ１０２のＩＰアドレス、ウェブブラウザ１０２のブラウザエージェントを保存する要求をデータストアサーバー３０４に送信する。

ステップ７４０において、データストアサーバー３０４は、ウェブソケットサーバー３０２から提供された情報をメモリに保存する。データストアは、セッションキー６０１をキーとして使用し、他の情報を値として提供する。セッションキー６０１がデータストアサーバー３０４に照会される場合と比べて、サーバーは以下の例示的な値を返す。
```
`{
“ip_address” : “104.131.30.5”,
“session_verification_key” : “VnpGSMNZEa3phHZEtNN3”,
“browser_agent” : “Mozilla/5.0 (Windows NT x.y; rv:10.0) Gecko/20100101 Firefox/10.0”
}`
```

ステップ７４１において、データストアサーバー３０４は、確認応答をウェブソケットサーバー３０２に返す。ステップ７４２において、ウェブソケットサーバー３０２は、現在確立されているウェブソケット接続のすべてを反復し、セッション検証キー６０５を一致するセッションキー６０１と接続する。ウェブブラウザ１０２からの現在のウェブソケット要求が、現在確立されているウェブソケット接続のリストに追加される（ステップ７４３）。一致するセッションがステップ７４２で検出されない場合、ウェブソケットサーバー３０２はセッション検証キー６０５をリバースプロキシサーバー３０１に送信してウェブブラウザ１０２に転送する（ステップ７４４）。次いで、リバースプロキシサーバー３０１は、セッション検証キー６０５をウェブブラウザ１０２に転送する（ステップ７４５）。ウェブブラウザ１０２は、セッション検証キー６０５をファイルシステム１０３に格納する（ステップ７４６）。

ここで図面の図９を参照すると、さらなる一連のステップが実行される。ステップ７４７において、ウェブブラウザ１０２がセッション検証キー６０５を受信すると、データベース関連要求をアプリケーションサーバー３０３に送信することが許可される。たとえば、データベースから値のセットを取得し、データベースにアクセスする必要があり、またこれはユーザーを認可するためにそれが必要となる。ウェブブラウザ１０２は、アプリケーションによって要求される情報についてアプリケーションサーバー３０３に要求を送信する。

ステップ７４８において、リバースプロキシサーバー３０１は、元のセッション確認パッケージ６０２を取り出すためにサーバー上に記憶された対称キー６０４を用いて暗号化セッション確認パッケージ６０３を暗号化する。リバースプロキシサーバー３０１は、アドレスの発信元ＩＰが、セッション確認パッケージ６０２に含まれるＩＰアドレスの発信元ＩＰと一致し、ブラウザエージェントが現在の要求のものと一致することを確認し、要求は、セッション確認パッケージ６０２内のものと一致する。これら３つの値のいずれかが異なる場合、リバースプロキシサーバー３０１はエラー応答を返す。

ステップ７４９において、リバースプロキシサーバー３０１は、要求をアプリケーションサーバー３０３に転送し、アプリケーションサーバー３０３は、リクエストからセッションキー６０１を分離する（ステップ７５０）。データストアサーバー３０４に、 そこにセッションキー６０１が格納されている。データストアサーバー３０４は、ステップ７４０で格納された検索要求を実行する（ステップ７５１）。データストアサーバー３０４は、セッションキー６０１に関連するデータを返す（ステップ７５２）。ステップ７５３において、アプリケーションサーバー３０３は、データストアサーバー３０４から検索された情報を用いて現在の要求をチェックする。これらの値のいずれかがＩＰアドレス、セッション検証キー６０５、または存在しない場合、データストアサーバー３０４では、アプリケーションサーバー３０３はエラー応答を返す。

ステップ７５４で、アプリケーションサーバー３０３は、ステップ７４７で実行されたようにウェブブラウザ１０２によって要求されたデータを検索するためのデータベースクエリを準備し、データベースサーバー３０５に要求を送信する。データベースサーバー３０５は、アプリケーションサーバー３０３に送信する（ステップ７５５）。データベースサーバー３０５は、クエリの結果をアプリケーションサーバー３０３に返す（ステップ７５６）。アプリケーションサーバー３０３は、データベースサーバー３０５から返された結果を解析する（ステップ７５７）。アプリケーションサーバー３０３は、リバースプロキシサーバー３０１に応答を返す（ステップ７５８）。リバースプロキシサーバー３０１は、ウェブブラウザ１０２に応答を返す（ステップ７５９）。

ここで図面の図１０〜１３を参照すると、システム９９からログアウトするプロセスを示す図が示される。図１０に示すように、ステップ７４７からウェブブラウザ１０２によって要求されたｈｔｔｐ要求の結果が画面に表示される。この状態では、ウェブブラウザ１０２は認証されたと見なされ、ステップ７４７〜７５９（ステップ７６０参照）を繰り返すことによって、アプリケーションサーバー３０３に追加の要求を行うことができる。

図１０には、セッションが終了するプロセスが示される。ユーザーは、アプリケーション内から「ログアウト」ボタン５０５をクリックする（ステップ７６１）。ウェブブラウザ１０２は、ウェブセッションサーバー３０２にセッションを終了する要求を送信する（ステップ７６２）。ステップ７６３において、リバースプロキシサーバー３０１は、元のセッション確認パッケージ６０２を取り出すためにサーバー上に記憶された対称キー６０４を用いて暗号化セッション確認パッケージ６０３を暗号化する。リバースプロキシサーバー３０１は、アドレスの発信元ＩＰが、セッション確認パッケージ６０２に含まれるＩＰアドレスの発信元ＩＰと一致し、ブラウザエージェントが現在の要求のものと一致することを確認し、要求は、セッション確認パッケージ６０２内のものと一致する。これら３つの値のいずれかが異なる場合、リバースプロキシサーバー３０１はエラー応答を返す。 次いで、リバースプロキシサーバー３０１は、要求をウェブソケットサーバー３０２に転送する（ステップ７６４）。この時点で、ウェブソケットサーバー３０２は、セッションキー６０１を要求ｈｅａｄｅｒから隔離する（ステップ７６５）。ウェブソケットサーバー３０２は、６０１セッションキーに関連する任意のデータを除去する要求をデータストアサーバー３０４に送信する（ステップ７６６）。データストアサーバー３０４は、セッションキー６０１に関連するデータをすべて削除する（ステップ７６７）。データストアサーバー３０４は、ウェブソケットサーバー３０２に確認を返す（ステップ７６８）。

ステップ７６９で、ウェブソケットサーバー３０２は、ステップ７３７において、６０１セッションキーを使用するための追加の要求が拒否されるように、セッション終了時間を記録する要求をデータベースサーバー３０５に送信する。データベースサーバー３０５は、クエリ（ステップ７７０）。データベースサーバー３０５は、確認応答をウェブソケットサーバー３０２に返す（ステップ７７１）。

図１２において、ウェブソケットサーバー３０３は、接続されたウェブソケットのリストを同じセッションキー６０１で繰り返し、接続を閉じる（ステップ７７２）。ウェブソケットサーバー３０２は、リバースプロキシサーバー３０１にクローズソケット応答を送信する（ステップ７７３）。リバースプロキシサーバー３０１は、クローズソケット応答をウェブソケットサーバー３０２に転送する（ステップ７７４）。ウェブブラウザ１０２は、ウェブソケット接続クローズイベントを認識する（ステップ７７５）。

図１３に見られるように、ウェブソケットサーバー３０２とのウェブソケット接続が閉じられると、アプリケーション内のスクリプトはウェブブラウザ１０２にＵＲＬロケーションを変更して、リバースプロキシサーバー３０１からのＣｏｏｋｉｅの削除を要求するよう指示する（ステップ７７６）。ステップ７７７において、ウェブブラウザ１０２は、リクエストのｈｅａｄｅｒに６０１セッションキー、暗号化セッション確認パッケージ６０３及びセッション確認キー６０５を有するＨＴＴＰリクエストをリバースプロキシサーバー３０１に送信する。ステップ７７８で、リバースプロキシサーバー３０１は、ウェブブラウザ１０２への応答を準備して、セッションキー６０１、暗号化セッション確認パッケージ６０３およびセッション検証キー６０５をパーソナルコンピュータ１０１のファイルストレージ１０３から削除し、ウェブブラウザ１０２への応答を行う（ステップ７７９）。ウェブブラウザ１０２は、パーソナルコンピュータ１０１のファイルストレージ１０３からセッションキー６０１、暗号化セッション確認パッケージ６０３およびセッション検証キー６０５を削除する（ステップ７８０）。

ここで図面の図１４〜１６を参照すると、複数のセッションおよび複数の接続を有するシステム９９の例示的な動作を示す図が示されている。より具体的には、図１４、１５および１６は、セッション検証キー６０５の機能の明確化と、単一のウェブクライアントからの複数の接続から複数のセッションを許可する方法を提供するが、複数のホストまたは複数のウェブクライアントからは可能でない。図１４は、セッション検証キー６０５を有する単一のコンピュータを認証するプロセスを示す。ここでの議論の目的のために、リバースプロキシサーバー３０１、ウェブソケットサーバー３０２、アプリケーションサーバー３０３、データストアサーバー３０４およびデータベースサーバー３０５、およびネットワーク４０１は一緒にグループ化され、単一のエンドポイント８０１と呼ばれる。ステップ７３１本アプリケーションでは、ウェブブラウザ１０２は、セッションキー６０１および暗号化セッション確認パッケージ６０３をエンドポイント８０１に送り、エンドポイント８０１は、現在の要求を有す唯一のウェブクライアントであるセッション検証キー６０５をウェブブラウザ１０２に返す。

図１５に、本発明による同じコンピュータ上の別のブラウザタブを開く動作を示す。この図は、説明のために同じパーソナルコンピュータ１０１を２台のコンピュータとして描いている。左タブ５０６は、図１３に示すウェブブラウザ１０２タブである。新しいタブ５０７が開かれると、ページ内のスクリプトは、本アプリケーションのステップ７３１で説明したように、エンドポイント８０１内のウェブソケットサーバー３０２に接続を試みる。

本アプリケーションのステップ７４２において、ウェブソケットサーバー３０２は、新しいセッション検証キー６０６を生成し、一致するセッションキー６０１を有する任意のクライアントに送信する。クライアントが存在する場合、ウェブソケットサーバー３０２は、要求を送信したウェブブラウザ１０２クライアントには、新しいセッション検証キー６０６を送信しない。

ステップ７４２において、エンドポイント８０１内のウェブソケットサーバー３０３は、既存の接続に新しいセッション検証キー６０６を送信する。元のタブ５０６と新しいタブ５０７は同じウェブブラウザ１０２上の同じ１０３のファイルシステムを共有するので、これは両方のタブが新しいセッション検証キー６０６で更新され、エンドポイント８０１内のアプリケーションサーバー３０３に関連するリクエストを送信する。

図１６は、セッション確認キーの管理が他のコンピュータがセッションの乗っ取りをいかに防ぐかを示している。この図には、前の図１５と同じタブ（５０６および５０７）が示されるが、全く新しいパーソナルコンピュータ１５１とウェブブラウザ１５２が追加されている。パーソナルコンピュータ１５１は、セッションキー６０１、暗号化セッション検証パッケージ６０３およびセッション検証キー６０５を得ることができた第三者のものであり、パーソナルコンピュータ１０１と同じネットワーク上にある。

前の図と同様に、ウェブブラウザ１５２は、本願のステップ７３１のウエブソケット・コネクションと同様にウエブソケット・コネクションを開始しようと試みる。ＩＰｖ６ネットワークの場合、この要求は、パーソナルコンピュータ１５１のＩＰアドレスがパーソナルコンピュータ１０１のＩＰアドレスと異なるため、本アプリケーションのステップ７３２で失敗する。しかし、ＩＰｖ４ネットワーク上では、これらのデバイスの両方とも同一のものとして認識される。

しかし、この場合、ウェブソケットサーバーは、本アプリケーションのステップ７４２に見られるように、新しいセッション検証キー６０６を生成し、それを既存の接続に送信し、データストアサーバー３０４内の関連データを更新して変更を反映する。パーソナルコンピュータ１５１とパーソナルコンピュータ１０１とが同じファイルシステムを共有しないため、これにより、ウェブブラウザ１５２は、アプリケーションサーバー３０３に要求を行う際に有効期限切れのセッション検証キー６０５で行うことになり、本出願のステップ７５３に示すようにサーバーへの要求は終了する。

図１７を参照すると、ユーザーがアプリケーション内からログアウトしないがウェブブラウザ１０２自体を閉じるときにセッションが終了するプロセスが示されている。ステップ７８１で、閉じるブラウザボタン５０８がクリックされる。そして、ウェブブラウザ１０２が終了する。この時点で、ウェブブラウザ１０２は、サーバーが閉じるとウェブサーバー切断イベントをサーバーに送信する（ステップ７８２）。ステップ７８３から、リバースプロキシサーバー３０１は、元のセッション確認パッケージ６０２を取り出すためにサーバー上に記憶された対称キー６０４でセッション確認パッケージ６０３を暗号化する。リバースプロキシサーバー３０１は、アドレスの発信元ＩＰが、セッション確認パッケージ６０２に含まれるＩＰアドレスの発信元ＩＰと一致し、ブラウザエージェントが現在の要求のものと一致することを確認し、要求は、セッション確認パッケージ６０２内のものと一致する。これら３つの値のいずれかが異なる場合、リバースプロキシサーバー３０１はエラー応答を返す。リバースプロキシサーバー３０１は、クローズソケットイベントをウェブソケットサーバー３０２に転送する（ステップ７８４）。ウェブソケットサーバー３０２は、要求によりセッションキー６０１を隔離する（ステップ７８５）。

ステップ７８６において、ウェブソケットサーバー３０２は、現在アクティブなソケット接続のリストを反復して、現在の切断された接続が所定のセッションキー６０１に対する最後の接続であるかどうかをチェックする。ステップ７８７で、切断されたウェブソケットが実際に関連するセッションキー６０１に最後に接続されている場合、ウェブソケットサーバー３０２は、セッションキー６０１に関する任意の関連データを削除するようにデータストアサーバー３０４に要求する。データストアサーバー３０４は、削除要求を実行する（ステップ７８８）。データストアサーバー３０４は、ウェブソケットサーバー３０２に確認要求を返す（ステップ７８９）。

この技術は、ネットワークを介して情報の配布を保証するために、検証の目的で二重の保護層を提供する能力を少なくとも含む以前の先行技術に対して多くの利点を有する。

本明細書の中で用いられる符号の説明は、以下の通りである：
１０１・・・パーソナルコンピュータ
１０２・・・ブラウザ
１０３・・・ファイルシステム
２０１・・・インターネット
３０１・・・リバースプロキシサーバー
３０２・・・ウェブソケットサーバー
３０３・・・アプリケーションサーバー
３０４・・・データストアサーバー
３０５・・・データベースサーバー
４０１・・・内部ネットワーク
５０１・・・アドレスバー
５０２・・・ユーザー名入力フィールド
５０３・・・パスワード入力フィールド
５０４・・・フォーム提出フィールド
５０５・・・ログアウトボタン
５０６・・・左タブ
５０７・・・右タブ
５０８・・・閉じるボタン
６０１・・・セッションキー
６０２・・・セッション確認パッケージ
６０３・・・暗号化されたセッション確認パッケージ
６０４・・・対称キー
６０５・・・セッション確認キー
６０６・・・新しいセッション確認キー

上述した特定の実施形態は例示的なものに過ぎず、具体化によって恩恵をこうむる事業者には明らかであるが、開示された厳密な形態のみに本発明を限定するものではない。したがって、上に開示された特定の実施形態は、変更または修正されてもよく、そのような変形形態はすべて、本出願の範囲および趣旨内にあると考えられることは明らかである。 従って、本明細書で求められる保護の範囲は、明細書に記載されている通りである。重要な利点を有するアプリケーションが説明され図示されていることは明らかである。本願は限られた数の形態で示されているが、これらの形態に限定されるものではなく、その精神から逸脱することなく様々な変更および改変が可能である。

Claims (15)

1. ネットワーク経由の要求の起点(の正当性)を検証するために、下記を有するシステム。
   ネットワークを介してデータを検索し、処理し、送信するために構成されたプロセッサ、メモリ記憶装置、入力／出力インタフェースと、を有するパーソナル電子装置と、
   ネットワークを介して前記パーソナル電子装置と通信する１つまたは複数のデータベースと、
   ネットワークを介してパーソナル電子デバイスと通信する１台または複数台のサーバーであって、前記１つまたは複数のデータベースとの間で情報の送信を制御し、継続して利用するユーザーを特定するために、一意的なセッションＩＤを生成する１台または複数台のサーバーと、
   ＩＰアドレス、セッションＩＤ、およびブラウザエージェント、１つまたは複数のデータベース上のファイルへのアクセスを制限するために構成された１台または複数のサーバーによって生成され、ネットワークを介して1台または複数のサーバーと、１つまたは複数のデータベースへの継続的なアクセスを保証する一意性を識別するセッション確認パッケージ。
2. 前記の一意性を識別するセッション確認パッケージは暗号化されていることを特徴とする請求項１に記載のシステム。
3. 前記の一意性を識別するセッション確認パッケージが前記１つ以上のサーバーに格納される、請求項１に記載のシステム。
4. 前記の一意性を識別するセッション確認パッケージが前記パーソナル電子装置に送信される、請求項１に記載のシステム。
5. 前記サーバー上の情報へのアクセスが、前記セッションＩＤおよび前記一意性を識別するセッション確認パッケージの検証を必要とする、請求項１に記載のシステム。
6. 前記１つまたは複数のサーバーおよび１つまたは複数のデータベースは、セッション検証を生成するように構成されている、請求項１に記載のシステム
7. 前記１つまたは複数のサーバーは、前記セッションＩＤおよび前記一意性を識別するセッション確認パッケージの検証に基づいてセッション検証キーを生成するように構成されている、請求項１に記載のシステム。
8. 前記セッション検証キーは、前記ネットワーク内で、前記セッション確認パッケージおよび前記セッションＩＤの後に生成される、請求項7に記載のシステム。
9. ネットワークを介してサーバー、データベース、およびパーソナル電子デバイスを有するリクエストの起点を検証する方法であって、
   前記個人電子装置から前記サーバーにユーザー識別データを送信するステップと、
   前記サーバーと前記データベースとの間で前記ユーザー識別データを認証し、前記個人電子デバイスに認証を返送するステップと、
   前記ネットワーク上のコンピュータセッションを識別するために前記サーバー上にセッションＩＤを作成するステップと、
   前記ＩＰアドレスに関連するデータと、
   前記パーソナル電子デバイスによって使用されるブラウザエージェントと、
   前記セッションＩＤと、を含むセッション確認パッケージを形成するステップと、
   セッション確認パッケージを一意のサーバーキーから暗号化するステップと、
   そしてセッションＩＤおよびセッション確認パッケージをパーソナル電子デバイスに返すステップと、
   前記ユーザーおよび個人用電子機器の識別は、セッションＩＤおよびセッション確認パッケージが特定のＩＰアドレスと一致することを検証することと、
   セッションＩＤがセッション確認パッケージ内のセッションＩＤと一致することを検証することとを含む。
10. 請求項９に記載の方法であって、
    特定のユーザーおよびパーソナル電子デバイスを識別するために使用されるセッション検証鍵を生成する。
11. 前記セッション検証キーは、前記ネットワーク内で、前記セッション確認パッケージおよび前記セッションＩＤの後に生成される、請求項１０に記載の方法。
12. 前記セッション検証キーは、前記パーソナル電子デバイスが前記ネットワークを介して前記サーバーにアクセスするときに生成される、請求項１０に記載の方法。
13. 前記セッション検証キーは、前記ネットワーク上の前記個人用電子デバイスのアクセス時に更新されることを特徴とする請求項１０に記載の方法。
14. セッション検証鍵は、第三者の電子デバイスが、セッションＩＤ、セッション確認パッケージ、およびセッション検証キーを使用してネットワークを介して情報にアクセスしようとしたときに、既にネットワーク上に存在する既存のパーソナル電子デバイス上で更新される請求項１３に記載の方法。
15. 前記第三者の電子デバイスは、古いセッション検証キーを保持する、請求項１４に記載の方法。

Images