ウェブサイトのための安全なセッション管理用プログラム、セッション管理方法、及びセッション管理システム
【課題】安全なセッション管理を実現しつつ、プログラムの実行効率と作成効率に著しい劣化を伴わないようにする。
【解決手段】 ウェブサイトのための安全なセッション管理用プログラムは、コンピュータに、ウェブクライアントからウェブページのアクセス要求を受けたときに、要求されたウェブページが非保護のウェブページの場合（Ｓｔ１：ＮＯ）、当該ウェブページの処理を行うステップ（Ｓｔ１０）と、要求されたウェブページが保護すべきウェブページの場合（Ｓｔ１：ＹＥＳ）、当該ウェブページの処理（Ｓｔ１０）を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいてウェブページに対するセッションを認証する処理を含む前処理を行うステップ（Ｓｔ２〜Ｓｔ９）とを実行させる。
【解決手段】 ウェブサイトのための安全なセッション管理用プログラムは、コンピュータに、ウェブクライアントからウェブページのアクセス要求を受けたときに、要求されたウェブページが非保護のウェブページの場合（Ｓｔ１：ＮＯ）、当該ウェブページの処理を行うステップ（Ｓｔ１０）と、要求されたウェブページが保護すべきウェブページの場合（Ｓｔ１：ＹＥＳ）、当該ウェブページの処理（Ｓｔ１０）を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいてウェブページに対するセッションを認証する処理を含む前処理を行うステップ（Ｓｔ２〜Ｓｔ９）とを実行させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブサイトのための安全なセッション管理用プログラム、セッション管理方法、及びセッション管理システムに関する。
【背景技術】
【０００２】
近年、インターネットに代表される通信ネットワークの利用増大に伴い、ネットワーク上のウェブサイトを用いた電子商取引も盛んに行われるようになっている。このような電子商取引では、ウェブサイトを成すウェブページを生成し維持するウェブサーバと、ウェブサイトにアクセスするウェブブラウザをもつウェブクライアントとの間でネットワークを介して通信が行われる。ウェブページにアクセスする際に用いる通信プロトコルには、通常、ＨＴＴＰ（HyperText Transfer Protocol）が使用されるが、個人情報やクレジットカード番号等を安全にやり取りする場合には、ＨＴＴＰにＳＳＬ（Secure Socket Layer）によるデータの暗号化機能を付加したＨＴＴＰＳ（Hypertext Transfer Protocol Security）も使用される。
【０００３】
ＨＴＴＰは、要求とその応答の１組で完結するステートレスなプロトコルである。このため、ＨＴＴＰを用いて、ユーザがウェブクライアントからウェブサイトのネットワーク上の所在を示すＵＲＬ（Uniform Resource Locator）を指定してそのウェブページにログインしてからログアウトするまでの同一ユーザによる一連のアクセス、すなわち同一ユーザによるセッションを識別し、そのセッションを追跡・維持するため、クッキー機能を利用することが多い。
【０００４】
クッキーを使用する場合、ウェブブラウザの画面上でユーザ名とパスワードが入力され、ログイン実行ボタンが押されると、サーバは、入力されたユーザ名とパスワード、又はその暗号化されたデータ、或いは登録されたユーザであることが確認された場合のみに乱数により発行されるセッションＩＤを入れたクッキーを応答ヘッダ内に記述されるデータとして発行する。それ以降、ウェブブラウザは、アクセス毎に応答ヘッダ内にそのデータを入れて送出するので、サーバはそのクッキーのデータに基づきユーザを特定し、そのユーザに対し一貫性のあるデータ処理及びサービス提供を行うことができる。
【０００５】
この場合、安全なアクセス制御のためには、パケット盗聴等によりクッキーが第三者に盗まれるといった事態を回避する必要がある。そのため、ＨＴＴＰに基づいてウェブサーバによりウェブクライアントに発行されるクッキーには、name属性、path属性、domain属性等のほか、オプションとしてsecure属性を指定できるようになっている。
【０００６】
secure属性が指定されていないクッキーは、通信プロトコルがＨＴＴＰの場合でも、ＨＴＴＰＳの場合でも、送出される。すなわち、ＵＲＬが「http://」で始まる非保護のウェブページにアクセスする場合でも、「https://」で始まる保護されたウェブページにアクセスする場合でも、いずれの場合でもクッキーデータが通信路上に流れる。これに対し、secure属性が指定されたクッキーは、通信プロトコルがＨＴＴＰＳの場合のみ送出され、ＨＴＴＰの場合では送出されない。すなわち、ＵＲＬが「https://」で始まる保護されたウェブページにアクセスする場合のみにクッキーデータが通信路上に流れ、「http://」で始まる非保護のウェブページにアクセスする場合には、クッキーデータが通信路上に流れない。
【０００７】
しかしながら、クッキーを用いたアクセス制御に際し、上記secure属性による機能が正しく使用されず、例えばクッキーが暗号化されずにネットワークに流れる等の事態が生じると、第三者がクッキーデータを盗聴することによってユーザのログイン状態（セッション）を乗っ取ることが可能となり、最悪の場合、パスワード等の個人情報を不正に閲覧したり、クレジットカード番号を盗み出したりする等、不都合な事態が生じる恐れがある（例えば、非特許文献１参照）。
【０００８】
このようなセッション維持のために使用されるクッキー（セッション維持クッキー）のデータ盗聴によるセッションの乗っ取りを回避する対策として、従来、ウェブサイトのための安全なセッション管理を行うシステム及び方法の一例が提案されている（例えば、特許文献１、非特許文献１、２参照）。
【０００９】
例えば、非特許文献１では、セッション維持クッキーを用いているウェブサイトにおいて、セッションの乗っ取りを避けた安全なセッション管理として、次の二つの方法が記載されている。
【００１０】
１）ウェブページとセッション維持クッキーの全てを保護されたウェブページ及び保護されたクッキーとする。すなわち、ウェブサイトの全てのウェブページが「https://」で始まるＵＲＬをもち、クッキーにはsecure属性が付加されるようにする。
【００１１】
２）保護されたウェブページでセッションを認証するために、非保護のセッション維持クッキーとは別に、保護されたクッキー（オースコードクッキー）を用意し、セッションを認証する。すなわち、２つのクッキーを用意し、１つ目のクッキーにはsecure属性を付加せず、２つ目のクッキーにはsecure属性を付加し、両者ともにランダムに生成されるセッションＩＤを与え、どちらのセッションＩＤからでもユーザを特定できるようにする。これにより、「https://」のウェブページではsecure属性が付加された２つ目のクッキーからユーザを特定すると共に、「http://」のウェブページではsecure属性が付加されない１つ目のクッキーからユーザを特定する。そうすると、仮に１つ目のsecure属性が付加されないクッキーが盗聴されても、それが「https://」のウェブページに入るのに必要なセッションＩＤではないため、ＳＳＬで保護されているウェブページの情報にアクセスすることはできない。
【００１２】
上記二つの方法のうち、１）の方法を用いると、非特許文献３でも指摘されているように、全てのウェブページを保護されたウェブページとして扱うため、すべての通信をＳＳＬで行うことでオーバーヘッドが大きくなる等、ウェブサイトの実行効率に著しい劣化が発生してしまう可能性がある。
【００１３】
そこで、現実的な方法としては、２）の方法を用いて、セッション維持のための非保護のクッキーと、保護されたウェブページにおける認証のための保護されたオースコードクッキーとを併用する必要がある。この例を図４に基づいて説明する。
【００１４】
図４に示すウェブサイトのための安全なセッション管理を行うシステムは、ウェブサイトを管理するウェブサーバ１２と、ウェブサイトにアクセスするウェブクライアント１６と、両者１２、１６を通信可能に接続するインターネット等のＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）に基づくネットワークから成る通信チャネル（通信路）１４とから構成されている。ウェブサーバ１２は、ソフトウェア構成上、ウェブサーバソフトウェア１８と、ウェブサーバソフトウェア１８により管理されるウェブサイトを成すウェブページ２２とを有している。ウェブページ２２には、保護すべきウェブページ３０と、非保護でも構わないウェブページ２８とが含まれる。
【００１５】
このような構成を有する従来のシステムにおいて、保護すべきウェブページ３０は、そのデータの送受信にあたってセッションの認証を行う必要があるため、ウェブページ３０内に記述されるサブプログラム３１によって応答が生成される。すなわち、保護すべきウェブページ３０の応答を生成するサブプログラム３１全てでセッションの認証処理を行う必要があり、その結果、ウェブページ３０内のセッションの認証を行うためのサブプログラム３１が記述される場所の数は、保護すべきウェブページ３０の数に比例することになる。
【特許文献１】特表2004-514996号公報（第２−７頁、図１）
【非特許文献１】高木浩光、“Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策”、［online］、2003年7月17日、［平成１７年２月７日検索］、インターネット＜URL：http://securit.gtrc.aist.go.jp/research/paper/AIST03-J00017/＞
【非特許文献２】情報処理振興事業協会セキュリティセンター、“経路のセキュリティと同時にセキュアなセッション管理を−ＳＳＬ／ＴＬＳでクッキーを使うときは、secure属性を付けるのを基本とする−”、［online］、2003年8月14日、独立行政法人情報処理推進機構（ＩＰＡ）、［平成１７年２月７日検索］、インターネット＜URL：http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html＞
【非特許文献３】Ja-Jakarta Project 掲示板、“セッションハイジャック”、［online］、2004年1月29日、Ja-Jakarta Project、［平成１７年２月７日検索］、インターネット＜URL：http://www.jajakarta.org/kvasir/bbs/technical/480?expand=true＞
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上述したように、非保護のセッション維持クッキーのみを用いて保護されたウェブページと非保護のウェブページの両方に対するセッションを維持する方法は、非特許文献１で述べられているセキュリティホールを持ち、その対策として、上記１）のように全てのウェブページを保護されたウェブページとして扱うことは、ウェブサイトの実行効率の著しい劣化を伴う。そこで、上記２）のようにセッション維持のための非保護のクッキーと、保護されたウェブページにおける認証のための保護されたオースコードクッキーとを併用する必要がある。
【００１７】
しかしながら、上記２）の方法では、非特許文献３で述べられているように、また図４で示したように、ウェブサイト内の保護すべきウェブページ全てに対してセッション認証の処理を記述する必要があり、プログラムの作成効率に著しい劣化が発生することが予想され、その対策が望まれている。
【００１８】
本発明は、このような従来の事情を考慮してなされたもので、セッション維持中に保護されたウェブページと非保護のウェブページとの行き来が可能な大規模なウェブサイトでも、安全なセッション管理を実現しつつ、プログラムの実行効率と作成効率に著しい劣化を伴わないようにすることを目的とする。
【課題を解決するための手段】
【００１９】
上記目的を達成するため、本発明に係るウェブサイトのための安全なセッション管理用プログラムは、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するプログラムであって、コンピュータに、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを実行させることを特徴とする。
【００２０】
本発明に係るセッション管理用プログラムにおいて、前記前処理を行うステップは、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有してもよい。また、前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有してもよい。
【００２１】
本発明に係るウェブサイトのための安全なセッション管理方法は、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理する方法であって、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを有することを特徴とする。
【００２２】
本発明に係るセッション管理方法において、前記前処理を行うステップは、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有してもよい。また、前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有してもよい。
【００２３】
本発明に係るウェブサイトのための安全なセッション管理システムは、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するシステムであって、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行う手段と、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行う前処理手段とを有することを特徴とする。
【００２４】
本発明に係るウェブサイトのための安全なセッション管理システムにおいて、前記前処理手段は、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別する手段と、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証する手段とを有してもよい。また、前記前処理手段は、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄する手段を有してもよい。
【発明の効果】
【００２５】
本発明によれば、セッション維持中に保護されたウェブページと非保護のウェブページとの行き来が可能な大規模なウェブサイトでも、安全なセッション管理を実現しつつ、プログラム作成量を削減し、プログラム実行効率を改善することが可能となる。とくに、プログラム作成量の削減効果は、ウェブサイト上の保護すべきウェブページの数が十分多い程、より一層発揮させることができる。また、プログラム実行効率の改善効果は、ウェブサイト上の非保護のウェブページの利用頻度が一定以上ある程、より一層発揮させることができる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明に係るウェブサイトのための安全なセッション管理用プログラム、セッション管理方法、及びセッション管理システムを実施するための最良の形態について図面を参照して詳細に説明する。
【００２７】
図１を参照すると、本実施例のウェブサイトのための安全なセッション管理システムは、ウェブサイトのＨＴＭＬ（HyperText Markup Language）等のウェブページ記述言語で記述されたウェブページ２２を管理するウェブサーバ１２と、ウェブページ２２へアクセスするためのウェブクライアント１６と、両者１２、１６を通信可能に結ぶ通信チャネル１４とを備える。通信チャネル１４は、例えばインターネット等のＴＣＰ／ＩＰに基づく通信ネットワークから成る。
【００２８】
ウェブクライアント１６は、通信チャネル１４を介してウェブサーバ１２との間でＴＣＰ／ＩＰに基づき通信を行い、ウェブサーバ１２により提供されるウェブサイトのウェブページ２２を閲覧可能な機能を有するウェブブラウザ（図示しない）を実行可能なコンピュータ機であれば、いずれの構成でも適用可能である。適用されるコンピュータ機では、ハードウェア構成上、例えばＣＰＵ、メモリ等の記録装置、通信チャネル１４用の通信装置（電話回線で用いるモデム装置、ＬＡＮで用いる通信インターフェース等）、表示装置（ＣＲＴや液晶ディスプレイ等）等を備え、ＣＰＵがメモリに配置されるウェブブラウザ等のプログラムを実行可能となっている。
【００２９】
ウェブサーバ１２は、ウェブサイトのウェブページ２２を管理するウェブサーバソフトウェアを実行可能なコンピュータマシンであれば、いずれの構成でも適用可能である。適用されるコンピュータ機では、ハードウェア構成上、例えばＣＰＵ、メモリ等の記録装置、通信チャネル１４用の通信装置（電話回線で用いるモデム装置、ＬＡＮで用いる通信インターフェース等）等を備え、ＣＰＵがメモリに配置されるウェブサーバソフトウェア等のプログラムを実行可能となっている。
【００３０】
このウェブサーバ１２は、ＣＰＵがプログラムを実行することで実現される機能上の構成として、図１に示すように、前処理機構１００、要求判別機構１０１、プロトコル機構１０２、セッション管理機構１０３、要求管理機構１０４、クッキー管理機構１０５、及びオースコード生成機構１０６とを有している。これら各機構１００〜１０６の機能を実現させるためのプログラムの例として、本実施例では例えばJava（登録商標、以下省略） Servlet APIに基づくプログラムが適用可能であるが、本発明はそれに限るものではない。
【００３１】
ウェブページ２２は、図１に示すように、保護すべきウェブページ３０と、非保護でも構わないウェブページ２８とから構成されている。保護されたウェブページ２８の参照に際して、本実施例では、セッションが有効かどうか確認するためにsecure属性をもつクッキーである「オースコードクッキー」が用いられる。オースコードクッキーの例としては、次のものがある。
【００３２】
session.authCode=200502081437-001; domain=sample.domain.com; path=/; secure
この例では、オースコードとして「200502081437-001」、domain属性として「sample.domain.com」、path属性として「/」が指定され、secure属性が付加されている。
【００３３】
前処理機構１００は、要求されたウェブページ２２に応じて事前に構成されたプログラムを呼び出し、その結果によって実際に処理するウェブページ２２を変更する。これは、ウェブページ２２の生成にあたって前処理をプラグインする機構であり、本実施例では例えばJava Servlet仕様のフィルター機構が適用可能であるが、本発明はそれに限るものではない。
【００３４】
要求判別機構１０１は、要求されたウェブページ２２が保護すべきウェブページ３０なのか非保護でも構わないウェブページ２８なのかを判別する。これは、要求されたウェブページが保護すべきウェブページなのか非保護でも構わないウェブページなのかの判別機構であり、本実施例では、例えば要求されたウェブページのＵＲＬを取得する手段とあらかじめ用意したデータベースとの組が適用可能であるが、それらに限るものではない。
【００３５】
プロトコル機構１０２は、要求されたウェブページ２２が保護された通信プロトコル（例えば、ＨＴＴＰＳ）によるものなのか、非保護な通信プロトコル（例えば、ＨＴＴＰ）によるものなのかを判別する。これは、要求されたウェブページ２２が保護された通信プロトコルによるものなのか、非保護な通信プロトコルによるものなのかを判別する機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequest.isSecure()が適用可能であるが、本発明はそれに限るものではない。
【００３６】
非保護の通信プロトコルと保護されている通信プロトコルとの組としては、ＨＴＴＰと、これをＳＳＬでラップしたＨＴＴＰＳとの組のほか、ＮＮＴＰ（Network News Transfer Protocol）、ＦＴＰ（File Transfer Protocol）、ＳＮＭＰ（Simple Network Management Protocol）などのプロトコルと、それらをＳＳＬでラップしたプロトコルとの組を例示できる。
【００３７】
セッション管理機構１０３は、非保護のクッキーにより属性を保持できるセッションの生成・保持・破棄を行う。これは、クッキーにより実装されていて属性を保持できるセッションを生成・保持・破棄する機構であり、本実施例では、例えばJava Servlet APIのHttpSessionが適用可能であるが、本発明はそれに限るものではない。
【００３８】
要求管理機構１０４は、ウェブクライアントからの要求に対して属性を設定・参照する。これは、ウェブクライアントからの要求に対して属性を設定・参照できる要求管理の機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequestが適用可能であるが、本発明はそれに限るものではない。
【００３９】
クッキー管理機構１０５は、ウェブクライアントに対してsecure属性を持ったクッキーを発行・参照する。これは、ウェブクライアントに対してsecure属性を持ったクッキーを発行・参照できる機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequestクラス・HttpServletResponseクラス、ならびにCookieクラスが適用可能であるが、本発明はそれに限るものではない。
【００４０】
オースコード生成機構１０６は、時刻や乱数などを用いて、系外から容易に推測できないオースコードを生成する。
【００４１】
次に、図２及び図３のフローチャートを参照して、本実施例の全体動作について詳細に説明する。
【００４２】
図２は、ウェブサーバ１２がウェブクライアント１６から要求されたウェブページ２２を処理する前に呼び出されるプログラムの処理の流れを表した図である。このプログラムの処理は、前処理機構１００によって挿入されるもので、ウェブクライアント１６からウェブサーバ１２に対してウェブページが要求されるたびに呼び出される。
【００４３】
まず、ウェブサーバ１２は、ウェブクライアント１６から要求を受けると、要求判別機構１０１によって、要求されたウェブページ２２を、保護すべきウェブページ３０であるか、非保護で構わないウェブページ２８であるかを判定する（ステップＳｔ１）。その結果、非保護で構わないウェブページ２８である場合（ステップＳｔ１：ＮＯ）、それ以上の前処理を行わず、要求されたウェブページをそのまま処理する（ステップＳｔ１０）。
【００４４】
また、保護すべきウェブページ３０である場合（ステップＳｔ１：ＹＥＳ）、プロトコル判別機構１０２によって、要求が通信チャネル１４上を保護された通信プロトコルで通過したのか、非保護の通信プロトコルで通過したのかを判定する（ステップＳｔ２）。その結果、非保護のプロトコルで通過していた場合（ステップＳｔ２：ＮＯ）、保護すべきウェブページ３０の内容を非保護のプロトコルで返信しないために、セッションを破棄して異常をウェブクライアント１６に返却する（ステップＳｔ４）。この際、保護されたプロトコルでアクセスすべき旨をクライアント１６に伝える。
【００４５】
また、保護された通信プロトコルで通過していた場合（ステップＳｔ２：ＹＥＳ）、セッション管理機構１０３によって、セッションのオースコード属性を参照しオースコードが存在するかどうか判定する（ステップＳｔ３）。セッションのオースコード属性の例としては、例えば要求管理機構１０４としてJava Servlet APIのHttpServletRequestを用いる場合には、ServletRequest#setAttributeメソッドの第一引数に文字列リテラル"session.authCode"を、第二引数に「オースコード」の文字列表現"200502081419-001"を与えて得られるサーブレット要求属性がある。
【００４６】
上記ステップＳｔ３の処理によりオースコードが存在せずにセッションがオースコード属性を保持していない場合（ステップＳｔ３：ＮＯ）は、要求管理機構１０４によって、ウェブクライアント１６からの当該要求に対して認証済み属性を設定する（ステップＳｔ６）と共に、図３で述べる方法でセッションを認証済みの状態に昇格し（ステップＳｔ７）、それ以上の前処理を行わない（ステップＳｔ１０）。上記ステップＳｔ３がＮＯの場合は、例えばセッションの１回目のアクセス時に対応する。
【００４７】
認証済み属性の例としては、要求管理機構１０４としてJava Servlet APIのHttpServletRequestを用いる場合には、ServletRequest#setAttribute メソッドの第一引数に文字列リテラル"session.authorized"を、第二引数に「真」の文字列表現"true"を与えて得られるサーブレット要求属性を例示できる。
【００４８】
図３は、図２のステップＳｔ７でセッションを認証済みの状態に昇格する際の処理の流れを表した図である。まず、オースコード生成機構１０６によって、当該セッションに対するオースコードを生成する（ステップＳｔ１１）。次に、セッション管理機構１０３によって、セッションのオースコード属性に、ステップＳｔ１１で生成したオースコードを設定する（ステップＳｔ１２）。最後に、クッキー管理機構１０５によって、ステップＳｔ１１で生成したオースコードを値とするオースコードクッキーをウェブクライアント１６に発行する（ステップＳｔ１３）。
【００４９】
次いで、図２に戻り、上記ステップＳｔ３の処理によりオースコードが存在してセッションがオースコード属性を保持している場合（ステップＳｔ３：ＹＥＳ）は、要求管理機構１０４によって、ウェブクライアント１６からの当該要求に対する認証済み属性を参照し認証済みとマークされているかどうか判定する（ステップＳｔ５）。その結果、当該要求に対し認証済みとマークされ、認証済み属性が既に設定されている場合（ステップＳｔ５：ＹＥＳ）、それ以上の前処理を行わない（ステップＳｔ１０）。上記ステップＳｔ３がＹＥＳの場合は、例えばセッションの２回目以降のアクセス時に対応する。
【００５０】
次いで、上記当該要求に対し認証済みとマークされず、認証済み属性が設定されていない場合（ステップＳｔ５：ＹＥＳ）、クッキー管理機構１０５によって、ウェブクライアント１６からの当該要求に対するオースコードクッキーを参照しそのオースコードクッキーが存在するかどうか判定する（ステップＳｔ８）。その結果、オースコードクッキーが存在しない場合（ステップＳｔ８：ＮＯ）、上記ステップＳｔ４に移行して上述した異常系処理を行う（ステップＳｔ４）。
【００５１】
次いで、上記ステップＳｔ８の処理によりオースコードクッキーが存在する場合（ステップＳｔ８：ＹＥＳ）、上記ステップＳｔ３の処理で参照したセッションのオースコード属性と、上記ステップＳｔ８の処理で参照したオースコードクッキーの値とを比較し、両オースコードが等しいかどうか判定する（ステップＳｔ９）。その結果、両オースコードの値が異なる場合（ステップＳｔ９：ＮＯ）、上記ステップＳｔ４に移行して上述した異常系処理を行う（ステップＳｔ４）。一方、両オースコードの値が等しければ（ステップＳｔ９：ＹＥＳ）、それ以上の前処理を行わない（ステップＳｔ１０）。
【００５２】
従って、本実施例によれば、保護すべきウェブページ３０をアクセスする際には、初回を除き２回目以降はオースコードクッキーによるセッションの認証を行っており、オースコードクッキーは保護された通信プロトコルの場合にのみ発行しており、オースコードクッキーにはsecure属性を与えているため、ウェブサイトのための安全なセッション管理を実現できる。
【００５３】
また、本実施例によれば、非保護でも構わないウェブページ２８について非保護の通信プロトコルでの送受信を許容しているため、ウェブサイトのための安全なセッション管理の実現にあたって、全てのウェブページ２２を保護された通信プロトコルで送受信する場合に比べて、ウェブサイトの実行効率劣化を低減できる。
【００５４】
さらに、本実施例によれば、セッションの認証処理を個々の保護すべきウェブページ３０ごとに記述するのではなく、ウェブページ全体で共通のサブプログラムを前処理機構で処理させているため、保護すべきウェブページ３０の数が多くとも、ウェブサイトのための安全なセッション管理の実現にあたって、セッションを認証するための処理を記述する箇所が多くならない。
【００５５】
以上説明したように、本実施例によれば、ウェブサーバ１２によるウェブサイトとウェブクライアント１６の間のセッション管理の内、全てのページで共通化できる部分のプログラム及びこれで用いるデータを前処理機構１００、すなわちウェブページ２２の生成にあたって前処理をプラグインする機構によって集中管理するよう構成したため、セッション維持のための処理を記述する箇所を削減でき、プログラムの作成効率の低下を大幅に抑止することができる。
【産業上の利用可能性】
【００５６】
本発明によれば、電子商取引分野における安全なセッション管理を従来よりも容易に実現するためのプログラムといった用途に適用できる。また、電子政府による証明書の発行分野における安全なセッション管理を従来よりも容易に実現するためのプログラムといった用途にも適用可能である。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施例に係るウェブサイトのための安全なセッション管理システムの構成を示す図である。
【図２】要求されたウェブページを処理する前の処理を説明するフローチャートである。
【図３】図２のセッションを認証済みの状態に昇格する際の処理（ステップＳｔ７）の詳細を説明するフローチャートである。
【図４】従来例に係るシステムの構成を示す図である。
【符号の説明】
【００５８】
１２ ウェブサーバ
１４ 通信チャネル
１６ ウェブクライアント
２２ ウェブページ
１００ 前処理機構
１０１ 要求判別機構
１０２ 通信プロトコル判別機構
１０３ セッション管理機構
１０４ 要求管理機構
１０５ クッキー管理機構
１０６ オースコード生成機構
【技術分野】
【０００１】
本発明は、ウェブサイトのための安全なセッション管理用プログラム、セッション管理方法、及びセッション管理システムに関する。
【背景技術】
【０００２】
近年、インターネットに代表される通信ネットワークの利用増大に伴い、ネットワーク上のウェブサイトを用いた電子商取引も盛んに行われるようになっている。このような電子商取引では、ウェブサイトを成すウェブページを生成し維持するウェブサーバと、ウェブサイトにアクセスするウェブブラウザをもつウェブクライアントとの間でネットワークを介して通信が行われる。ウェブページにアクセスする際に用いる通信プロトコルには、通常、ＨＴＴＰ（HyperText Transfer Protocol）が使用されるが、個人情報やクレジットカード番号等を安全にやり取りする場合には、ＨＴＴＰにＳＳＬ（Secure Socket Layer）によるデータの暗号化機能を付加したＨＴＴＰＳ（Hypertext Transfer Protocol Security）も使用される。
【０００３】
ＨＴＴＰは、要求とその応答の１組で完結するステートレスなプロトコルである。このため、ＨＴＴＰを用いて、ユーザがウェブクライアントからウェブサイトのネットワーク上の所在を示すＵＲＬ（Uniform Resource Locator）を指定してそのウェブページにログインしてからログアウトするまでの同一ユーザによる一連のアクセス、すなわち同一ユーザによるセッションを識別し、そのセッションを追跡・維持するため、クッキー機能を利用することが多い。
【０００４】
クッキーを使用する場合、ウェブブラウザの画面上でユーザ名とパスワードが入力され、ログイン実行ボタンが押されると、サーバは、入力されたユーザ名とパスワード、又はその暗号化されたデータ、或いは登録されたユーザであることが確認された場合のみに乱数により発行されるセッションＩＤを入れたクッキーを応答ヘッダ内に記述されるデータとして発行する。それ以降、ウェブブラウザは、アクセス毎に応答ヘッダ内にそのデータを入れて送出するので、サーバはそのクッキーのデータに基づきユーザを特定し、そのユーザに対し一貫性のあるデータ処理及びサービス提供を行うことができる。
【０００５】
この場合、安全なアクセス制御のためには、パケット盗聴等によりクッキーが第三者に盗まれるといった事態を回避する必要がある。そのため、ＨＴＴＰに基づいてウェブサーバによりウェブクライアントに発行されるクッキーには、name属性、path属性、domain属性等のほか、オプションとしてsecure属性を指定できるようになっている。
【０００６】
secure属性が指定されていないクッキーは、通信プロトコルがＨＴＴＰの場合でも、ＨＴＴＰＳの場合でも、送出される。すなわち、ＵＲＬが「http://」で始まる非保護のウェブページにアクセスする場合でも、「https://」で始まる保護されたウェブページにアクセスする場合でも、いずれの場合でもクッキーデータが通信路上に流れる。これに対し、secure属性が指定されたクッキーは、通信プロトコルがＨＴＴＰＳの場合のみ送出され、ＨＴＴＰの場合では送出されない。すなわち、ＵＲＬが「https://」で始まる保護されたウェブページにアクセスする場合のみにクッキーデータが通信路上に流れ、「http://」で始まる非保護のウェブページにアクセスする場合には、クッキーデータが通信路上に流れない。
【０００７】
しかしながら、クッキーを用いたアクセス制御に際し、上記secure属性による機能が正しく使用されず、例えばクッキーが暗号化されずにネットワークに流れる等の事態が生じると、第三者がクッキーデータを盗聴することによってユーザのログイン状態（セッション）を乗っ取ることが可能となり、最悪の場合、パスワード等の個人情報を不正に閲覧したり、クレジットカード番号を盗み出したりする等、不都合な事態が生じる恐れがある（例えば、非特許文献１参照）。
【０００８】
このようなセッション維持のために使用されるクッキー（セッション維持クッキー）のデータ盗聴によるセッションの乗っ取りを回避する対策として、従来、ウェブサイトのための安全なセッション管理を行うシステム及び方法の一例が提案されている（例えば、特許文献１、非特許文献１、２参照）。
【０００９】
例えば、非特許文献１では、セッション維持クッキーを用いているウェブサイトにおいて、セッションの乗っ取りを避けた安全なセッション管理として、次の二つの方法が記載されている。
【００１０】
１）ウェブページとセッション維持クッキーの全てを保護されたウェブページ及び保護されたクッキーとする。すなわち、ウェブサイトの全てのウェブページが「https://」で始まるＵＲＬをもち、クッキーにはsecure属性が付加されるようにする。
【００１１】
２）保護されたウェブページでセッションを認証するために、非保護のセッション維持クッキーとは別に、保護されたクッキー（オースコードクッキー）を用意し、セッションを認証する。すなわち、２つのクッキーを用意し、１つ目のクッキーにはsecure属性を付加せず、２つ目のクッキーにはsecure属性を付加し、両者ともにランダムに生成されるセッションＩＤを与え、どちらのセッションＩＤからでもユーザを特定できるようにする。これにより、「https://」のウェブページではsecure属性が付加された２つ目のクッキーからユーザを特定すると共に、「http://」のウェブページではsecure属性が付加されない１つ目のクッキーからユーザを特定する。そうすると、仮に１つ目のsecure属性が付加されないクッキーが盗聴されても、それが「https://」のウェブページに入るのに必要なセッションＩＤではないため、ＳＳＬで保護されているウェブページの情報にアクセスすることはできない。
【００１２】
上記二つの方法のうち、１）の方法を用いると、非特許文献３でも指摘されているように、全てのウェブページを保護されたウェブページとして扱うため、すべての通信をＳＳＬで行うことでオーバーヘッドが大きくなる等、ウェブサイトの実行効率に著しい劣化が発生してしまう可能性がある。
【００１３】
そこで、現実的な方法としては、２）の方法を用いて、セッション維持のための非保護のクッキーと、保護されたウェブページにおける認証のための保護されたオースコードクッキーとを併用する必要がある。この例を図４に基づいて説明する。
【００１４】
図４に示すウェブサイトのための安全なセッション管理を行うシステムは、ウェブサイトを管理するウェブサーバ１２と、ウェブサイトにアクセスするウェブクライアント１６と、両者１２、１６を通信可能に接続するインターネット等のＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）に基づくネットワークから成る通信チャネル（通信路）１４とから構成されている。ウェブサーバ１２は、ソフトウェア構成上、ウェブサーバソフトウェア１８と、ウェブサーバソフトウェア１８により管理されるウェブサイトを成すウェブページ２２とを有している。ウェブページ２２には、保護すべきウェブページ３０と、非保護でも構わないウェブページ２８とが含まれる。
【００１５】
このような構成を有する従来のシステムにおいて、保護すべきウェブページ３０は、そのデータの送受信にあたってセッションの認証を行う必要があるため、ウェブページ３０内に記述されるサブプログラム３１によって応答が生成される。すなわち、保護すべきウェブページ３０の応答を生成するサブプログラム３１全てでセッションの認証処理を行う必要があり、その結果、ウェブページ３０内のセッションの認証を行うためのサブプログラム３１が記述される場所の数は、保護すべきウェブページ３０の数に比例することになる。
【特許文献１】特表2004-514996号公報（第２−７頁、図１）
【非特許文献１】高木浩光、“Cookie盗聴によるWebアプリケーションハイジャックの危険性とその対策”、［online］、2003年7月17日、［平成１７年２月７日検索］、インターネット＜URL：http://securit.gtrc.aist.go.jp/research/paper/AIST03-J00017/＞
【非特許文献２】情報処理振興事業協会セキュリティセンター、“経路のセキュリティと同時にセキュアなセッション管理を−ＳＳＬ／ＴＬＳでクッキーを使うときは、secure属性を付けるのを基本とする−”、［online］、2003年8月14日、独立行政法人情報処理推進機構（ＩＰＡ）、［平成１７年２月７日検索］、インターネット＜URL：http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html＞
【非特許文献３】Ja-Jakarta Project 掲示板、“セッションハイジャック”、［online］、2004年1月29日、Ja-Jakarta Project、［平成１７年２月７日検索］、インターネット＜URL：http://www.jajakarta.org/kvasir/bbs/technical/480?expand=true＞
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上述したように、非保護のセッション維持クッキーのみを用いて保護されたウェブページと非保護のウェブページの両方に対するセッションを維持する方法は、非特許文献１で述べられているセキュリティホールを持ち、その対策として、上記１）のように全てのウェブページを保護されたウェブページとして扱うことは、ウェブサイトの実行効率の著しい劣化を伴う。そこで、上記２）のようにセッション維持のための非保護のクッキーと、保護されたウェブページにおける認証のための保護されたオースコードクッキーとを併用する必要がある。
【００１７】
しかしながら、上記２）の方法では、非特許文献３で述べられているように、また図４で示したように、ウェブサイト内の保護すべきウェブページ全てに対してセッション認証の処理を記述する必要があり、プログラムの作成効率に著しい劣化が発生することが予想され、その対策が望まれている。
【００１８】
本発明は、このような従来の事情を考慮してなされたもので、セッション維持中に保護されたウェブページと非保護のウェブページとの行き来が可能な大規模なウェブサイトでも、安全なセッション管理を実現しつつ、プログラムの実行効率と作成効率に著しい劣化を伴わないようにすることを目的とする。
【課題を解決するための手段】
【００１９】
上記目的を達成するため、本発明に係るウェブサイトのための安全なセッション管理用プログラムは、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するプログラムであって、コンピュータに、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを実行させることを特徴とする。
【００２０】
本発明に係るセッション管理用プログラムにおいて、前記前処理を行うステップは、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有してもよい。また、前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有してもよい。
【００２１】
本発明に係るウェブサイトのための安全なセッション管理方法は、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理する方法であって、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを有することを特徴とする。
【００２２】
本発明に係るセッション管理方法において、前記前処理を行うステップは、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有してもよい。また、前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有してもよい。
【００２３】
本発明に係るウェブサイトのための安全なセッション管理システムは、保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するシステムであって、前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行う手段と、要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行う前処理手段とを有することを特徴とする。
【００２４】
本発明に係るウェブサイトのための安全なセッション管理システムにおいて、前記前処理手段は、前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別する手段と、前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証する手段とを有してもよい。また、前記前処理手段は、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄する手段を有してもよい。
【発明の効果】
【００２５】
本発明によれば、セッション維持中に保護されたウェブページと非保護のウェブページとの行き来が可能な大規模なウェブサイトでも、安全なセッション管理を実現しつつ、プログラム作成量を削減し、プログラム実行効率を改善することが可能となる。とくに、プログラム作成量の削減効果は、ウェブサイト上の保護すべきウェブページの数が十分多い程、より一層発揮させることができる。また、プログラム実行効率の改善効果は、ウェブサイト上の非保護のウェブページの利用頻度が一定以上ある程、より一層発揮させることができる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明に係るウェブサイトのための安全なセッション管理用プログラム、セッション管理方法、及びセッション管理システムを実施するための最良の形態について図面を参照して詳細に説明する。
【００２７】
図１を参照すると、本実施例のウェブサイトのための安全なセッション管理システムは、ウェブサイトのＨＴＭＬ（HyperText Markup Language）等のウェブページ記述言語で記述されたウェブページ２２を管理するウェブサーバ１２と、ウェブページ２２へアクセスするためのウェブクライアント１６と、両者１２、１６を通信可能に結ぶ通信チャネル１４とを備える。通信チャネル１４は、例えばインターネット等のＴＣＰ／ＩＰに基づく通信ネットワークから成る。
【００２８】
ウェブクライアント１６は、通信チャネル１４を介してウェブサーバ１２との間でＴＣＰ／ＩＰに基づき通信を行い、ウェブサーバ１２により提供されるウェブサイトのウェブページ２２を閲覧可能な機能を有するウェブブラウザ（図示しない）を実行可能なコンピュータ機であれば、いずれの構成でも適用可能である。適用されるコンピュータ機では、ハードウェア構成上、例えばＣＰＵ、メモリ等の記録装置、通信チャネル１４用の通信装置（電話回線で用いるモデム装置、ＬＡＮで用いる通信インターフェース等）、表示装置（ＣＲＴや液晶ディスプレイ等）等を備え、ＣＰＵがメモリに配置されるウェブブラウザ等のプログラムを実行可能となっている。
【００２９】
ウェブサーバ１２は、ウェブサイトのウェブページ２２を管理するウェブサーバソフトウェアを実行可能なコンピュータマシンであれば、いずれの構成でも適用可能である。適用されるコンピュータ機では、ハードウェア構成上、例えばＣＰＵ、メモリ等の記録装置、通信チャネル１４用の通信装置（電話回線で用いるモデム装置、ＬＡＮで用いる通信インターフェース等）等を備え、ＣＰＵがメモリに配置されるウェブサーバソフトウェア等のプログラムを実行可能となっている。
【００３０】
このウェブサーバ１２は、ＣＰＵがプログラムを実行することで実現される機能上の構成として、図１に示すように、前処理機構１００、要求判別機構１０１、プロトコル機構１０２、セッション管理機構１０３、要求管理機構１０４、クッキー管理機構１０５、及びオースコード生成機構１０６とを有している。これら各機構１００〜１０６の機能を実現させるためのプログラムの例として、本実施例では例えばJava（登録商標、以下省略） Servlet APIに基づくプログラムが適用可能であるが、本発明はそれに限るものではない。
【００３１】
ウェブページ２２は、図１に示すように、保護すべきウェブページ３０と、非保護でも構わないウェブページ２８とから構成されている。保護されたウェブページ２８の参照に際して、本実施例では、セッションが有効かどうか確認するためにsecure属性をもつクッキーである「オースコードクッキー」が用いられる。オースコードクッキーの例としては、次のものがある。
【００３２】
session.authCode=200502081437-001; domain=sample.domain.com; path=/; secure
この例では、オースコードとして「200502081437-001」、domain属性として「sample.domain.com」、path属性として「/」が指定され、secure属性が付加されている。
【００３３】
前処理機構１００は、要求されたウェブページ２２に応じて事前に構成されたプログラムを呼び出し、その結果によって実際に処理するウェブページ２２を変更する。これは、ウェブページ２２の生成にあたって前処理をプラグインする機構であり、本実施例では例えばJava Servlet仕様のフィルター機構が適用可能であるが、本発明はそれに限るものではない。
【００３４】
要求判別機構１０１は、要求されたウェブページ２２が保護すべきウェブページ３０なのか非保護でも構わないウェブページ２８なのかを判別する。これは、要求されたウェブページが保護すべきウェブページなのか非保護でも構わないウェブページなのかの判別機構であり、本実施例では、例えば要求されたウェブページのＵＲＬを取得する手段とあらかじめ用意したデータベースとの組が適用可能であるが、それらに限るものではない。
【００３５】
プロトコル機構１０２は、要求されたウェブページ２２が保護された通信プロトコル（例えば、ＨＴＴＰＳ）によるものなのか、非保護な通信プロトコル（例えば、ＨＴＴＰ）によるものなのかを判別する。これは、要求されたウェブページ２２が保護された通信プロトコルによるものなのか、非保護な通信プロトコルによるものなのかを判別する機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequest.isSecure()が適用可能であるが、本発明はそれに限るものではない。
【００３６】
非保護の通信プロトコルと保護されている通信プロトコルとの組としては、ＨＴＴＰと、これをＳＳＬでラップしたＨＴＴＰＳとの組のほか、ＮＮＴＰ（Network News Transfer Protocol）、ＦＴＰ（File Transfer Protocol）、ＳＮＭＰ（Simple Network Management Protocol）などのプロトコルと、それらをＳＳＬでラップしたプロトコルとの組を例示できる。
【００３７】
セッション管理機構１０３は、非保護のクッキーにより属性を保持できるセッションの生成・保持・破棄を行う。これは、クッキーにより実装されていて属性を保持できるセッションを生成・保持・破棄する機構であり、本実施例では、例えばJava Servlet APIのHttpSessionが適用可能であるが、本発明はそれに限るものではない。
【００３８】
要求管理機構１０４は、ウェブクライアントからの要求に対して属性を設定・参照する。これは、ウェブクライアントからの要求に対して属性を設定・参照できる要求管理の機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequestが適用可能であるが、本発明はそれに限るものではない。
【００３９】
クッキー管理機構１０５は、ウェブクライアントに対してsecure属性を持ったクッキーを発行・参照する。これは、ウェブクライアントに対してsecure属性を持ったクッキーを発行・参照できる機構であり、本実施例では、例えばJava Servlet APIのHttpServletRequestクラス・HttpServletResponseクラス、ならびにCookieクラスが適用可能であるが、本発明はそれに限るものではない。
【００４０】
オースコード生成機構１０６は、時刻や乱数などを用いて、系外から容易に推測できないオースコードを生成する。
【００４１】
次に、図２及び図３のフローチャートを参照して、本実施例の全体動作について詳細に説明する。
【００４２】
図２は、ウェブサーバ１２がウェブクライアント１６から要求されたウェブページ２２を処理する前に呼び出されるプログラムの処理の流れを表した図である。このプログラムの処理は、前処理機構１００によって挿入されるもので、ウェブクライアント１６からウェブサーバ１２に対してウェブページが要求されるたびに呼び出される。
【００４３】
まず、ウェブサーバ１２は、ウェブクライアント１６から要求を受けると、要求判別機構１０１によって、要求されたウェブページ２２を、保護すべきウェブページ３０であるか、非保護で構わないウェブページ２８であるかを判定する（ステップＳｔ１）。その結果、非保護で構わないウェブページ２８である場合（ステップＳｔ１：ＮＯ）、それ以上の前処理を行わず、要求されたウェブページをそのまま処理する（ステップＳｔ１０）。
【００４４】
また、保護すべきウェブページ３０である場合（ステップＳｔ１：ＹＥＳ）、プロトコル判別機構１０２によって、要求が通信チャネル１４上を保護された通信プロトコルで通過したのか、非保護の通信プロトコルで通過したのかを判定する（ステップＳｔ２）。その結果、非保護のプロトコルで通過していた場合（ステップＳｔ２：ＮＯ）、保護すべきウェブページ３０の内容を非保護のプロトコルで返信しないために、セッションを破棄して異常をウェブクライアント１６に返却する（ステップＳｔ４）。この際、保護されたプロトコルでアクセスすべき旨をクライアント１６に伝える。
【００４５】
また、保護された通信プロトコルで通過していた場合（ステップＳｔ２：ＹＥＳ）、セッション管理機構１０３によって、セッションのオースコード属性を参照しオースコードが存在するかどうか判定する（ステップＳｔ３）。セッションのオースコード属性の例としては、例えば要求管理機構１０４としてJava Servlet APIのHttpServletRequestを用いる場合には、ServletRequest#setAttributeメソッドの第一引数に文字列リテラル"session.authCode"を、第二引数に「オースコード」の文字列表現"200502081419-001"を与えて得られるサーブレット要求属性がある。
【００４６】
上記ステップＳｔ３の処理によりオースコードが存在せずにセッションがオースコード属性を保持していない場合（ステップＳｔ３：ＮＯ）は、要求管理機構１０４によって、ウェブクライアント１６からの当該要求に対して認証済み属性を設定する（ステップＳｔ６）と共に、図３で述べる方法でセッションを認証済みの状態に昇格し（ステップＳｔ７）、それ以上の前処理を行わない（ステップＳｔ１０）。上記ステップＳｔ３がＮＯの場合は、例えばセッションの１回目のアクセス時に対応する。
【００４７】
認証済み属性の例としては、要求管理機構１０４としてJava Servlet APIのHttpServletRequestを用いる場合には、ServletRequest#setAttribute メソッドの第一引数に文字列リテラル"session.authorized"を、第二引数に「真」の文字列表現"true"を与えて得られるサーブレット要求属性を例示できる。
【００４８】
図３は、図２のステップＳｔ７でセッションを認証済みの状態に昇格する際の処理の流れを表した図である。まず、オースコード生成機構１０６によって、当該セッションに対するオースコードを生成する（ステップＳｔ１１）。次に、セッション管理機構１０３によって、セッションのオースコード属性に、ステップＳｔ１１で生成したオースコードを設定する（ステップＳｔ１２）。最後に、クッキー管理機構１０５によって、ステップＳｔ１１で生成したオースコードを値とするオースコードクッキーをウェブクライアント１６に発行する（ステップＳｔ１３）。
【００４９】
次いで、図２に戻り、上記ステップＳｔ３の処理によりオースコードが存在してセッションがオースコード属性を保持している場合（ステップＳｔ３：ＹＥＳ）は、要求管理機構１０４によって、ウェブクライアント１６からの当該要求に対する認証済み属性を参照し認証済みとマークされているかどうか判定する（ステップＳｔ５）。その結果、当該要求に対し認証済みとマークされ、認証済み属性が既に設定されている場合（ステップＳｔ５：ＹＥＳ）、それ以上の前処理を行わない（ステップＳｔ１０）。上記ステップＳｔ３がＹＥＳの場合は、例えばセッションの２回目以降のアクセス時に対応する。
【００５０】
次いで、上記当該要求に対し認証済みとマークされず、認証済み属性が設定されていない場合（ステップＳｔ５：ＹＥＳ）、クッキー管理機構１０５によって、ウェブクライアント１６からの当該要求に対するオースコードクッキーを参照しそのオースコードクッキーが存在するかどうか判定する（ステップＳｔ８）。その結果、オースコードクッキーが存在しない場合（ステップＳｔ８：ＮＯ）、上記ステップＳｔ４に移行して上述した異常系処理を行う（ステップＳｔ４）。
【００５１】
次いで、上記ステップＳｔ８の処理によりオースコードクッキーが存在する場合（ステップＳｔ８：ＹＥＳ）、上記ステップＳｔ３の処理で参照したセッションのオースコード属性と、上記ステップＳｔ８の処理で参照したオースコードクッキーの値とを比較し、両オースコードが等しいかどうか判定する（ステップＳｔ９）。その結果、両オースコードの値が異なる場合（ステップＳｔ９：ＮＯ）、上記ステップＳｔ４に移行して上述した異常系処理を行う（ステップＳｔ４）。一方、両オースコードの値が等しければ（ステップＳｔ９：ＹＥＳ）、それ以上の前処理を行わない（ステップＳｔ１０）。
【００５２】
従って、本実施例によれば、保護すべきウェブページ３０をアクセスする際には、初回を除き２回目以降はオースコードクッキーによるセッションの認証を行っており、オースコードクッキーは保護された通信プロトコルの場合にのみ発行しており、オースコードクッキーにはsecure属性を与えているため、ウェブサイトのための安全なセッション管理を実現できる。
【００５３】
また、本実施例によれば、非保護でも構わないウェブページ２８について非保護の通信プロトコルでの送受信を許容しているため、ウェブサイトのための安全なセッション管理の実現にあたって、全てのウェブページ２２を保護された通信プロトコルで送受信する場合に比べて、ウェブサイトの実行効率劣化を低減できる。
【００５４】
さらに、本実施例によれば、セッションの認証処理を個々の保護すべきウェブページ３０ごとに記述するのではなく、ウェブページ全体で共通のサブプログラムを前処理機構で処理させているため、保護すべきウェブページ３０の数が多くとも、ウェブサイトのための安全なセッション管理の実現にあたって、セッションを認証するための処理を記述する箇所が多くならない。
【００５５】
以上説明したように、本実施例によれば、ウェブサーバ１２によるウェブサイトとウェブクライアント１６の間のセッション管理の内、全てのページで共通化できる部分のプログラム及びこれで用いるデータを前処理機構１００、すなわちウェブページ２２の生成にあたって前処理をプラグインする機構によって集中管理するよう構成したため、セッション維持のための処理を記述する箇所を削減でき、プログラムの作成効率の低下を大幅に抑止することができる。
【産業上の利用可能性】
【００５６】
本発明によれば、電子商取引分野における安全なセッション管理を従来よりも容易に実現するためのプログラムといった用途に適用できる。また、電子政府による証明書の発行分野における安全なセッション管理を従来よりも容易に実現するためのプログラムといった用途にも適用可能である。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施例に係るウェブサイトのための安全なセッション管理システムの構成を示す図である。
【図２】要求されたウェブページを処理する前の処理を説明するフローチャートである。
【図３】図２のセッションを認証済みの状態に昇格する際の処理（ステップＳｔ７）の詳細を説明するフローチャートである。
【図４】従来例に係るシステムの構成を示す図である。
【符号の説明】
【００５８】
１２ ウェブサーバ
１４ 通信チャネル
１６ ウェブクライアント
２２ ウェブページ
１００ 前処理機構
１０１ 要求判別機構
１０２ 通信プロトコル判別機構
１０３ セッション管理機構
１０４ 要求管理機構
１０５ クッキー管理機構
１０６ オースコード生成機構
【特許請求の範囲】
【請求項１】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するプログラムであって、
コンピュータに、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、
前記要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを実行させることを特徴とするウェブサイトのための安全なセッション管理用プログラム。
【請求項２】
前記前処理を行うステップは、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有することを特徴とする請求項１記載のウェブサイトのための安全なセッション管理用プログラム。
【請求項３】
前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有することを特徴とする請求項２記載のウェブサイトのための安全なセッション管理用プログラム。
【請求項４】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理する方法であって、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、
要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを有することを特徴とするウェブサイトのための安全なセッション管理方法。
【請求項５】
前記前処理を行うステップは、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有することを特徴とする請求項４記載のウェブサイトのための安全なセッション管理方法。
【請求項６】
前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有することを特徴とする請求項５記載のウェブサイトのための安全なセッション管理方法。
【請求項７】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するシステムであって、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行う手段と、
前記要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行う前処理手段とを有することを特徴とするウェブサイトのための安全なセッション管理システム。
【請求項８】
前記前処理手段は、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別する手段と、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証する手段とを有することを特徴とする請求項７記載のウェブサイトのための安全なセッション管理システム。
【請求項９】
前記前処理手段は、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄する手段を有することを特徴とする請求項８記載のウェブサイトのための安全なセッション管理システム。
【請求項１】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するプログラムであって、
コンピュータに、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、
前記要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを実行させることを特徴とするウェブサイトのための安全なセッション管理用プログラム。
【請求項２】
前記前処理を行うステップは、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有することを特徴とする請求項１記載のウェブサイトのための安全なセッション管理用プログラム。
【請求項３】
前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有することを特徴とする請求項２記載のウェブサイトのための安全なセッション管理用プログラム。
【請求項４】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理する方法であって、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行うステップと、
要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行うステップとを有することを特徴とするウェブサイトのための安全なセッション管理方法。
【請求項５】
前記前処理を行うステップは、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別するステップと、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証するステップとを有することを特徴とする請求項４記載のウェブサイトのための安全なセッション管理方法。
【請求項６】
前記前処理を行うステップは、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄するステップを有することを特徴とする請求項５記載のウェブサイトのための安全なセッション管理方法。
【請求項７】
保護すべきウェブページ及び非保護のウェブページを有するウェブページから成るウェブサイトで用いられ、このウェブサイトへアクセスするウェブクライアントとの間の通信による一連のアクセスから成るセッションを管理するシステムであって、
前記ウェブクライアントから前記ウェブページのアクセス要求を受けたときに、要求されたウェブページが前記非保護のウェブページの場合、当該ウェブページの処理を行う手段と、
前記要求されたウェブページが前記保護すべきウェブページの場合、当該ウェブページの処理を行う前にそのウェブページの処理とは独立して、secure属性を付加したオースコードクッキーに基づいて前記ウェブページに対するセッションを認証する処理を含む前処理を行う前処理手段とを有することを特徴とするウェブサイトのための安全なセッション管理システム。
【請求項８】
前記前処理手段は、
前記要求されたウェブページの通信で用いる通信プロトコルが保護された通信プロトコルか非保護の通信プロトコルかを判別する手段と、
前記保護された通信プロトコルと判別された場合、前記保護すべきウェブページに対するセッションの１回目のアクセス時に前記ウェブクライアントに対して前記オースコードクッキーを発行すると共に、前記セッションの２回目以降のアクセス時に前記オースコードクッキーを参照して前記セッションを認証する手段とを有することを特徴とする請求項７記載のウェブサイトのための安全なセッション管理システム。
【請求項９】
前記前処理手段は、前記非保護の通信プロトコルと判別された場合、前記セッションを破棄する手段を有することを特徴とする請求項８記載のウェブサイトのための安全なセッション管理システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００６−２４３９２４（Ｐ２００６−２４３９２４Ａ）
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願番号】特願２００５−５５９６２（Ｐ２００５−５５９６２）
【出願日】平成１７年３月１日（２００５．３．１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願日】平成１７年３月１日（２００５．３．１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]