セッション管理装置
【課題】正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、セッションハイジャックの危険性を低減する。
【解決手段】ネットワーク１０１を介してＷｅｂクライアント１０３ａ〜１０３ｃと接続されたＷｅｂサーバ１０２には、セッション管理部２０４が設けられ、セッション管理部２０４は、Ｗｅｂクライアント１０３とＷｅｂサーバ１０２との間で受け渡されるセッションＩＤをＷｅｂクライアント１０３からのアクセスの度に採番し、Ｗｅｂクライアント１０３ａ〜１０３からの一連のアクセスをＷｅｂサーバ１０２側で管理する管理ＩＤをセッションＩＤに付与し、同一の管理ＩＤが付与された互いに異なる複数のセッションＩＤを同時刻に有効にする。
【解決手段】ネットワーク１０１を介してＷｅｂクライアント１０３ａ〜１０３ｃと接続されたＷｅｂサーバ１０２には、セッション管理部２０４が設けられ、セッション管理部２０４は、Ｗｅｂクライアント１０３とＷｅｂサーバ１０２との間で受け渡されるセッションＩＤをＷｅｂクライアント１０３からのアクセスの度に採番し、Ｗｅｂクライアント１０３ａ〜１０３からの一連のアクセスをＷｅｂサーバ１０２側で管理する管理ＩＤをセッションＩＤに付与し、同一の管理ＩＤが付与された互いに異なる複数のセッションＩＤを同時刻に有効にする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はセッション管理装置に関し、特に、Ｗｅｂアプリケーションなどで使用されるセッションＩＤを詐称した「なりすまし」を防止する方法に適用して好適なものである。
【背景技術】
【０００２】
近年のインターネットの普及に伴って、電子申請やオンラインショッピングを始めとした様々な手続きや業務が電子化されている。この電子化にあたっては、パーソナルコンピュータに標準搭載されているＷｅｂブラウザをクライアントソフトとし、オンラインショッピングに代表されるＷｅｂアプリケーションを構築することが盛んに行われている。
このＷｅｂアプリケーションの構築に当たっては、ＨＴＴＰというプロトコルが通常用いられる。このＨＴＴＰというプロトコルはステートレスなプロトコルであり、一回のリクエストとレスポンスにより処理が完結する仕組みが採用され、リクエストとレスポンスのやり取りを複数回にわたって管理するためのセッションという概念が備わっていない。オンラインショッピングに代表されるＷｅｂアプリケーションでは、ユーザを識別したり、ユーザが入力した内容を記憶したりする必要があるが、ＨＴＴＰというプロトコルが用いられているため、セッションを管理することができない。
【０００３】
この問題の解決策として、クライアントとサーバ間でのやりとりの際にセッションＩＤと呼ばれるセッションを識別するための識別子の受け渡しを行うことが広く行われている。
具体的には、ある段階でサーバがセッションＩＤを採番し、ＨＴＴＰレスポンス中に含めて受け渡す。クライアントは、その後のリクエスト時に受け取ったセッションＩＤをサーバに送る。サーバは、受け取ったセッションＩＤを確認してセッションを特定する。
【０００４】
この方法では、セッションＩＤが第三者に知られると、俗に言う「なりすまし」による不正アクセスが実行される危険性がある。すなわち、セッションＩＤの受け渡しは、Ｃｏｏｋｉｅと呼ばれる仕組みやＵＲＬの一部分を利用する仕組み、Ｈｉｄｄｅｎパラメータを利用する仕組みなどが一般に知られているが、どの手法においても、通信路の盗聴などにより、セッションＩＤが第三者に知られてしまう危険性がある。
【０００５】
このような第三者が略取したセッションＩＤを使用して不正なアクセスを行う行為はセッションハイジャックと呼ばれ、Ｗｅｂアプリケーションに対するセキュリティ上の脅威として問題視されており、セッションＩＤの有効期限を設定するという対抗策が考えられている。
また、特許文献１には、Ｗｅｂシステムにおけるセッション管理に関して、セッションハイジャックの危険性を低減するために、Ｗｅｂクライアントからのアクセス毎に当該Ｗｅｂクライアントとの間のセッションＩＤの更新登録を行う方法が開示されている。
【０００６】
図８は、従来のセッション管理処理の流れの一例を示すシーケンス図である。
図８において、Ｗｅｂクライアント１３上には表示画面１３ａが設けられ、表示画面１３ａにはＷｅｂアプリケーションに応じたログイン画面が表示される。そして、ログイン画面上でユーザＩＤやパスワードが入力され、ログインボタンが押下されると、Ｗｅｂクライアント１３からＷｅｂサーバ１２に認証情報が送信される（ステップＳ６０１）。そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から認証情報を受信すると、アカウントデータベース１４を参照することで、Ｗｅｂクライアント１３を認証する（ステップＳ６０２）。そして、Ｗｅｂクライアント１３が認証されると、Ｗｅｂサーバ１２は、セッションＩＤ１を採番し（ステップＳ６０３）、セッションデータベース１５に新規登録するとともに（ステップＳ６０４）、ＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ１をＷｅｂクライアント１３に受け渡すことで（ステップＳ６０５）、Ｗｅｂクライアント１３はフレーム構造のみ取得する。
【０００７】
ここで、ログイン後の表示画面１３ａがフレーム１、２によって複数の画面から構成される場合、フレーム１、２にアクセスするための複数のリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ６０６、Ｓ６１０）。
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３からフレーム１にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ６０７）。そして、セッションＩＤ１の確認がとれると、Ｗｅｂサーバ１２は、セッションＩＤ２を採番し（ステップＳ６０８）、セッションＩＤ１をセッションデータベース１５から削除するとともに、セッションＩＤ２をセッションデータベース１５に更新登録する（ステップＳ６０９）。そして、Ｗｅｂサーバ１２は、フレーム１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ２をＷｅｂクライアント１３に受け渡すことで（ステップＳ６１１）、表示画面１３ａ上にフレーム１の正常な内容が表示される。
【０００８】
また、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３からフレーム２にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ６１２）。ここで、セッションデータベース１５上ではセッションＩＤ１が既に削除され、セッションＩＤ１の確認がとれないため、フレーム２に対応したＨＴＴＰレスポンスとしてエラーがＷｅｂクライアント１３に返され（ステップＳ６１３）、表示画面１３ａ上にフレーム２のエラーの内容が表示される。
【０００９】
図９は、従来のセッション管理処理の流れのその他の例を示すシーケンス図である。
図９において、ログイン画面上でユーザＩＤやパスワードが入力され、ログインボタンが押下されると、Ｗｅｂクライアント１３からＷｅｂサーバ１２に認証情報が送信される（ステップＳ７０１）。そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から認証情報を受信すると、アカウントデータベース１４を参照することで、Ｗｅｂクライアント１３を認証する（ステップＳ７０２）。そして、Ｗｅｂクライアント１３が認証されると、Ｗｅｂサーバ１２は、セッションＩＤ１を採番し（ステップＳ７０３）、セッションデータベース１５に新規登録するとともに（ステップＳ７０４）、ＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ１をＷｅｂクライアント１３に受け渡すことで（ステップＳ７０５）、Ｗｅｂクライアント１３はメニュー画面を取得する。
【００１０】
ここで、メニュー画面には複数の画面１、２へのリンクが含まれ、メニュー画面上で画面１へのリンクが押下された場合、画面１にアクセスするためのリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ７０６）。
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から画面１にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ７０７）。そして、セッションＩＤ１の確認がとれると、Ｗｅｂサーバ１２は、セッションＩＤ２を採番し（ステップＳ７０８）、セッションＩＤ１をセッションデータベース１５から削除するとともに、セッションＩＤ２をセッションデータベース１５に更新登録する（ステップＳ７０９）。
【００１１】
そして、Ｗｅｂサーバ１２は、画面１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ２をＷｅｂクライアント１３に受け渡す（ステップＳ７１１）。ここで、Ｗｅｂサーバ１２による処理中に画面２へのリンクが押下された場合、ブラウザは画面１への接続を既に廃棄しているため、画面１への接続が無効化される。
また、画面２へのリンクが押下されると、画面２にアクセスするためのリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ７１０）。
【００１２】
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から画面２にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ７１２）。ここで、セッションデータベース１５上ではセッションＩＤ１が既に削除され、セッションＩＤ１の確認がとれないため、画面２に対応したＨＴＴＰレスポンスとしてエラーがＷｅｂクライアント１３に返され（ステップＳ７１３）、表示画面１３ａ上にエラーの内容が表示される。
【特許文献１】特開２００６−３４４１３７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、セッションＩＤの有効期限を設定する方法では、有効期限が短かすぎれば、ユーザの利便性が低下し、有効期限が長すぎると、セッションハイジャックへの防止効果が低下するという問題があった。加えて、セッションＩＤの有効期限を設定する方法では、最後のアクセスから有効期限内に操作されなかった場合にセッションＩＤが無効化され、ユーザがＷｅｂアプリケーションを利用し続けている間はセッションＩＤは有効であるため、セッションハイジャックへの防止効果としてはそれほど高くない。
【００１４】
また、特許文献１に開示された手法では、図８および図９に示したように、同じセッションＩＤで複数のリクエストが送られる場合やサーバが処理中にクライアント側で別なページへ遷移するボタンが押された場合などでは、正規のユーザであるにも関わらずエラーとなるという問題があった。
そこで、本発明の目的は、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、セッションハイジャックの危険性を低減することが可能なセッション管理装置を提供することである。
【課題を解決するための手段】
【００１５】
上述した課題を解決するために、請求項１記載のセッション管理装置によれば、ＷｅｂクライアントとＷｅｂサーバとの間で受け渡されるセッションＩＤを前記Ｗｅｂクライアントからのアクセスの度に採番するセッションＩＤ採番手段と、前記Ｗｅｂクライアントからの一連のアクセスを前記Ｗｅｂサーバ側で管理する管理ＩＤを前記セッションＩＤに付与し、前記管理ＩＤを付与された前記セッションＩＤの情報に基づき、前記Ｗｅｂクライアントから受け渡されるセッションＩＤの有効・無効を確認するセッションＩＤ管理手段とを備えることを特徴とする。
【００１６】
また、請求項２記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、互いに異なる複数のセッションＩＤに同一管理ＩＤの付与を許容することを特徴とする。
また、請求項３記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセス回数を利用し、既に使用されたセッションＩＤを使用回数に基づいて任意のタイミングで無効化することを特徴とする。
【００１７】
また、請求項４記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセスからの経過時間を利用し、既に使用されたセッションＩＤをその使用後の有効時間に基づいて任意のタイミングで無効化することを特徴とする。
また、請求項５記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、あるセッションＩＤの使用後に新たに発行されたセッションＩＤの個数を利用し、既に使用されたセッションＩＤを前記セッションＩＤの世代に基づいて任意のタイミングで無効化することを特徴とする。
【発明の効果】
【００１８】
以上説明したように、本発明によれば、Ｗｅｂクライアントからのアクセスの度にセッションＩＤを採番し、互いに異なる複数のセッションＩＤが同時刻に有効になるのを許容しつつ、所定の条件下でセッションＩＤを無効化することが可能となるとともに、セッションＩＤに管理ＩＤを付与することで、Ｗｅｂクライアントからのアクセスの度にセッションＩＤを採番した場合においても、Ｗｅｂクライアントからの一連のアクセスを管理することができる。
このため、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、セッションハイジャックの危険性を低減することが可能となるとともに、リクエストとレスポンスのやり取りを複数回にわたって管理することができ、オンラインショッピングに代表されるＷｅｂアプリケーションにおけるユーザの識別処理や、ユーザによる入力データの記憶処理などを一括して管理することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施形態に係るセッション管理装置について図面を参照しながら説明する。
図１は、本発明の一実施形態に係るセッション管理装置が適用されるＷｅｂシステムの概略構成を示すブロック図である。
図１において、Ｗｅｂシステムには、Ｗｅｂサーバ１０２およびＷｅｂクライアント１０３ａ〜１０３ｃが設けられ、Ｗｅｂサーバ１０２とＷｅｂクライアント１０３ａ〜１０３ｃとはネットワーク１０１を介して接続されている。
【００２０】
なお、ネットワーク１０１としては、ＬＡＮまたはＷＡＮなどの他、インターネットなどのネットワークを用いることができる。また、Ｗｅｂサーバ１０２としては、例えば、パーソナルコンピュータを用いることができ、Ｗｅｂクライアント１０３ａ〜１０３ｃとしては、パーソナルコンピュータなどの他、携帯電話などの携帯情報端末を用いることができる。また、Ｗｅｂクライアント１０３ａ〜１０３ｃには、Ｗｅｂブラウザをクライアントソフトとして搭載し、Ｗｅｂサーバ１０２には、オンラインショッピングなどのＷｅｂアプリケーションを搭載することができる。また、Ｗｅｂサーバ１０２は、そこに搭載されるＷｅｂアプリケーションの数に応じて複数台で構成するようにしてもよい。
【００２１】
図２は、図１のＷｅｂサーバおよびＷｅｂクライアントの概略構成を示すブロック図である。
図２において、Ｗｅｂクライアント１０３ａ〜１０３ｃにはＷｅｂブラウザ２０１がそれぞれ搭載され、Ｗｅｂサーバ１０２には、Ｗｅｂサーバソフト２０２およびＷｅｂアプリケーション２０３が搭載されている。また、Ｗｅｂサーバ１０２には、セッションの管理を行うセッション管理部２０４が設けられている。なお、セッション管理部２０４は、Ｗｅｂアプリケーション２０３の一部として動作するようにしてもよい。
【００２２】
Ｗｅｂブラウザ２０１は、ＨＴＴＰやＨＴＴＰを利用するプロトコル（ＳＳＬやＴＬＳなど。以下、総称してＨＴＴＰと呼ぶ）を使用することで、ネットワーク１０１を介してＷｅｂサーバソフト２０２との間で処理要求の送信や処理結果の受信を行うことができる。
Ｗｅｂサーバソフト２０２は、Ｗｅｂブラウザ２０１より送られた処理要求をＷｅｂアプリケーション２０３に受け渡したり、Ｗｅｂアプリケーション２０３による処理結果（ＨＴＭＬ、ＸＭＬ、ＴＥＸＴのようなテキストデータや画像・動画に代表されるバイナリデータ）をＷｅｂブラウザ２０１に送信したりすることができる。
【００２３】
Ｗｅｂアプリケーション２０３は、Ｗｅｂサーバソフト２０２から受け取った処理要求を元にセッション管理部２０４と連携して一連のアクセスを識別し、所定の処理を行ってＷｅｂサーバソフト２０２に受け渡すことができる。
セッション管理部２０４は、Ｗｅｂクライアント１０３ａ〜１０３ｃとＷｅｂサーバ１０２との間で受け渡されるセッションＩＤをＷｅｂクライアント１０３ａ〜１０３ｃからのアクセスの度に採番し、Ｗｅｂクライアント１０３ａ〜１０３からの一連のアクセスをＷｅｂサーバ１０２側で管理する管理ＩＤをセッションＩＤに付与することができる。
【００２４】
そして、セッション管理部２０４は、リクエスト中にセッションＩＤが含まれていない場合に管理ＩＤ並びにセッションＩＤを採番し発行する。一方、リクエスト中にセッションＩＤが含まれている場合はアクセスの度にセッションＩＤを採番し発行する。これにより、Ｗｅｂクライアント１０３ａ〜１０３ｃは、フレームにより構成された画面やＷｅｂサーバ１０２が処理中に別なページへの遷移を行った場合の例外を除いて、各アクセスごとに異なるセッションＩＤを使用することができる。
【００２５】
また、セッション管理部２０４は、従来のセッション管理方式が行っていたようにセッションＩＤをもって一連のアクセスを識別するのではなく、セッションＩＤから管理ＩＤを特定し、管理ＩＤを持って一連のアクセスを識別することにより、間接的に一連のアクセスに紐付くセッションＩＤを同時刻において複数個有効にすることが可能となる。
これにより、従来方式のように、新しいセッションＩＤを発行した際に直ちに使用済みのセッションＩＤが無効になるのではなく、任意のタイミングでセッションＩＤを無効にすることが可能となる。
【００２６】
また、使用済みのセッションＩＤを無効化するタイミングを、当該セッションＩＤを使用したアクセス回数や当該セッションＩＤを使用したアクセスからの経過時間、当該セッションＩＤ以降に発行されたセッションＩＤ数などの値を利用して設定することが可能となる。
その結果、使用されたセッションＩＤは無効化されるが、一定期間の間は既に使用されたセッションＩＤであっても有効であるという制御が可能となり、セッションハイジャックによるなりすましの脅威を低減しつつ、正規のユーザによる正常なアクセス時には処理を継続することが可能となる。
ここで、セッション管理部２０４には、セッションＩＤと管理ＩＤとを管理するセッションテーブル３０１が設けられ、セッション管理部２０４は、一連のアクセスによってその都度採番されたセッションＩＤと管理ＩＤとを紐付けすることができる。
【００２７】
図３は、本発明の一実施形態に係るセッションテーブルを従来例と比較して示す図である。
図３（ｂ）において、従来のセッションテーブル３０２では、セッションＩＤが個別に管理される。これに対し、本実施形態のセッションテーブル３０１では、図３（ａ）に示すように、一連のアクセスによってその都度採番された複数のセッションＩＤは、同一の管理ＩＤにて一括して管理される。なお、ここでは便宜上一つの管理ＩＤに複数のセッションＩＤとして模式化して示しているが、相関関係が保たれておればよく、テーブルの構成を限定するものでは無い。
図４は、本発明の一実施形態に係るリソースマッピングを従来例と比較して示す図である。
図４（ｂ）において、従来のリソースマッピング４０２では、Ｗｅｂサーバ１０２のリソースはセッションＩＤごとに紐付けられる。これに対し、本実施形態のセッションテーブル４０１では、図４（ａ）に示すように、Ｗｅｂサーバ１０２のリソースは管理ＩＤごとに紐付けられる。
【００２８】
図５および図６は、本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
図５において、Ｗｅｂクライアント１０３ａ〜１０３ｃ（以降の説明において、Ｗｅｂクライアント１０３と記す）からＷｅｂサーバ１０２にアクセスされ（ステップＳ１０１）、そのアクセスにセッションＩＤが含まれていないものとすると、Ｗｅｂサーバ１０２は、管理ＩＤ−Ａを採番し（ステップＳ１０２）、セッションテーブル３０１に新規登録する（ステップＳ１０３）。そして、管理ＩＤ−Ａの登録後、セッションＩＤ−Ａ１を採番し（ステップＳ１０４）、セッションテーブル３０１に新規登録するとともに（ステップＳ１０５）、ＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ１をＷｅｂクライアント１０３に受け渡す（ステップＳ１０６）。なお、ここでは図示していないが、管理ＩＤを採番する度にセッションテーブル３０１にアクセスし、採番すべきＩＤを決めてもよいし、Ｗｅｂアプリケーション２０３内に管理ＩＤの採番用内部変数を保持し、これに基づき採番しても構わない。また、説明の関係上、ステップＳ６００ａでは、管理ＩＤ−Ａの登録とセッションＩＤ−Ａ１と分けているが、同時に行っても構わない。
【００２９】
ここで、Ｗｅｂクライアント１０３上の表示画面がフレーム１、２によって複数の画面から構成される場合、フレーム１、２にアクセスするための複数のリクエストがＷｅｂクライアント１０３から行われ、セッションＩＤ−Ａ１がＷｅｂサーバ１０２に受け渡される（ステップＳ２０１、Ｓ２５１）。なお、セッションＩＤ−Ａ１は、Ｗｅｂブラウザ２０１の備える機能であるＣｏｏｋｉｅの仕組みか、またはＵＲＬの一部、またはＰＯＳＴパラメータなどとして送信することができる。この時、不正クライアント５０１は、ネットワーク１０１の盗聴などにより、セッションＩＤ−Ａ１を入手することができる。
【００３０】
そして、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からフレーム１にアクセスするためのリクエストを受信すると、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認する（ステップＳ２０２）。そして、セッションＩＤ−Ａ１の確認がとれると、Ｗｅｂサーバ１０２は、セッションＩＤ−Ａ２を採番し（ステップＳ２０３）、セッションＩＤ−Ａ１をセッションテーブル３０１から削除することなく、セッションＩＤ−Ａ２をセッションテーブル３０１に登録する（ステップＳ２０４）。そして、Ｗｅｂサーバ１０２は、フレーム１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ２をＷｅｂクライアント１０３に受け渡す（ステップＳ２０５）。
【００３１】
また、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からフレーム２にアクセスするためのリクエストを受信すると、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認する（ステップＳ２５２）。ここで、セッションテーブル３０１上ではセッションＩＤ−Ａ１は削除されることなく保持されているため、セッションＩＤ−Ａ１の確認をとることができる。そして、セッションＩＤ−Ａ１の確認が取れると、そのセッションＩＤ−Ａ１が一定条件を満たしているかどうかを判断する。ここで、セッションＩＤ−Ａ１に要求される一定条件としては、この例ではフレームアクセスが２回であることから、セッションＩＤ−Ａ１の使用回数を２回以下に制限することができる。そして、セッションＩＤ−Ａ１は、ステップＳ２０１のアクセスで１回だけ使用され、今回のステップＳ２５１のアクセスで２回目なので、セッションＩＤ−Ａ１に要求される一定条件を満たしていると判断することができる。このため、Ｗｅｂサーバ１０２は、フレーム２に対応したＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ２をＷｅｂクライアント１０３に受け渡す（ステップＳ２５３）。
【００３２】
次に、Ｗｅｂクライアント１０３からＷｅｂサーバ１０２にアクセスされ（ステップＳ３０１）、そのアクセスにセッションＩＤ−Ａ２が含まれているものとすると、Ｗｅｂサーバ１０２は、セッションテーブル３０１を参照し、セッションＩＤ−Ａ２が登録されていることを確認する（ステップＳ３０２）。そして、セッションＩＤ−Ａ２の確認がとれると、Ｗｅｂサーバ１０２は、セッションＩＤ−Ａ３を採番し（ステップＳ３０３）、セッションＩＤ−Ａ２をセッションテーブル３０１から削除することなく、セッションＩＤ−Ａ３をセッションテーブル３０１に登録する（ステップＳ３０４）。そして、Ｗｅｂサーバ１０２は、ステップＳ３０１のアクセスに対するＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ３をＷｅｂクライアント１０３に受け渡す（ステップＳ３０５）。
【００３３】
また、Ｗｅｂサーバ１０２は、不正クライアント５０１によるセッションＩＤ−Ａ１を使用した不正アクセスを受信すると（ステップＳ１５）、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認し、そのセッションＩＤ−Ａ１が一定条件を満たしているかどうかを判断する（ステップＳ１６）。ここで、セッションＩＤ−Ａ１に要求される一定条件として、セッションＩＤ−Ａ１の使用回数が２回以下に制限されているものとすると、セッションＩＤ−Ａ１は、ステップＳ２０１のアクセスで１回目の使用がされ、ステップＳ２５１のアクセスで２回目の使用がされているので、今回のステップＳ１５のアクセスでは３回目の使用と判断される。このため、Ｗｅｂサーバ１０２は、今回のステップＳ１５のアクセスでは、セッションＩＤ−Ａ１に要求される一定条件を満たしていないと判断し、セッションＩＤ−Ａ１をセッションテーブル３０１から削除する（ステップＳ１７）。そして、Ｗｅｂサーバ１０２は、ステップＳ１５のアクセスに対応したＨＴＴＰレスポンスとしてエラーを不正クライアント５０１に返す（ステップＳ１８）。
【００３４】
これにより、Ｗｅｂクライアント１０３からのアクセスの度にセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を順次採番し、互いに異なる複数のセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３が同時刻に有効になるのを許容しつつ、所定の条件の下でセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を無効化することが可能となるとともに、セッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３に管理ＩＤ−Ａを付与することで、Ｗｅｂクライアント１０３からのアクセスの度にセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を順次採番した場合においても、Ｗｅｂクライアント１０３からの一連のアクセスを管理することができる。
【００３５】
このため、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、不正クライアント５０１によるセッションハイジャックの危険性を低減することが可能となるとともに、リクエストとレスポンスのやり取りを複数回にわたって管理することができ、オンラインショッピングに代表されるＷｅｂアプリケーション２０３におけるユーザの識別処理や、ユーザによる入力データの記憶処理などを一括して管理することができる。
【００３６】
図７は、本発明の一実施形態に係るセッション管理処理の動作を示すフローチャートである。なお、このセッション管理処理は、図５および図６のステップＳ６００ａ〜６００ｅの処理で実行することができる。
図７において、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からのアクセスを受信すると、そのアクセスにセッションＩＤが付与されているかどうかを判断する（ステップＳ８０１）。
そして、Ｗｅｂクライアント１０３からのアクセスにセッションＩＤが付与されていない場合、Ｗｅｂサーバ１０２は、管理ＩＤを採番し（ステップＳ８０２）、セッションテーブル３０１に登録する（ステップＳ８０３）。そして、Ｗｅｂサーバ１０２は、管理ＩＤを採番すると、セッションＩＤを採番し（ステップＳ８０４）、管理ＩＤに紐付けながらセッションＩＤをセッションテーブル３０１に登録する（ステップＳ８０５）。
【００３７】
そして、Ｗｅｂサーバ１０２は、セッションＩＤをセッションテーブル３０１に登録すると、管理ＩＤと有効なセッションＩＤをＷｅｂアプリケーション２０３に渡す（ステップＳ８０６）。
一方、ステップＳ８０１において、Ｗｅｂクライアント１０３からのアクセスにセッションＩＤが付与されている場合、そのセッションＩＤはセッションテーブル３０１に登録されているかどうかを判断する（ステップＳ８２１）。そして、そのセッションＩＤがセッションテーブル３０１に登録されていない場合、Ｗｅｂクライアント１０３にエラーを返す（ステップＳ８２２）。
【００３８】
一方、ステップＳ８２１において、そのセッションＩＤがセッションテーブル３０１に登録されている場合、そのセッションＩＤは既に使用されているかどうかを判断する（ステップＳ８４１）。そして、そのセッションＩＤが過去に使用されていない場合、ステップＳ８０４以降の処理を行う。
一方、ステップＳ８４１において、そのセッションＩＤが過去に使用されている場合、そのセッションＩＤは有効な条件を満たすかどうかを判断する（ステップＳ８４２）。そして、そのセッションＩＤは有効な条件を満たさない場合、そのセッションＩＤをセッションテーブル３０１から削除してから（ステップＳ８６１）、ステップＳ８２２以降の処理を行う。
【００３９】
一方、ステップＳ８４２において、そのセッションＩＤは有効な条件を満たす場合、最新のセッションＩＤを使用し（ステップＳ８４３）、ステップＳ８０６以降の処理を行う。ここで最新のセッションＩＤとは、対象としているセッションＩＤと同一の管理ＩＤが付与されているセッションＩＤにおいて、時系列的に最後にセッションテーブルに採番・登録されたセッションＩＤを指す。
なお、セッションＩＤに有効な条件としては、図５の例では、フレームアクセスが２個であることから、同一のセッションＩＤの使用回数を２回と指定することができ、同一のセッションＩＤが既に２回使用されている場合には、そのセッションＩＤは無効であると判断できる。
【００４０】
また、セッションＩＤに有効な条件として、使用されたセッションの有効時間を、盗聴から不正アクセスを試行するに至るまでに困難な時間内に設定することができ、例えば、数秒から数分という非常に短い有効時間に設定することができ、
また、セッションＩＤを受け渡す際に最も良く利用されるＣｏｏｋｉｅの仕組みでは、最後に受け取ったセッションＩＤが使用される。このため、セッションＩＤに２世代以上古いものが使用されることは考えにくく、２世代以上古いものは不正なアクセスであると判断し、そのセッションＩＤを無効にするようにしてもよい。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態に係るセッション管理装置が適用されるＷｅｂシステムの概略構成を示すブロック図である。
【図２】図１のＷｅｂサーバおよびＷｅｂクライアントの概略構成を示すブロック図である。
【図３】本発明の一実施形態に係るセッションテーブルを従来例と比較して示す図である。
【図４】本発明の一実施形態に係るリソースマッピングを従来例と比較して示す図である。
【図５】本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
【図６】本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
【図７】本発明の一実施形態に係るセッション管理処理の動作を示すフローチャートである。
【図８】従来のセッション管理処理の流れの一例を示すシーケンス図である。
【図９】従来のセッション管理処理の流れのその他の例を示すシーケンス図である。
【符号の説明】
【００４２】
１０１ ネットワーク
１０２ Ｗｅｂサーバ
１０３ａ〜１０３ｃ Ｗｅｂクライアント
２０１ Ｗｅｂブラウザ
２０２ Ｗｅｂサーバソフト
２０３ Ｗｅｂアプリケーション
２０４ セッション管理部
３０１ セッションテーブル
４０１ リソースマッピング
５０１ 不正クライアント
【技術分野】
【０００１】
本発明はセッション管理装置に関し、特に、Ｗｅｂアプリケーションなどで使用されるセッションＩＤを詐称した「なりすまし」を防止する方法に適用して好適なものである。
【背景技術】
【０００２】
近年のインターネットの普及に伴って、電子申請やオンラインショッピングを始めとした様々な手続きや業務が電子化されている。この電子化にあたっては、パーソナルコンピュータに標準搭載されているＷｅｂブラウザをクライアントソフトとし、オンラインショッピングに代表されるＷｅｂアプリケーションを構築することが盛んに行われている。
このＷｅｂアプリケーションの構築に当たっては、ＨＴＴＰというプロトコルが通常用いられる。このＨＴＴＰというプロトコルはステートレスなプロトコルであり、一回のリクエストとレスポンスにより処理が完結する仕組みが採用され、リクエストとレスポンスのやり取りを複数回にわたって管理するためのセッションという概念が備わっていない。オンラインショッピングに代表されるＷｅｂアプリケーションでは、ユーザを識別したり、ユーザが入力した内容を記憶したりする必要があるが、ＨＴＴＰというプロトコルが用いられているため、セッションを管理することができない。
【０００３】
この問題の解決策として、クライアントとサーバ間でのやりとりの際にセッションＩＤと呼ばれるセッションを識別するための識別子の受け渡しを行うことが広く行われている。
具体的には、ある段階でサーバがセッションＩＤを採番し、ＨＴＴＰレスポンス中に含めて受け渡す。クライアントは、その後のリクエスト時に受け取ったセッションＩＤをサーバに送る。サーバは、受け取ったセッションＩＤを確認してセッションを特定する。
【０００４】
この方法では、セッションＩＤが第三者に知られると、俗に言う「なりすまし」による不正アクセスが実行される危険性がある。すなわち、セッションＩＤの受け渡しは、Ｃｏｏｋｉｅと呼ばれる仕組みやＵＲＬの一部分を利用する仕組み、Ｈｉｄｄｅｎパラメータを利用する仕組みなどが一般に知られているが、どの手法においても、通信路の盗聴などにより、セッションＩＤが第三者に知られてしまう危険性がある。
【０００５】
このような第三者が略取したセッションＩＤを使用して不正なアクセスを行う行為はセッションハイジャックと呼ばれ、Ｗｅｂアプリケーションに対するセキュリティ上の脅威として問題視されており、セッションＩＤの有効期限を設定するという対抗策が考えられている。
また、特許文献１には、Ｗｅｂシステムにおけるセッション管理に関して、セッションハイジャックの危険性を低減するために、Ｗｅｂクライアントからのアクセス毎に当該Ｗｅｂクライアントとの間のセッションＩＤの更新登録を行う方法が開示されている。
【０００６】
図８は、従来のセッション管理処理の流れの一例を示すシーケンス図である。
図８において、Ｗｅｂクライアント１３上には表示画面１３ａが設けられ、表示画面１３ａにはＷｅｂアプリケーションに応じたログイン画面が表示される。そして、ログイン画面上でユーザＩＤやパスワードが入力され、ログインボタンが押下されると、Ｗｅｂクライアント１３からＷｅｂサーバ１２に認証情報が送信される（ステップＳ６０１）。そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から認証情報を受信すると、アカウントデータベース１４を参照することで、Ｗｅｂクライアント１３を認証する（ステップＳ６０２）。そして、Ｗｅｂクライアント１３が認証されると、Ｗｅｂサーバ１２は、セッションＩＤ１を採番し（ステップＳ６０３）、セッションデータベース１５に新規登録するとともに（ステップＳ６０４）、ＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ１をＷｅｂクライアント１３に受け渡すことで（ステップＳ６０５）、Ｗｅｂクライアント１３はフレーム構造のみ取得する。
【０００７】
ここで、ログイン後の表示画面１３ａがフレーム１、２によって複数の画面から構成される場合、フレーム１、２にアクセスするための複数のリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ６０６、Ｓ６１０）。
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３からフレーム１にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ６０７）。そして、セッションＩＤ１の確認がとれると、Ｗｅｂサーバ１２は、セッションＩＤ２を採番し（ステップＳ６０８）、セッションＩＤ１をセッションデータベース１５から削除するとともに、セッションＩＤ２をセッションデータベース１５に更新登録する（ステップＳ６０９）。そして、Ｗｅｂサーバ１２は、フレーム１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ２をＷｅｂクライアント１３に受け渡すことで（ステップＳ６１１）、表示画面１３ａ上にフレーム１の正常な内容が表示される。
【０００８】
また、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３からフレーム２にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ６１２）。ここで、セッションデータベース１５上ではセッションＩＤ１が既に削除され、セッションＩＤ１の確認がとれないため、フレーム２に対応したＨＴＴＰレスポンスとしてエラーがＷｅｂクライアント１３に返され（ステップＳ６１３）、表示画面１３ａ上にフレーム２のエラーの内容が表示される。
【０００９】
図９は、従来のセッション管理処理の流れのその他の例を示すシーケンス図である。
図９において、ログイン画面上でユーザＩＤやパスワードが入力され、ログインボタンが押下されると、Ｗｅｂクライアント１３からＷｅｂサーバ１２に認証情報が送信される（ステップＳ７０１）。そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から認証情報を受信すると、アカウントデータベース１４を参照することで、Ｗｅｂクライアント１３を認証する（ステップＳ７０２）。そして、Ｗｅｂクライアント１３が認証されると、Ｗｅｂサーバ１２は、セッションＩＤ１を採番し（ステップＳ７０３）、セッションデータベース１５に新規登録するとともに（ステップＳ７０４）、ＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ１をＷｅｂクライアント１３に受け渡すことで（ステップＳ７０５）、Ｗｅｂクライアント１３はメニュー画面を取得する。
【００１０】
ここで、メニュー画面には複数の画面１、２へのリンクが含まれ、メニュー画面上で画面１へのリンクが押下された場合、画面１にアクセスするためのリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ７０６）。
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から画面１にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ７０７）。そして、セッションＩＤ１の確認がとれると、Ｗｅｂサーバ１２は、セッションＩＤ２を採番し（ステップＳ７０８）、セッションＩＤ１をセッションデータベース１５から削除するとともに、セッションＩＤ２をセッションデータベース１５に更新登録する（ステップＳ７０９）。
【００１１】
そして、Ｗｅｂサーバ１２は、画面１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１３に返し、セッションＩＤ２をＷｅｂクライアント１３に受け渡す（ステップＳ７１１）。ここで、Ｗｅｂサーバ１２による処理中に画面２へのリンクが押下された場合、ブラウザは画面１への接続を既に廃棄しているため、画面１への接続が無効化される。
また、画面２へのリンクが押下されると、画面２にアクセスするためのリクエストが行われ、セッションＩＤ１がＷｅｂサーバ１２に受け渡される（ステップＳ７１０）。
【００１２】
そして、Ｗｅｂサーバ１２は、Ｗｅｂクライアント１３から画面２にアクセスするためのリクエストを受信すると、セッションデータベース１５を参照することで、セッションＩＤ１を確認する（ステップＳ７１２）。ここで、セッションデータベース１５上ではセッションＩＤ１が既に削除され、セッションＩＤ１の確認がとれないため、画面２に対応したＨＴＴＰレスポンスとしてエラーがＷｅｂクライアント１３に返され（ステップＳ７１３）、表示画面１３ａ上にエラーの内容が表示される。
【特許文献１】特開２００６−３４４１３７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、セッションＩＤの有効期限を設定する方法では、有効期限が短かすぎれば、ユーザの利便性が低下し、有効期限が長すぎると、セッションハイジャックへの防止効果が低下するという問題があった。加えて、セッションＩＤの有効期限を設定する方法では、最後のアクセスから有効期限内に操作されなかった場合にセッションＩＤが無効化され、ユーザがＷｅｂアプリケーションを利用し続けている間はセッションＩＤは有効であるため、セッションハイジャックへの防止効果としてはそれほど高くない。
【００１４】
また、特許文献１に開示された手法では、図８および図９に示したように、同じセッションＩＤで複数のリクエストが送られる場合やサーバが処理中にクライアント側で別なページへ遷移するボタンが押された場合などでは、正規のユーザであるにも関わらずエラーとなるという問題があった。
そこで、本発明の目的は、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、セッションハイジャックの危険性を低減することが可能なセッション管理装置を提供することである。
【課題を解決するための手段】
【００１５】
上述した課題を解決するために、請求項１記載のセッション管理装置によれば、ＷｅｂクライアントとＷｅｂサーバとの間で受け渡されるセッションＩＤを前記Ｗｅｂクライアントからのアクセスの度に採番するセッションＩＤ採番手段と、前記Ｗｅｂクライアントからの一連のアクセスを前記Ｗｅｂサーバ側で管理する管理ＩＤを前記セッションＩＤに付与し、前記管理ＩＤを付与された前記セッションＩＤの情報に基づき、前記Ｗｅｂクライアントから受け渡されるセッションＩＤの有効・無効を確認するセッションＩＤ管理手段とを備えることを特徴とする。
【００１６】
また、請求項２記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、互いに異なる複数のセッションＩＤに同一管理ＩＤの付与を許容することを特徴とする。
また、請求項３記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセス回数を利用し、既に使用されたセッションＩＤを使用回数に基づいて任意のタイミングで無効化することを特徴とする。
【００１７】
また、請求項４記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセスからの経過時間を利用し、既に使用されたセッションＩＤをその使用後の有効時間に基づいて任意のタイミングで無効化することを特徴とする。
また、請求項５記載のセッション管理装置によれば、前記セッションＩＤ管理手段は、あるセッションＩＤの使用後に新たに発行されたセッションＩＤの個数を利用し、既に使用されたセッションＩＤを前記セッションＩＤの世代に基づいて任意のタイミングで無効化することを特徴とする。
【発明の効果】
【００１８】
以上説明したように、本発明によれば、Ｗｅｂクライアントからのアクセスの度にセッションＩＤを採番し、互いに異なる複数のセッションＩＤが同時刻に有効になるのを許容しつつ、所定の条件下でセッションＩＤを無効化することが可能となるとともに、セッションＩＤに管理ＩＤを付与することで、Ｗｅｂクライアントからのアクセスの度にセッションＩＤを採番した場合においても、Ｗｅｂクライアントからの一連のアクセスを管理することができる。
このため、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、セッションハイジャックの危険性を低減することが可能となるとともに、リクエストとレスポンスのやり取りを複数回にわたって管理することができ、オンラインショッピングに代表されるＷｅｂアプリケーションにおけるユーザの識別処理や、ユーザによる入力データの記憶処理などを一括して管理することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施形態に係るセッション管理装置について図面を参照しながら説明する。
図１は、本発明の一実施形態に係るセッション管理装置が適用されるＷｅｂシステムの概略構成を示すブロック図である。
図１において、Ｗｅｂシステムには、Ｗｅｂサーバ１０２およびＷｅｂクライアント１０３ａ〜１０３ｃが設けられ、Ｗｅｂサーバ１０２とＷｅｂクライアント１０３ａ〜１０３ｃとはネットワーク１０１を介して接続されている。
【００２０】
なお、ネットワーク１０１としては、ＬＡＮまたはＷＡＮなどの他、インターネットなどのネットワークを用いることができる。また、Ｗｅｂサーバ１０２としては、例えば、パーソナルコンピュータを用いることができ、Ｗｅｂクライアント１０３ａ〜１０３ｃとしては、パーソナルコンピュータなどの他、携帯電話などの携帯情報端末を用いることができる。また、Ｗｅｂクライアント１０３ａ〜１０３ｃには、Ｗｅｂブラウザをクライアントソフトとして搭載し、Ｗｅｂサーバ１０２には、オンラインショッピングなどのＷｅｂアプリケーションを搭載することができる。また、Ｗｅｂサーバ１０２は、そこに搭載されるＷｅｂアプリケーションの数に応じて複数台で構成するようにしてもよい。
【００２１】
図２は、図１のＷｅｂサーバおよびＷｅｂクライアントの概略構成を示すブロック図である。
図２において、Ｗｅｂクライアント１０３ａ〜１０３ｃにはＷｅｂブラウザ２０１がそれぞれ搭載され、Ｗｅｂサーバ１０２には、Ｗｅｂサーバソフト２０２およびＷｅｂアプリケーション２０３が搭載されている。また、Ｗｅｂサーバ１０２には、セッションの管理を行うセッション管理部２０４が設けられている。なお、セッション管理部２０４は、Ｗｅｂアプリケーション２０３の一部として動作するようにしてもよい。
【００２２】
Ｗｅｂブラウザ２０１は、ＨＴＴＰやＨＴＴＰを利用するプロトコル（ＳＳＬやＴＬＳなど。以下、総称してＨＴＴＰと呼ぶ）を使用することで、ネットワーク１０１を介してＷｅｂサーバソフト２０２との間で処理要求の送信や処理結果の受信を行うことができる。
Ｗｅｂサーバソフト２０２は、Ｗｅｂブラウザ２０１より送られた処理要求をＷｅｂアプリケーション２０３に受け渡したり、Ｗｅｂアプリケーション２０３による処理結果（ＨＴＭＬ、ＸＭＬ、ＴＥＸＴのようなテキストデータや画像・動画に代表されるバイナリデータ）をＷｅｂブラウザ２０１に送信したりすることができる。
【００２３】
Ｗｅｂアプリケーション２０３は、Ｗｅｂサーバソフト２０２から受け取った処理要求を元にセッション管理部２０４と連携して一連のアクセスを識別し、所定の処理を行ってＷｅｂサーバソフト２０２に受け渡すことができる。
セッション管理部２０４は、Ｗｅｂクライアント１０３ａ〜１０３ｃとＷｅｂサーバ１０２との間で受け渡されるセッションＩＤをＷｅｂクライアント１０３ａ〜１０３ｃからのアクセスの度に採番し、Ｗｅｂクライアント１０３ａ〜１０３からの一連のアクセスをＷｅｂサーバ１０２側で管理する管理ＩＤをセッションＩＤに付与することができる。
【００２４】
そして、セッション管理部２０４は、リクエスト中にセッションＩＤが含まれていない場合に管理ＩＤ並びにセッションＩＤを採番し発行する。一方、リクエスト中にセッションＩＤが含まれている場合はアクセスの度にセッションＩＤを採番し発行する。これにより、Ｗｅｂクライアント１０３ａ〜１０３ｃは、フレームにより構成された画面やＷｅｂサーバ１０２が処理中に別なページへの遷移を行った場合の例外を除いて、各アクセスごとに異なるセッションＩＤを使用することができる。
【００２５】
また、セッション管理部２０４は、従来のセッション管理方式が行っていたようにセッションＩＤをもって一連のアクセスを識別するのではなく、セッションＩＤから管理ＩＤを特定し、管理ＩＤを持って一連のアクセスを識別することにより、間接的に一連のアクセスに紐付くセッションＩＤを同時刻において複数個有効にすることが可能となる。
これにより、従来方式のように、新しいセッションＩＤを発行した際に直ちに使用済みのセッションＩＤが無効になるのではなく、任意のタイミングでセッションＩＤを無効にすることが可能となる。
【００２６】
また、使用済みのセッションＩＤを無効化するタイミングを、当該セッションＩＤを使用したアクセス回数や当該セッションＩＤを使用したアクセスからの経過時間、当該セッションＩＤ以降に発行されたセッションＩＤ数などの値を利用して設定することが可能となる。
その結果、使用されたセッションＩＤは無効化されるが、一定期間の間は既に使用されたセッションＩＤであっても有効であるという制御が可能となり、セッションハイジャックによるなりすましの脅威を低減しつつ、正規のユーザによる正常なアクセス時には処理を継続することが可能となる。
ここで、セッション管理部２０４には、セッションＩＤと管理ＩＤとを管理するセッションテーブル３０１が設けられ、セッション管理部２０４は、一連のアクセスによってその都度採番されたセッションＩＤと管理ＩＤとを紐付けすることができる。
【００２７】
図３は、本発明の一実施形態に係るセッションテーブルを従来例と比較して示す図である。
図３（ｂ）において、従来のセッションテーブル３０２では、セッションＩＤが個別に管理される。これに対し、本実施形態のセッションテーブル３０１では、図３（ａ）に示すように、一連のアクセスによってその都度採番された複数のセッションＩＤは、同一の管理ＩＤにて一括して管理される。なお、ここでは便宜上一つの管理ＩＤに複数のセッションＩＤとして模式化して示しているが、相関関係が保たれておればよく、テーブルの構成を限定するものでは無い。
図４は、本発明の一実施形態に係るリソースマッピングを従来例と比較して示す図である。
図４（ｂ）において、従来のリソースマッピング４０２では、Ｗｅｂサーバ１０２のリソースはセッションＩＤごとに紐付けられる。これに対し、本実施形態のセッションテーブル４０１では、図４（ａ）に示すように、Ｗｅｂサーバ１０２のリソースは管理ＩＤごとに紐付けられる。
【００２８】
図５および図６は、本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
図５において、Ｗｅｂクライアント１０３ａ〜１０３ｃ（以降の説明において、Ｗｅｂクライアント１０３と記す）からＷｅｂサーバ１０２にアクセスされ（ステップＳ１０１）、そのアクセスにセッションＩＤが含まれていないものとすると、Ｗｅｂサーバ１０２は、管理ＩＤ−Ａを採番し（ステップＳ１０２）、セッションテーブル３０１に新規登録する（ステップＳ１０３）。そして、管理ＩＤ−Ａの登録後、セッションＩＤ−Ａ１を採番し（ステップＳ１０４）、セッションテーブル３０１に新規登録するとともに（ステップＳ１０５）、ＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ１をＷｅｂクライアント１０３に受け渡す（ステップＳ１０６）。なお、ここでは図示していないが、管理ＩＤを採番する度にセッションテーブル３０１にアクセスし、採番すべきＩＤを決めてもよいし、Ｗｅｂアプリケーション２０３内に管理ＩＤの採番用内部変数を保持し、これに基づき採番しても構わない。また、説明の関係上、ステップＳ６００ａでは、管理ＩＤ−Ａの登録とセッションＩＤ−Ａ１と分けているが、同時に行っても構わない。
【００２９】
ここで、Ｗｅｂクライアント１０３上の表示画面がフレーム１、２によって複数の画面から構成される場合、フレーム１、２にアクセスするための複数のリクエストがＷｅｂクライアント１０３から行われ、セッションＩＤ−Ａ１がＷｅｂサーバ１０２に受け渡される（ステップＳ２０１、Ｓ２５１）。なお、セッションＩＤ−Ａ１は、Ｗｅｂブラウザ２０１の備える機能であるＣｏｏｋｉｅの仕組みか、またはＵＲＬの一部、またはＰＯＳＴパラメータなどとして送信することができる。この時、不正クライアント５０１は、ネットワーク１０１の盗聴などにより、セッションＩＤ−Ａ１を入手することができる。
【００３０】
そして、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からフレーム１にアクセスするためのリクエストを受信すると、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認する（ステップＳ２０２）。そして、セッションＩＤ−Ａ１の確認がとれると、Ｗｅｂサーバ１０２は、セッションＩＤ−Ａ２を採番し（ステップＳ２０３）、セッションＩＤ−Ａ１をセッションテーブル３０１から削除することなく、セッションＩＤ−Ａ２をセッションテーブル３０１に登録する（ステップＳ２０４）。そして、Ｗｅｂサーバ１０２は、フレーム１に対応したＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ２をＷｅｂクライアント１０３に受け渡す（ステップＳ２０５）。
【００３１】
また、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からフレーム２にアクセスするためのリクエストを受信すると、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認する（ステップＳ２５２）。ここで、セッションテーブル３０１上ではセッションＩＤ−Ａ１は削除されることなく保持されているため、セッションＩＤ−Ａ１の確認をとることができる。そして、セッションＩＤ−Ａ１の確認が取れると、そのセッションＩＤ−Ａ１が一定条件を満たしているかどうかを判断する。ここで、セッションＩＤ−Ａ１に要求される一定条件としては、この例ではフレームアクセスが２回であることから、セッションＩＤ−Ａ１の使用回数を２回以下に制限することができる。そして、セッションＩＤ−Ａ１は、ステップＳ２０１のアクセスで１回だけ使用され、今回のステップＳ２５１のアクセスで２回目なので、セッションＩＤ−Ａ１に要求される一定条件を満たしていると判断することができる。このため、Ｗｅｂサーバ１０２は、フレーム２に対応したＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ２をＷｅｂクライアント１０３に受け渡す（ステップＳ２５３）。
【００３２】
次に、Ｗｅｂクライアント１０３からＷｅｂサーバ１０２にアクセスされ（ステップＳ３０１）、そのアクセスにセッションＩＤ−Ａ２が含まれているものとすると、Ｗｅｂサーバ１０２は、セッションテーブル３０１を参照し、セッションＩＤ−Ａ２が登録されていることを確認する（ステップＳ３０２）。そして、セッションＩＤ−Ａ２の確認がとれると、Ｗｅｂサーバ１０２は、セッションＩＤ−Ａ３を採番し（ステップＳ３０３）、セッションＩＤ−Ａ２をセッションテーブル３０１から削除することなく、セッションＩＤ−Ａ３をセッションテーブル３０１に登録する（ステップＳ３０４）。そして、Ｗｅｂサーバ１０２は、ステップＳ３０１のアクセスに対するＨＴＴＰレスポンスをＷｅｂクライアント１０３に返し、セッションＩＤ−Ａ３をＷｅｂクライアント１０３に受け渡す（ステップＳ３０５）。
【００３３】
また、Ｗｅｂサーバ１０２は、不正クライアント５０１によるセッションＩＤ−Ａ１を使用した不正アクセスを受信すると（ステップＳ１５）、セッションテーブル３０１を参照し、セッションＩＤ−Ａ１が登録されていることを確認し、そのセッションＩＤ−Ａ１が一定条件を満たしているかどうかを判断する（ステップＳ１６）。ここで、セッションＩＤ−Ａ１に要求される一定条件として、セッションＩＤ−Ａ１の使用回数が２回以下に制限されているものとすると、セッションＩＤ−Ａ１は、ステップＳ２０１のアクセスで１回目の使用がされ、ステップＳ２５１のアクセスで２回目の使用がされているので、今回のステップＳ１５のアクセスでは３回目の使用と判断される。このため、Ｗｅｂサーバ１０２は、今回のステップＳ１５のアクセスでは、セッションＩＤ−Ａ１に要求される一定条件を満たしていないと判断し、セッションＩＤ−Ａ１をセッションテーブル３０１から削除する（ステップＳ１７）。そして、Ｗｅｂサーバ１０２は、ステップＳ１５のアクセスに対応したＨＴＴＰレスポンスとしてエラーを不正クライアント５０１に返す（ステップＳ１８）。
【００３４】
これにより、Ｗｅｂクライアント１０３からのアクセスの度にセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を順次採番し、互いに異なる複数のセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３が同時刻に有効になるのを許容しつつ、所定の条件の下でセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を無効化することが可能となるとともに、セッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３に管理ＩＤ−Ａを付与することで、Ｗｅｂクライアント１０３からのアクセスの度にセッションＩＤ−Ａ１、ＩＤ−Ａ２、ＩＤ−Ａ３を順次採番した場合においても、Ｗｅｂクライアント１０３からの一連のアクセスを管理することができる。
【００３５】
このため、正規のユーザによる正常なアクセスの妨害となるのを防止しつつ、不正クライアント５０１によるセッションハイジャックの危険性を低減することが可能となるとともに、リクエストとレスポンスのやり取りを複数回にわたって管理することができ、オンラインショッピングに代表されるＷｅｂアプリケーション２０３におけるユーザの識別処理や、ユーザによる入力データの記憶処理などを一括して管理することができる。
【００３６】
図７は、本発明の一実施形態に係るセッション管理処理の動作を示すフローチャートである。なお、このセッション管理処理は、図５および図６のステップＳ６００ａ〜６００ｅの処理で実行することができる。
図７において、Ｗｅｂサーバ１０２は、Ｗｅｂクライアント１０３からのアクセスを受信すると、そのアクセスにセッションＩＤが付与されているかどうかを判断する（ステップＳ８０１）。
そして、Ｗｅｂクライアント１０３からのアクセスにセッションＩＤが付与されていない場合、Ｗｅｂサーバ１０２は、管理ＩＤを採番し（ステップＳ８０２）、セッションテーブル３０１に登録する（ステップＳ８０３）。そして、Ｗｅｂサーバ１０２は、管理ＩＤを採番すると、セッションＩＤを採番し（ステップＳ８０４）、管理ＩＤに紐付けながらセッションＩＤをセッションテーブル３０１に登録する（ステップＳ８０５）。
【００３７】
そして、Ｗｅｂサーバ１０２は、セッションＩＤをセッションテーブル３０１に登録すると、管理ＩＤと有効なセッションＩＤをＷｅｂアプリケーション２０３に渡す（ステップＳ８０６）。
一方、ステップＳ８０１において、Ｗｅｂクライアント１０３からのアクセスにセッションＩＤが付与されている場合、そのセッションＩＤはセッションテーブル３０１に登録されているかどうかを判断する（ステップＳ８２１）。そして、そのセッションＩＤがセッションテーブル３０１に登録されていない場合、Ｗｅｂクライアント１０３にエラーを返す（ステップＳ８２２）。
【００３８】
一方、ステップＳ８２１において、そのセッションＩＤがセッションテーブル３０１に登録されている場合、そのセッションＩＤは既に使用されているかどうかを判断する（ステップＳ８４１）。そして、そのセッションＩＤが過去に使用されていない場合、ステップＳ８０４以降の処理を行う。
一方、ステップＳ８４１において、そのセッションＩＤが過去に使用されている場合、そのセッションＩＤは有効な条件を満たすかどうかを判断する（ステップＳ８４２）。そして、そのセッションＩＤは有効な条件を満たさない場合、そのセッションＩＤをセッションテーブル３０１から削除してから（ステップＳ８６１）、ステップＳ８２２以降の処理を行う。
【００３９】
一方、ステップＳ８４２において、そのセッションＩＤは有効な条件を満たす場合、最新のセッションＩＤを使用し（ステップＳ８４３）、ステップＳ８０６以降の処理を行う。ここで最新のセッションＩＤとは、対象としているセッションＩＤと同一の管理ＩＤが付与されているセッションＩＤにおいて、時系列的に最後にセッションテーブルに採番・登録されたセッションＩＤを指す。
なお、セッションＩＤに有効な条件としては、図５の例では、フレームアクセスが２個であることから、同一のセッションＩＤの使用回数を２回と指定することができ、同一のセッションＩＤが既に２回使用されている場合には、そのセッションＩＤは無効であると判断できる。
【００４０】
また、セッションＩＤに有効な条件として、使用されたセッションの有効時間を、盗聴から不正アクセスを試行するに至るまでに困難な時間内に設定することができ、例えば、数秒から数分という非常に短い有効時間に設定することができ、
また、セッションＩＤを受け渡す際に最も良く利用されるＣｏｏｋｉｅの仕組みでは、最後に受け取ったセッションＩＤが使用される。このため、セッションＩＤに２世代以上古いものが使用されることは考えにくく、２世代以上古いものは不正なアクセスであると判断し、そのセッションＩＤを無効にするようにしてもよい。
【図面の簡単な説明】
【００４１】
【図１】本発明の一実施形態に係るセッション管理装置が適用されるＷｅｂシステムの概略構成を示すブロック図である。
【図２】図１のＷｅｂサーバおよびＷｅｂクライアントの概略構成を示すブロック図である。
【図３】本発明の一実施形態に係るセッションテーブルを従来例と比較して示す図である。
【図４】本発明の一実施形態に係るリソースマッピングを従来例と比較して示す図である。
【図５】本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
【図６】本発明の一実施形態に係るセッション管理処理の流れを示すシーケンス図である。
【図７】本発明の一実施形態に係るセッション管理処理の動作を示すフローチャートである。
【図８】従来のセッション管理処理の流れの一例を示すシーケンス図である。
【図９】従来のセッション管理処理の流れのその他の例を示すシーケンス図である。
【符号の説明】
【００４２】
１０１ ネットワーク
１０２ Ｗｅｂサーバ
１０３ａ〜１０３ｃ Ｗｅｂクライアント
２０１ Ｗｅｂブラウザ
２０２ Ｗｅｂサーバソフト
２０３ Ｗｅｂアプリケーション
２０４ セッション管理部
３０１ セッションテーブル
４０１ リソースマッピング
５０１ 不正クライアント
【特許請求の範囲】
【請求項１】
ＷｅｂクライアントとＷｅｂサーバとの間で受け渡されるセッションＩＤを前記Ｗｅｂクライアントからのアクセスの度に採番するセッションＩＤ採番手段と、
前記Ｗｅｂクライアントからの一連のアクセスを前記Ｗｅｂサーバ側で管理する管理ＩＤを前記セッションＩＤに付与し、前記管理ＩＤを付与された前記セッションＩＤの情報に基づき、前記Ｗｅｂクライアントから受け渡されるセッションＩＤの有効・無効を確認するセッションＩＤ管理手段とを備えることを特徴とするセッション管理装置。
【請求項２】
前記セッションＩＤ管理手段は、互いに異なる複数のセッションＩＤに同一管理ＩＤの付与を許容することを特徴とする請求項１記載のセッション管理装置。
【請求項３】
前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセス回数を利用し、既に使用されたセッションＩＤを使用回数に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【請求項４】
前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセスからの経過時間を利用し、既に使用されたセッションＩＤをその使用後の有効時間に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【請求項５】
前記セッションＩＤ管理手段は、あるセッションＩＤの使用後に新たに発行されたセッションＩＤの個数を利用し、既に使用されたセッションＩＤを前記セッションＩＤの世代に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【請求項１】
ＷｅｂクライアントとＷｅｂサーバとの間で受け渡されるセッションＩＤを前記Ｗｅｂクライアントからのアクセスの度に採番するセッションＩＤ採番手段と、
前記Ｗｅｂクライアントからの一連のアクセスを前記Ｗｅｂサーバ側で管理する管理ＩＤを前記セッションＩＤに付与し、前記管理ＩＤを付与された前記セッションＩＤの情報に基づき、前記Ｗｅｂクライアントから受け渡されるセッションＩＤの有効・無効を確認するセッションＩＤ管理手段とを備えることを特徴とするセッション管理装置。
【請求項２】
前記セッションＩＤ管理手段は、互いに異なる複数のセッションＩＤに同一管理ＩＤの付与を許容することを特徴とする請求項１記載のセッション管理装置。
【請求項３】
前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセス回数を利用し、既に使用されたセッションＩＤを使用回数に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【請求項４】
前記セッションＩＤ管理手段は、セッションＩＤを使用したアクセスからの経過時間を利用し、既に使用されたセッションＩＤをその使用後の有効時間に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【請求項５】
前記セッションＩＤ管理手段は、あるセッションＩＤの使用後に新たに発行されたセッションＩＤの個数を利用し、既に使用されたセッションＩＤを前記セッションＩＤの世代に基づいて任意のタイミングで無効化することを特徴とする請求項１または２記載のセッション管理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００９−１４０１６３（Ｐ２００９−１４０１６３Ａ）
【公開日】平成２１年６月２５日（２００９．６．２５）
【国際特許分類】
【出願番号】特願２００７−３１４８０９（Ｐ２００７−３１４８０９）
【出願日】平成１９年１２月５日（２００７．１２．５）
【出願人】（５９１０８３２４４）富士電機システムズ株式会社 (1,717)
【Ｆターム（参考）】
【公開日】平成２１年６月２５日（２００９．６．２５）
【国際特許分類】
【出願日】平成１９年１２月５日（２００７．１２．５）
【出願人】（５９１０８３２４４）富士電機システムズ株式会社 (1,717)
【Ｆターム（参考）】
[ Back to top ]