ＵＲＬ検証方法、装置、およびプログラム
【課題】フィッシング詐欺の被害に遭う危険性を低くする。
【解決手段】 まず、利用者がｗｅｂ情報取得部３において個人情報などを入力し、送信の操作を行なう。ｗｅｂ情報取得部３は、個人情報の送信先となるＵＲＬを取得し、検証済リスト格納部３２を検索し、該ＵＲＬが存在するか否かを調べる。検証済リスト格納部３２にＵＲＬが存在した場合、ｗｅｂ情報取得部３は個人情報を送信し、検証処理を終了する。
【解決手段】 まず、利用者がｗｅｂ情報取得部３において個人情報などを入力し、送信の操作を行なう。ｗｅｂ情報取得部３は、個人情報の送信先となるＵＲＬを取得し、検証済リスト格納部３２を検索し、該ＵＲＬが存在するか否かを調べる。検証済リスト格納部３２にＵＲＬが存在した場合、ｗｅｂ情報取得部３は個人情報を送信し、検証処理を終了する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フィッシング詐欺等の防止を目的とし、インターネット等のネットワークを介して公開されている情報の発信元に対する正当性の検証方法に関する。
【背景技術】
【０００２】
昨今、フィッシング詐欺による被害が多発している。フィッシング詐欺とは、信頼のおける金融機関等の企業を装ったメールによって利用者を不正サイトへ誘導し、個人情報やクレジットカード番号などを収集する詐欺である。
【０００３】
現在、非特許文献１のように、不正なサイトのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）群をブラックリストとして管理し、利用者がアクセスしているＵＲＬを常にチェックして、不正なサイトにアクセスした場合に利用者に警告するといった方式によるフィッシング対策の提案がなされているが、不正サイトの発見、登録が人の手によって行なわれるため、不正サイトのＵＲＬがブラックリストに登録されるまでの間にタイムラグが存在し、被害が発生してしまうといった問題がある。
【非特許文献１】Ｎｅｔｃｒａｆｔ社 Ａｎｔｉ−Ｐｈｉｓｈｉｎｇ Ｔｏｏｌｂａｒ （ｈｔｔｐ：／／ｔｏｏｌｂａｒ．ｎｅｔｃｒａｆｔ．ｃｏｍ／）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
フィッシング詐欺を防止するためのＵＲＬ検証に必要となる性質は、以下の３点である。
【０００５】
１）ブラックリスト方式ではなく、個人情報の送信先が正当なものであることを検証することができる必要がある。これは、ブラックリスト方式によるフィッシング詐欺対策を行なう場合に発生する、ブラックリストに不正サイトを登録するまでのタイムラグの問題を解決するためである。
【０００６】
２）利用者の不注意や、情報リテラシの低い利用者をターゲットとしたフィッシング詐欺を防止するために、容易な操作によって、利用者に対して注意を喚起できる必要がある。ｗｅｂサイトのブラウジングを行なう利用者の利便性を下げることなく、単純な操作でＵＲＬの検証を行なうことができ、しかも正当なｗｅｂサイトに接続していることを利用者に対して効果的に通知することができなければならない。
【０００７】
３）ｗｅｂサイト運営者側に負担がかからない検証方式である必要がある。（１）において、個人情報の送信先が正当なものであることを検証するためには、正当なｗｅｂサイトのＵＲＬを管理する必要がある。しかし、ｗｅｂサイトの構成、ＵＲＬなどは頻繁に変更されるため、ｗｅｂサイト運営者にとっては変更の度に正当なｗｅｂサイトとしての登録情報を更新しなければならない。そこで、ｗｅｂサイト運営者側の利便性を高めるため、サイトの構成、ＵＲＬなどの変更に柔軟に対応できなければならない。
【課題を解決するための手段】
【０００８】
本発明のＵＲＬ検証方法は、ＵＲＬ検証装置においてＵＲＬを検証する方法であって、ＵＲＬ情報証明部が、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理し、ＵＲＬ情報検証部が、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知するものである。
【０００９】
フィッシング詐欺の標的となる個人情報などの送信を行なう機会は、ｗｅｂサイトを閲覧する場合に比べて圧倒的に少ないことに注目し、正当なｗｅｂサイトの中の、個人情報の送信先となるＵＲＬをホワイトリストとして管理する。個人情報の送信時、送信先となるＵＲＬをホワイトリストにおいて検索し、送信先ＵＲＬの正当性を検証した上で送信の可否を決定する。
【００１０】
本発明の実施態様では、ＵＲＬ情報検証部が、利用者がｗｅｂサイトに送信する情報を入力する前にも前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する。
【００１１】
個人情報などの送信先ＵＲＬのみの検証では、利用者が多くの情報を入力した上で、送信先の検証を行なうため、正当なＵＲＬとして検証されなかった場合に利用者の利便性を低下させる可能性がある。そこで、ｗｅｂサイトが読み込まれた時点、つまり、個人情報を入力する前の段階においても、当該ＵＲＬの正当性検証を行ない、利用者は正当なｗｅｂサイトであることを確認した上で個人情報の入力を開始できる。
【００１２】
本発明の実施態様では、ＵＲＬ情報検証部が、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの正当性検証を行なう。
【００１３】
利用者に対して別の装置を操作させることにより、利用者の注意を喚起する。
【００１４】
本発明の実施態様によれば、ＵＲＬ情報検証部が、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュする。
【００１５】
過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュすることにより、利用者が閲覧、もしくは情報を送信しようとする度に正当なｗｅｂサイトのＵＲＬリストにアクセスすることなく、利用者側の端末のみでｗｅｂサイトの正当性検証を行なう。
【００１６】
本発明の実施態様によれば、正当なｗｅｂサイトとして判断されるためのディレクトリの許容範囲を設定する。
【００１７】
ｗｅｂサイトの構成の変更に対する柔軟な対応を可能とするために、ｗｅｂサイトの運営者がディレクトリレベルの設定を可能とし、「同一ディレクトリにあるファイルならばファイル名が変更されても信頼する」、「ホスト名が一致していれば信頼する」といった設定を可能とする。
【００１８】
本発明の実施態様によれば、証明情報生成部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮する。
【００１９】
利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮することによって、正当なＵＲＬリストを管理する装置との通信、該装置におけるＵＲＬの検索を効率的に行なう。
【発明の効果】
【００２０】
請求項１の発明は、ホワイトリストによるｗｅｂサイトの正当性検証を行なうことにより、「個人情報の送信先が正当なサイトである」ことを確認した上で送信を実行することが可能となり、ブラックリストを用いる方式に比べてフィッシング詐欺の被害に遭う危険性を低くすることができる。
【００２１】
請求項２の発明は、個人情報等の入力前にｗｅｂサイトが正当であるか否かを判断することにより、情報の送信時に利用者に対して警告を行なう場合に比べて利便性が高くなっている。
【００２２】
請求項３の発明は、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの検証を行なうことにより、利用者の注意を喚起すると共に、ｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末を乗っ取るような手口のフィッシング詐欺に対しても頑強なものとなる。
【００２３】
請求項５の発明は、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュすることにより、ＵＲＬの検証を行なうたびに正当なＵＲＬリストを管理している装置に対して通信を行なうことなく、利用者側の端末に閉じた検証が可能となり、検証に要する時間、コストを下げることが可能となる。
【００２４】
請求項６の発明は、ｗｅｂサイトの運営者に対してディレクトリレベルの設定を可能とすることにより、ｗｅｂサイトの構成の変更に対する柔軟な対応が可能となり、構成の変更を行なう度に正当なＵＲＬリストを管理している装置に対して更新を行なう必要がなくなり、利便性が高くなる。
【００２５】
請求項７の発明は、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮することによって、ＵＲＬ情報検証部とＵＲＬ情報証明部との間で発生する通信量を削減することが可能となり、正当なＵＲＬリストにおける検索を効率的に行なうことが可能となる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明の実施の形態について図面を参照して説明する。
【００２７】
なお、以下の本実施形態においては、ＵＲＬ情報を画像化する手段として、二次元バーコードを想定している。
【００２８】
図１は本発明の一実施形態のＵＲＬ検証装置の構成を示すブロック図である。本装置はＵＲＬ情報検証部１とＵＲＬ情報証明部２とｗｅｂ情報取得部３とｗｅｂ情報公開部４からなる。
【００２９】
ＵＲＬ情報検証部１は、ｗｅｂ情報取得部３において生成された二次元バーコードを読み込み、バーコード情報をデコードしてＵＲＬ情報を抽出し、必要に応じてＵＲＬ情報証明部２から証明情報を取得することによってＵＲＬ情報の検証を行なう。ＵＲＬ情報検証部１には、検証済リスト格納部１２が含まれ、ＵＲＬ検証に成功した正当なＵＲＬの情報をキャッシュとして保存しておくことが可能であり、次回以降の検証の際に利用される。検証用コード撮影部１１は、ｗｅｂ情報取得部３において生成される二次元バーコードを撮影し、ｗｅｂ情報取得部３において表示されているｗｅｂサイトのＵＲＬを取得する。本実施形態では、ＵＲＬ情報検証部１として、二次元バーコードを読み込むことができるカメラ機能と、ＩＣカードを利用した通信機能、赤外線通信機能、インターネットへの接続機能を備えた携帯端末を利用することを想定している。
【００３０】
ＵＲＬ情報証明部２は、ｗｅｂ情報公開部４において生成される証明情報を格納する証明情報格納部２１を含み、ＵＲＬ情報検証部１からの要求により、証明情報格納部２１において保存されている証明情報を提供し、ＵＲＬ検証に必須となる、正当なｗｅｂサイトのＵＲＬ（ホワイトリスト）を提供する。なお、ＵＲＬ情報証明部２は、証明情報の信頼性を確保するために第三者機関に設けられている。
【００３１】
ｗｅｂ情報取得部３は検証用コード生成部３１と検証済リスト格納部３２から構成される。ｗｅｂ情報公開部４から提供されるｗｅｂサイトの情報を利用者に対して出力すると同時に、ｗｅｂサイトのＵＲＬを検証用コード生成部３１において二次元バーコード化する。また、利用者がｗｅｂ情報取得部３から個人情報を送信しようとした場合、送信先ＵＲＬを検証用コード生成部３１において二次元バーコード化する。この二次元バーコードを利用してＵＲＬ情報検証部１においてＵＲＬの検証が行なわれ、検証に成功した場合には当該ＵＲＬ情報を検証済リスト格納部３２に保存する。検証済リスト格納部３２に保存されるＵＲＬ情報は、次回以降、利用者が個人情報を送信しようとした場合の正当なＵＲＬのキャッシュ情報として利用される。本実施形態では、ｗｅｂ情報取得部３として、二次元バーコードを表示する機能を備えたｗｅｂブラウザを利用することを想定している。
【００３２】
ｗｅｂ情報公開部４は証明情報生成部４１からなり、ｗｅｂサイト運営者によって作成されたｗｅｂ情報を公開する。ｗｅｂサイト運営者は、証明情報生成部４１において公開しているｗｅｂサイトのＵＲＬを基に証明情報を作成する。証明情報はＵＲＬ情報証明部２に送信され、正当なｗｅｂサイトのＵＲＬとして登録されると、以後ＵＲＬ情報検証部１におけるＵＲＬ検証に成功するようになる。
【００３３】
図２は、図１のＵＲＬ検証装置において行なわれるＵＲＬ検証処理のうち、ｗｅｂ情報を閲覧する際のＵＲＬを検証する場合のフローチャートを記述したものである。以下、図２を参照して検証処理の処理手順を説明する。
【００３４】
まず、利用者がｗｅｂ情報取得部３において閲覧したいｗｅｂサイトのＵＲＬを入力することにより、ｗｅｂ情報取得部３はｗｅｂ情報公開部４に対してｗｅｂサイトの情報を要求する（ステップ１０１）。次に、ｗｅｂ情報取得部３は、ｗｅｂ情報公開部４から取得した情報を利用者に対して出力すると共に、当該ｗｅｂサイトを構成するＵＲＬ群を取得する（ステップ１０２）。構成ＵＲＬの取得処理の手順については図５において説明する。得られたＵＲＬ群を基に二次元バーコードを生成し、これを利用者に対して出力する（ステップ１０３）。二次元バーコード生成・表示処理については図６において説明する。利用者は検証用コード撮影部１１を利用して生成した二次元バーコードを撮影し（ステップ１０４）、ＵＲＬ情報検証部１において該バーコードをデコードし、ＵＲＬ情報を取得する（ステップ１０５）。ＵＲＬ情報検証部１はまず、検証済リスト格納部１２において当該ＵＲＬがキャッシュされているか否かを調べる。検証済リストを検索する際の検索方法の例としては、検索キーとしてＵＲＬに含まれるホスト名（例：トップページのＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｉｎｄｅｘ．ｈｔｍｌの場合にはｘｘｘの部分）を使用する方法が挙げられる。検証済リスト格納部１２に該ＵＲＬが存在する場合（ステップ１０７のＹｅｓ）、ＵＲＬ情報検証部１は利用者に対してＵＲＬの検証に成功したことを通知し（ステップ１０８）、ＵＲＬ情報検証部１からｗｅｂ情報取得部３に対してＵＲＬの検証に成功したことを通知する（ステップ１０９）。ｗｅｂ情報取得部３は該ＵＲＬを検証済リスト格納部３２に保存し、以後、同じＵＲＬにおいて正当性検証が行なわれる際のキャッシュとして利用する。
【００３５】
検証済リスト格納部１２において該ＵＲＬが存在しなかった場合（ステップ１０７のＮｏ）、ＵＲＬ情報検証部１はＵＲＬ情報証明部２に対して該ＵＲＬの検索要求を行なう（ステップ１１１）。ＵＲＬ情報証明部２では、ステップ１０７と同様に該ＵＲＬのホスト名をキーとし、証明情報格納部２１を検索する（ステップ１１２）。証明情報格納部２１に該ＵＲＬが存在した場合（１１３のＹｅｓ）、ＵＲＬ情報証明部２はＵＲＬ情報検証部１に対して検索結果を通知し（ステップ１１４）、ステップ１０８〜１１０を実行する。
【００３６】
証明情報格納部２１において該ＵＲＬが存在しなかった場合（ステップ１１３のＮｏ）、ＵＲＬ情報証明部２はＵＲＬ情報検証部１に対して検索結果を通知し（ステップ１１５）、ＵＲＬ情報検証部１は利用者に対して検証に失敗したことを通知する（ステップ１１６）。ＵＲＬ情報検証部１はｗｅｂ情報取得部３に対して正当性検証に失敗したことを通知し（ステップ１１７）、ｗｅｂ情報取得部３から利用者に対して正当性検証に失敗したことを通知する（ステップ１１８）。
【００３７】
以上の処理により、利用者がｗｅｂ情報を閲覧する際に当該ＵＲＬが正当なものであるか否かを検証し、利用者に通知することができる。
【００３８】
図３は、図１のＵＲＬ検証装置において行なわれるＵＲＬ検証処理のうち、個人情報などを送信する際のＵＲＬを検証する場合のフローチャートを記述したものである。以下、図３を参照して検証処理の処理手順を説明する。
【００３９】
まず、利用者がｗｅｂ情報取得部３において個人情報などを入力し、送信の操作を行なう（ステップ２０１）。ｗｅｂ情報取得部３は、個人情報の送信先となるＵＲＬを取得し（ステップ２０２）、検証済リスト格納部３２を検索し、該ＵＲＬが存在するか否かを調べる。検証済リスト格納部３２にＵＲＬが存在した場合（ステップ２０３のＹｅｓ）、ｗｅｂ情報取得部３は個人情報を送信し（ステップ２１３）、検証処理を終了する。
【００４０】
検証済リスト格納部３２に該ＵＲＬが存在しなかった場合（ステップ２０３のＮｏ）、図２のステップ１０３〜１０６と同様の処理を行なう（ステップ２０４〜２０７）。検証済リスト格納部１２に該ＵＲＬが存在した場合（ステップ２０８のＹｅｓ）、図２のステップ１０８〜１１０と同様に処理を行ない（ステップ２０９〜２１１）、ｗｅｂ情報取得部３は最後に個人情報を送信して（ステップ２１２）、検証処理を終了する。
【００４１】
検証済リスト格納部１２に該ＵＲＬが存在しなかった場合（ステップ２０８のＮｏ）、図２のステップ１１１〜１１８と同様の処理を行う（ステップ２１４〜２２１）。以上の処理により、利用者が個人情報を送信する場合に送信先ＵＲＬが正当なものであるか否かを検証し、利用者に通知することができる。
【００４２】
図４は証明情報生成部４１において、ＵＲＬ情報証明部２に送信する証明情報（正当なｗｅｂサイトであることを証明するための情報）を生成する処理のフローチャートを記述したものである。以下、図４を参照して証明情報生成処理の処理手順を説明する。
【００４３】
まず、ｗｅｂサイト運営者はｗｅｂ情報公開部４において生成対象となるｗｅｂサイトのトップページのＵＲＬを入力する（ステップ３０１）。この状態で証明情報生成部４１を起動し（ステップ３０２）、ｗｅｂサイトを構成するＵＲＬを取得する（ステップ３０３）。構成ＵＲＬ取得の手順は、図５において説明する。ｗｅｂサイト運営者は得られた構成ＵＲＬ群に対し、ディレクトリレベルを設定する（ステップ３０４）。証明情報生成部４１は通信を効率的に行なうためにＵＲＬ群に対して圧縮操作を行ない（ステップ３０５）、圧縮された各ＵＲＬに対してステップ３０４で設定されたディレクトリレベルの数値を連接する（ステップ３０６）。ＵＲＬ圧縮の処理については図７で説明する。ディレクトリレベルを連接したＵＲＬ群は証明情報生成部４１において１つの文字列に連接され、これが証明情報となる（ステップ３０７）。証明情報はｗｅｂ情報公開部４からｗｅｂサイト運営者に対して出力され（ステップ３０８）、ｗｅｂサイト運営者はこの証明情報をＵＲＬ情報証明部２に対して送信し、証明情報は証明情報格納部２１に格納される（ステップ３０９）。証明情報が証明情報格納部２１に格納されると、以後ＵＲＬ検証処理によって正当なＵＲＬとして判断されることになる。
【００４４】
表１は例としてｈｔｔｐ：／／ａａａ．ｃｏｍ／ｂｂｂ／ｃｃｃ／ｄｄｄ．ｈｔｍｌというＵＲＬが存在した場合に、ディレクトリレベルの設定値と対応する設定内容を示したものである。ｗｅｂサイトの運営者はこれらの設定値の中から当該ｗｅｂサイトの運営に最適なレベルを選択することにより、「ファイル名が異なる場合には信頼しない」といった厳しいポリシから、「ホスト名が一致すれば信頼する」といった緩いポリシまでを選択することが可能である。
【００４５】
【表１】
【００４６】
図５はステップ１０２、ステップ３０３において実行される処理（ＵＲＬ取得）のフローチャートを記述したものである。以下、図５を参照して構成ＵＲＬ取得処理の処理手順を説明する。
【００４７】
本実施形態では構成ＵＲＬとしてトップページのＵＲＬ、フレームを構成するＵＲＬ、情報の送信先となるＵＲＬを対象としている。まず、トップページのＵＲＬから、当該ｗｅｂサイトがフレーム構成を持つか否かを判断し（ステップ４０１）、フレーム構成を持つ場合（ステップ４０１のＹｅｓ）、フレームを構成するＵＲＬ群を取得する（ステップ４０２）。次に、トップページのＵＲＬとフレームを構成するＵＲＬ群のＨＴＭＬソースを取得し、当該ソースファイルに含まれる情報送信先ＵＲＬを取得する（ステップ４０３）。例えば、ＨＴＭＬのＦＯＲＭタグを検索キーとし、ソースファイルを検索することにより、ヒットしたタグの中のａｃｔｉｏｎ属性に記述されるＵＲＬを取得することにより、情報送信先ＵＲＬを取得することが可能となる。以上の処理により、トップページのＵＲＬ、フレームを構成するＵＲＬ、情報の送信先となるＵＲＬを取得することができる。
【００４８】
該ｗｅｂサイトがフレーム構成を持たなかった場合（ステップ４０１のＮｏ）、トップページＵＲＬのＨＴＭＬソースを取得し、ステップ４０３を実行する。これにより、トップページのＵＲＬと情報の送信先となるＵＲＬを取得することができる。
【００４９】
図６はステップ１０３、ステップ２０４において実行される二次元バーコード生成・表示処理のフローチャートを記述したものである。以下、図６を参照して二次元バーコード生成・表示処理の手順を示す。
【００５０】
まず、通信を効率的に行なうために二次元バーコード生成の対象となっているＵＲＬ群を圧縮する（ステップ５０１）。ＵＲＬ圧縮の処理については図７で説明する。ＵＲＬ群を圧縮後、各ＵＲＬを１つの文字列に連接し（ステップ５０２）、得られた文字列を基にバーコードを生成、表示する（ステップ５０３）。以上の処理により、ｗｅｂ情報取得部３において二次元バーコードが表示され、検証用コード撮影部１１からの撮影が可能な状態となる。
【００５１】
図７はステップ３０５、ステップ５０１において実行されるＵＲＬ圧縮処理のフローチャートを記述したものである。ＵＲＬ圧縮を行なうことより、ＵＲＬ情報を二次元バーコード化する際、もしくは通信によってＵＲＬ情報を送受信する際のデータ量を削減し、効率を高めることが可能となる。以下、図７を参照してＵＲＬ圧縮処理の手順を示す。
【００５２】
ＵＲＬ圧縮処理には入力として圧縮対象となるＵＲＬ群が与えられる。最初に、トップページ以外に未処理のＵＲＬが残っているか否かを調べる（ステップ６０１）。未処理のＵＲＬが残っている場合（ステップ６０１のＹｅｓ）、該ＵＲＬを処理対象とし（ステップ６０２）、トップページのＵＲＬと該ＵＲＬを前方一致で比較し、一致している文字の数を取得する（ステップ６０３）。この比較の結果得られた一致文字数分を当該ＵＲＬから削除し（ステップ６０４）、削除後の文字列に一致文字数の値を連接する（ステップ６０５）。これにより、トップページのＵＲＬと連接後の文字列によってもとのＵＲＬが復元可能となる。
【００５３】
ステップ６０１においてトップページ以外に未処理のＵＲＬが存在しなかった場合は（ステップ６０１のＮｏ）、ＵＲＬ圧縮処理を終了する。
【００５４】
図８は、図２のステップ１０３において実行される二次元バーコード生成・表示処理によって生成される証明情報の例を示したものである。図中上段のトップページＵＲＬ、フレーム構成ＵＲＬ、送信先ＵＲＬから構成されるｗｅｂサイトが存在すると仮定すると、ステップ１０３の処理によって図中下段の文字列が生成される。ＵＲＬの間に位置する数値は、ＵＲＬ圧縮処理（ステップ５０１）を実行することによって得られたトップページＵＲＬと当該ＵＲＬとの一致文字数となる。
【００５５】
なお、以上説明したＵＲＬ検証装置の機能は、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定時間プログラムを保持しているものを含む。
【図面の簡単な説明】
【００５６】
【図１】本発明の一実施形態のＵＲＬ検証装置を示すブロック図である。
【図２】ｗｅｂ情報を閲覧する際のＵＲＬ検証処理のフローチャートである。
【図３】利用者が情報を送信する際の送信先ＵＲＬ検証処理のフローチャートである。
【図４】証明情報生成処理のフローチャートである。
【図５】構成ＵＲＬ取得処理のフローチャートである。
【図６】二次元バーコード生成・表示処理のフローチャートである。
【図７】ＵＲＬ圧縮処理のフローチャートである。
【図８】二次元バーコード生成・表示処理によって生成される文字列の例を示す図である。
【符号の説明】
【００５７】
１ ＵＲＬ情報検証部
１１ 検証用コード撮影部
１２ 検証済リスト格納部
２ ＵＲＬ情報証明部
２１ 証明情報格納部
３ ｗｅｂ情報取得部
３１ 検証用コード生成部
３２ 検証済リスト格納部
４ ｗｅｂ情報公開部
４１ 証明情報生成部
１０１〜１１８，２０１〜２２１，３０１〜３０９ ステップ
４０１〜４０３，５０１〜５０３，６０１〜６０５ ステップ
【技術分野】
【０００１】
本発明は、フィッシング詐欺等の防止を目的とし、インターネット等のネットワークを介して公開されている情報の発信元に対する正当性の検証方法に関する。
【背景技術】
【０００２】
昨今、フィッシング詐欺による被害が多発している。フィッシング詐欺とは、信頼のおける金融機関等の企業を装ったメールによって利用者を不正サイトへ誘導し、個人情報やクレジットカード番号などを収集する詐欺である。
【０００３】
現在、非特許文献１のように、不正なサイトのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）群をブラックリストとして管理し、利用者がアクセスしているＵＲＬを常にチェックして、不正なサイトにアクセスした場合に利用者に警告するといった方式によるフィッシング対策の提案がなされているが、不正サイトの発見、登録が人の手によって行なわれるため、不正サイトのＵＲＬがブラックリストに登録されるまでの間にタイムラグが存在し、被害が発生してしまうといった問題がある。
【非特許文献１】Ｎｅｔｃｒａｆｔ社 Ａｎｔｉ−Ｐｈｉｓｈｉｎｇ Ｔｏｏｌｂａｒ （ｈｔｔｐ：／／ｔｏｏｌｂａｒ．ｎｅｔｃｒａｆｔ．ｃｏｍ／）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
フィッシング詐欺を防止するためのＵＲＬ検証に必要となる性質は、以下の３点である。
【０００５】
１）ブラックリスト方式ではなく、個人情報の送信先が正当なものであることを検証することができる必要がある。これは、ブラックリスト方式によるフィッシング詐欺対策を行なう場合に発生する、ブラックリストに不正サイトを登録するまでのタイムラグの問題を解決するためである。
【０００６】
２）利用者の不注意や、情報リテラシの低い利用者をターゲットとしたフィッシング詐欺を防止するために、容易な操作によって、利用者に対して注意を喚起できる必要がある。ｗｅｂサイトのブラウジングを行なう利用者の利便性を下げることなく、単純な操作でＵＲＬの検証を行なうことができ、しかも正当なｗｅｂサイトに接続していることを利用者に対して効果的に通知することができなければならない。
【０００７】
３）ｗｅｂサイト運営者側に負担がかからない検証方式である必要がある。（１）において、個人情報の送信先が正当なものであることを検証するためには、正当なｗｅｂサイトのＵＲＬを管理する必要がある。しかし、ｗｅｂサイトの構成、ＵＲＬなどは頻繁に変更されるため、ｗｅｂサイト運営者にとっては変更の度に正当なｗｅｂサイトとしての登録情報を更新しなければならない。そこで、ｗｅｂサイト運営者側の利便性を高めるため、サイトの構成、ＵＲＬなどの変更に柔軟に対応できなければならない。
【課題を解決するための手段】
【０００８】
本発明のＵＲＬ検証方法は、ＵＲＬ検証装置においてＵＲＬを検証する方法であって、ＵＲＬ情報証明部が、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理し、ＵＲＬ情報検証部が、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知するものである。
【０００９】
フィッシング詐欺の標的となる個人情報などの送信を行なう機会は、ｗｅｂサイトを閲覧する場合に比べて圧倒的に少ないことに注目し、正当なｗｅｂサイトの中の、個人情報の送信先となるＵＲＬをホワイトリストとして管理する。個人情報の送信時、送信先となるＵＲＬをホワイトリストにおいて検索し、送信先ＵＲＬの正当性を検証した上で送信の可否を決定する。
【００１０】
本発明の実施態様では、ＵＲＬ情報検証部が、利用者がｗｅｂサイトに送信する情報を入力する前にも前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する。
【００１１】
個人情報などの送信先ＵＲＬのみの検証では、利用者が多くの情報を入力した上で、送信先の検証を行なうため、正当なＵＲＬとして検証されなかった場合に利用者の利便性を低下させる可能性がある。そこで、ｗｅｂサイトが読み込まれた時点、つまり、個人情報を入力する前の段階においても、当該ＵＲＬの正当性検証を行ない、利用者は正当なｗｅｂサイトであることを確認した上で個人情報の入力を開始できる。
【００１２】
本発明の実施態様では、ＵＲＬ情報検証部が、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの正当性検証を行なう。
【００１３】
利用者に対して別の装置を操作させることにより、利用者の注意を喚起する。
【００１４】
本発明の実施態様によれば、ＵＲＬ情報検証部が、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュする。
【００１５】
過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュすることにより、利用者が閲覧、もしくは情報を送信しようとする度に正当なｗｅｂサイトのＵＲＬリストにアクセスすることなく、利用者側の端末のみでｗｅｂサイトの正当性検証を行なう。
【００１６】
本発明の実施態様によれば、正当なｗｅｂサイトとして判断されるためのディレクトリの許容範囲を設定する。
【００１７】
ｗｅｂサイトの構成の変更に対する柔軟な対応を可能とするために、ｗｅｂサイトの運営者がディレクトリレベルの設定を可能とし、「同一ディレクトリにあるファイルならばファイル名が変更されても信頼する」、「ホスト名が一致していれば信頼する」といった設定を可能とする。
【００１８】
本発明の実施態様によれば、証明情報生成部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮する。
【００１９】
利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮することによって、正当なＵＲＬリストを管理する装置との通信、該装置におけるＵＲＬの検索を効率的に行なう。
【発明の効果】
【００２０】
請求項１の発明は、ホワイトリストによるｗｅｂサイトの正当性検証を行なうことにより、「個人情報の送信先が正当なサイトである」ことを確認した上で送信を実行することが可能となり、ブラックリストを用いる方式に比べてフィッシング詐欺の被害に遭う危険性を低くすることができる。
【００２１】
請求項２の発明は、個人情報等の入力前にｗｅｂサイトが正当であるか否かを判断することにより、情報の送信時に利用者に対して警告を行なう場合に比べて利便性が高くなっている。
【００２２】
請求項３の発明は、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの検証を行なうことにより、利用者の注意を喚起すると共に、ｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末を乗っ取るような手口のフィッシング詐欺に対しても頑強なものとなる。
【００２３】
請求項５の発明は、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュすることにより、ＵＲＬの検証を行なうたびに正当なＵＲＬリストを管理している装置に対して通信を行なうことなく、利用者側の端末に閉じた検証が可能となり、検証に要する時間、コストを下げることが可能となる。
【００２４】
請求項６の発明は、ｗｅｂサイトの運営者に対してディレクトリレベルの設定を可能とすることにより、ｗｅｂサイトの構成の変更に対する柔軟な対応が可能となり、構成の変更を行なう度に正当なＵＲＬリストを管理している装置に対して更新を行なう必要がなくなり、利便性が高くなる。
【００２５】
請求項７の発明は、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮することによって、ＵＲＬ情報検証部とＵＲＬ情報証明部との間で発生する通信量を削減することが可能となり、正当なＵＲＬリストにおける検索を効率的に行なうことが可能となる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明の実施の形態について図面を参照して説明する。
【００２７】
なお、以下の本実施形態においては、ＵＲＬ情報を画像化する手段として、二次元バーコードを想定している。
【００２８】
図１は本発明の一実施形態のＵＲＬ検証装置の構成を示すブロック図である。本装置はＵＲＬ情報検証部１とＵＲＬ情報証明部２とｗｅｂ情報取得部３とｗｅｂ情報公開部４からなる。
【００２９】
ＵＲＬ情報検証部１は、ｗｅｂ情報取得部３において生成された二次元バーコードを読み込み、バーコード情報をデコードしてＵＲＬ情報を抽出し、必要に応じてＵＲＬ情報証明部２から証明情報を取得することによってＵＲＬ情報の検証を行なう。ＵＲＬ情報検証部１には、検証済リスト格納部１２が含まれ、ＵＲＬ検証に成功した正当なＵＲＬの情報をキャッシュとして保存しておくことが可能であり、次回以降の検証の際に利用される。検証用コード撮影部１１は、ｗｅｂ情報取得部３において生成される二次元バーコードを撮影し、ｗｅｂ情報取得部３において表示されているｗｅｂサイトのＵＲＬを取得する。本実施形態では、ＵＲＬ情報検証部１として、二次元バーコードを読み込むことができるカメラ機能と、ＩＣカードを利用した通信機能、赤外線通信機能、インターネットへの接続機能を備えた携帯端末を利用することを想定している。
【００３０】
ＵＲＬ情報証明部２は、ｗｅｂ情報公開部４において生成される証明情報を格納する証明情報格納部２１を含み、ＵＲＬ情報検証部１からの要求により、証明情報格納部２１において保存されている証明情報を提供し、ＵＲＬ検証に必須となる、正当なｗｅｂサイトのＵＲＬ（ホワイトリスト）を提供する。なお、ＵＲＬ情報証明部２は、証明情報の信頼性を確保するために第三者機関に設けられている。
【００３１】
ｗｅｂ情報取得部３は検証用コード生成部３１と検証済リスト格納部３２から構成される。ｗｅｂ情報公開部４から提供されるｗｅｂサイトの情報を利用者に対して出力すると同時に、ｗｅｂサイトのＵＲＬを検証用コード生成部３１において二次元バーコード化する。また、利用者がｗｅｂ情報取得部３から個人情報を送信しようとした場合、送信先ＵＲＬを検証用コード生成部３１において二次元バーコード化する。この二次元バーコードを利用してＵＲＬ情報検証部１においてＵＲＬの検証が行なわれ、検証に成功した場合には当該ＵＲＬ情報を検証済リスト格納部３２に保存する。検証済リスト格納部３２に保存されるＵＲＬ情報は、次回以降、利用者が個人情報を送信しようとした場合の正当なＵＲＬのキャッシュ情報として利用される。本実施形態では、ｗｅｂ情報取得部３として、二次元バーコードを表示する機能を備えたｗｅｂブラウザを利用することを想定している。
【００３２】
ｗｅｂ情報公開部４は証明情報生成部４１からなり、ｗｅｂサイト運営者によって作成されたｗｅｂ情報を公開する。ｗｅｂサイト運営者は、証明情報生成部４１において公開しているｗｅｂサイトのＵＲＬを基に証明情報を作成する。証明情報はＵＲＬ情報証明部２に送信され、正当なｗｅｂサイトのＵＲＬとして登録されると、以後ＵＲＬ情報検証部１におけるＵＲＬ検証に成功するようになる。
【００３３】
図２は、図１のＵＲＬ検証装置において行なわれるＵＲＬ検証処理のうち、ｗｅｂ情報を閲覧する際のＵＲＬを検証する場合のフローチャートを記述したものである。以下、図２を参照して検証処理の処理手順を説明する。
【００３４】
まず、利用者がｗｅｂ情報取得部３において閲覧したいｗｅｂサイトのＵＲＬを入力することにより、ｗｅｂ情報取得部３はｗｅｂ情報公開部４に対してｗｅｂサイトの情報を要求する（ステップ１０１）。次に、ｗｅｂ情報取得部３は、ｗｅｂ情報公開部４から取得した情報を利用者に対して出力すると共に、当該ｗｅｂサイトを構成するＵＲＬ群を取得する（ステップ１０２）。構成ＵＲＬの取得処理の手順については図５において説明する。得られたＵＲＬ群を基に二次元バーコードを生成し、これを利用者に対して出力する（ステップ１０３）。二次元バーコード生成・表示処理については図６において説明する。利用者は検証用コード撮影部１１を利用して生成した二次元バーコードを撮影し（ステップ１０４）、ＵＲＬ情報検証部１において該バーコードをデコードし、ＵＲＬ情報を取得する（ステップ１０５）。ＵＲＬ情報検証部１はまず、検証済リスト格納部１２において当該ＵＲＬがキャッシュされているか否かを調べる。検証済リストを検索する際の検索方法の例としては、検索キーとしてＵＲＬに含まれるホスト名（例：トップページのＵＲＬがｈｔｔｐ：／／ｘｘｘ／ｉｎｄｅｘ．ｈｔｍｌの場合にはｘｘｘの部分）を使用する方法が挙げられる。検証済リスト格納部１２に該ＵＲＬが存在する場合（ステップ１０７のＹｅｓ）、ＵＲＬ情報検証部１は利用者に対してＵＲＬの検証に成功したことを通知し（ステップ１０８）、ＵＲＬ情報検証部１からｗｅｂ情報取得部３に対してＵＲＬの検証に成功したことを通知する（ステップ１０９）。ｗｅｂ情報取得部３は該ＵＲＬを検証済リスト格納部３２に保存し、以後、同じＵＲＬにおいて正当性検証が行なわれる際のキャッシュとして利用する。
【００３５】
検証済リスト格納部１２において該ＵＲＬが存在しなかった場合（ステップ１０７のＮｏ）、ＵＲＬ情報検証部１はＵＲＬ情報証明部２に対して該ＵＲＬの検索要求を行なう（ステップ１１１）。ＵＲＬ情報証明部２では、ステップ１０７と同様に該ＵＲＬのホスト名をキーとし、証明情報格納部２１を検索する（ステップ１１２）。証明情報格納部２１に該ＵＲＬが存在した場合（１１３のＹｅｓ）、ＵＲＬ情報証明部２はＵＲＬ情報検証部１に対して検索結果を通知し（ステップ１１４）、ステップ１０８〜１１０を実行する。
【００３６】
証明情報格納部２１において該ＵＲＬが存在しなかった場合（ステップ１１３のＮｏ）、ＵＲＬ情報証明部２はＵＲＬ情報検証部１に対して検索結果を通知し（ステップ１１５）、ＵＲＬ情報検証部１は利用者に対して検証に失敗したことを通知する（ステップ１１６）。ＵＲＬ情報検証部１はｗｅｂ情報取得部３に対して正当性検証に失敗したことを通知し（ステップ１１７）、ｗｅｂ情報取得部３から利用者に対して正当性検証に失敗したことを通知する（ステップ１１８）。
【００３７】
以上の処理により、利用者がｗｅｂ情報を閲覧する際に当該ＵＲＬが正当なものであるか否かを検証し、利用者に通知することができる。
【００３８】
図３は、図１のＵＲＬ検証装置において行なわれるＵＲＬ検証処理のうち、個人情報などを送信する際のＵＲＬを検証する場合のフローチャートを記述したものである。以下、図３を参照して検証処理の処理手順を説明する。
【００３９】
まず、利用者がｗｅｂ情報取得部３において個人情報などを入力し、送信の操作を行なう（ステップ２０１）。ｗｅｂ情報取得部３は、個人情報の送信先となるＵＲＬを取得し（ステップ２０２）、検証済リスト格納部３２を検索し、該ＵＲＬが存在するか否かを調べる。検証済リスト格納部３２にＵＲＬが存在した場合（ステップ２０３のＹｅｓ）、ｗｅｂ情報取得部３は個人情報を送信し（ステップ２１３）、検証処理を終了する。
【００４０】
検証済リスト格納部３２に該ＵＲＬが存在しなかった場合（ステップ２０３のＮｏ）、図２のステップ１０３〜１０６と同様の処理を行なう（ステップ２０４〜２０７）。検証済リスト格納部１２に該ＵＲＬが存在した場合（ステップ２０８のＹｅｓ）、図２のステップ１０８〜１１０と同様に処理を行ない（ステップ２０９〜２１１）、ｗｅｂ情報取得部３は最後に個人情報を送信して（ステップ２１２）、検証処理を終了する。
【００４１】
検証済リスト格納部１２に該ＵＲＬが存在しなかった場合（ステップ２０８のＮｏ）、図２のステップ１１１〜１１８と同様の処理を行う（ステップ２１４〜２２１）。以上の処理により、利用者が個人情報を送信する場合に送信先ＵＲＬが正当なものであるか否かを検証し、利用者に通知することができる。
【００４２】
図４は証明情報生成部４１において、ＵＲＬ情報証明部２に送信する証明情報（正当なｗｅｂサイトであることを証明するための情報）を生成する処理のフローチャートを記述したものである。以下、図４を参照して証明情報生成処理の処理手順を説明する。
【００４３】
まず、ｗｅｂサイト運営者はｗｅｂ情報公開部４において生成対象となるｗｅｂサイトのトップページのＵＲＬを入力する（ステップ３０１）。この状態で証明情報生成部４１を起動し（ステップ３０２）、ｗｅｂサイトを構成するＵＲＬを取得する（ステップ３０３）。構成ＵＲＬ取得の手順は、図５において説明する。ｗｅｂサイト運営者は得られた構成ＵＲＬ群に対し、ディレクトリレベルを設定する（ステップ３０４）。証明情報生成部４１は通信を効率的に行なうためにＵＲＬ群に対して圧縮操作を行ない（ステップ３０５）、圧縮された各ＵＲＬに対してステップ３０４で設定されたディレクトリレベルの数値を連接する（ステップ３０６）。ＵＲＬ圧縮の処理については図７で説明する。ディレクトリレベルを連接したＵＲＬ群は証明情報生成部４１において１つの文字列に連接され、これが証明情報となる（ステップ３０７）。証明情報はｗｅｂ情報公開部４からｗｅｂサイト運営者に対して出力され（ステップ３０８）、ｗｅｂサイト運営者はこの証明情報をＵＲＬ情報証明部２に対して送信し、証明情報は証明情報格納部２１に格納される（ステップ３０９）。証明情報が証明情報格納部２１に格納されると、以後ＵＲＬ検証処理によって正当なＵＲＬとして判断されることになる。
【００４４】
表１は例としてｈｔｔｐ：／／ａａａ．ｃｏｍ／ｂｂｂ／ｃｃｃ／ｄｄｄ．ｈｔｍｌというＵＲＬが存在した場合に、ディレクトリレベルの設定値と対応する設定内容を示したものである。ｗｅｂサイトの運営者はこれらの設定値の中から当該ｗｅｂサイトの運営に最適なレベルを選択することにより、「ファイル名が異なる場合には信頼しない」といった厳しいポリシから、「ホスト名が一致すれば信頼する」といった緩いポリシまでを選択することが可能である。
【００４５】
【表１】
【００４６】
図５はステップ１０２、ステップ３０３において実行される処理（ＵＲＬ取得）のフローチャートを記述したものである。以下、図５を参照して構成ＵＲＬ取得処理の処理手順を説明する。
【００４７】
本実施形態では構成ＵＲＬとしてトップページのＵＲＬ、フレームを構成するＵＲＬ、情報の送信先となるＵＲＬを対象としている。まず、トップページのＵＲＬから、当該ｗｅｂサイトがフレーム構成を持つか否かを判断し（ステップ４０１）、フレーム構成を持つ場合（ステップ４０１のＹｅｓ）、フレームを構成するＵＲＬ群を取得する（ステップ４０２）。次に、トップページのＵＲＬとフレームを構成するＵＲＬ群のＨＴＭＬソースを取得し、当該ソースファイルに含まれる情報送信先ＵＲＬを取得する（ステップ４０３）。例えば、ＨＴＭＬのＦＯＲＭタグを検索キーとし、ソースファイルを検索することにより、ヒットしたタグの中のａｃｔｉｏｎ属性に記述されるＵＲＬを取得することにより、情報送信先ＵＲＬを取得することが可能となる。以上の処理により、トップページのＵＲＬ、フレームを構成するＵＲＬ、情報の送信先となるＵＲＬを取得することができる。
【００４８】
該ｗｅｂサイトがフレーム構成を持たなかった場合（ステップ４０１のＮｏ）、トップページＵＲＬのＨＴＭＬソースを取得し、ステップ４０３を実行する。これにより、トップページのＵＲＬと情報の送信先となるＵＲＬを取得することができる。
【００４９】
図６はステップ１０３、ステップ２０４において実行される二次元バーコード生成・表示処理のフローチャートを記述したものである。以下、図６を参照して二次元バーコード生成・表示処理の手順を示す。
【００５０】
まず、通信を効率的に行なうために二次元バーコード生成の対象となっているＵＲＬ群を圧縮する（ステップ５０１）。ＵＲＬ圧縮の処理については図７で説明する。ＵＲＬ群を圧縮後、各ＵＲＬを１つの文字列に連接し（ステップ５０２）、得られた文字列を基にバーコードを生成、表示する（ステップ５０３）。以上の処理により、ｗｅｂ情報取得部３において二次元バーコードが表示され、検証用コード撮影部１１からの撮影が可能な状態となる。
【００５１】
図７はステップ３０５、ステップ５０１において実行されるＵＲＬ圧縮処理のフローチャートを記述したものである。ＵＲＬ圧縮を行なうことより、ＵＲＬ情報を二次元バーコード化する際、もしくは通信によってＵＲＬ情報を送受信する際のデータ量を削減し、効率を高めることが可能となる。以下、図７を参照してＵＲＬ圧縮処理の手順を示す。
【００５２】
ＵＲＬ圧縮処理には入力として圧縮対象となるＵＲＬ群が与えられる。最初に、トップページ以外に未処理のＵＲＬが残っているか否かを調べる（ステップ６０１）。未処理のＵＲＬが残っている場合（ステップ６０１のＹｅｓ）、該ＵＲＬを処理対象とし（ステップ６０２）、トップページのＵＲＬと該ＵＲＬを前方一致で比較し、一致している文字の数を取得する（ステップ６０３）。この比較の結果得られた一致文字数分を当該ＵＲＬから削除し（ステップ６０４）、削除後の文字列に一致文字数の値を連接する（ステップ６０５）。これにより、トップページのＵＲＬと連接後の文字列によってもとのＵＲＬが復元可能となる。
【００５３】
ステップ６０１においてトップページ以外に未処理のＵＲＬが存在しなかった場合は（ステップ６０１のＮｏ）、ＵＲＬ圧縮処理を終了する。
【００５４】
図８は、図２のステップ１０３において実行される二次元バーコード生成・表示処理によって生成される証明情報の例を示したものである。図中上段のトップページＵＲＬ、フレーム構成ＵＲＬ、送信先ＵＲＬから構成されるｗｅｂサイトが存在すると仮定すると、ステップ１０３の処理によって図中下段の文字列が生成される。ＵＲＬの間に位置する数値は、ＵＲＬ圧縮処理（ステップ５０１）を実行することによって得られたトップページＵＲＬと当該ＵＲＬとの一致文字数となる。
【００５５】
なお、以上説明したＵＲＬ検証装置の機能は、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定時間プログラムを保持しているものを含む。
【図面の簡単な説明】
【００５６】
【図１】本発明の一実施形態のＵＲＬ検証装置を示すブロック図である。
【図２】ｗｅｂ情報を閲覧する際のＵＲＬ検証処理のフローチャートである。
【図３】利用者が情報を送信する際の送信先ＵＲＬ検証処理のフローチャートである。
【図４】証明情報生成処理のフローチャートである。
【図５】構成ＵＲＬ取得処理のフローチャートである。
【図６】二次元バーコード生成・表示処理のフローチャートである。
【図７】ＵＲＬ圧縮処理のフローチャートである。
【図８】二次元バーコード生成・表示処理によって生成される文字列の例を示す図である。
【符号の説明】
【００５７】
１ ＵＲＬ情報検証部
１１ 検証用コード撮影部
１２ 検証済リスト格納部
２ ＵＲＬ情報証明部
２１ 証明情報格納部
３ ｗｅｂ情報取得部
３１ 検証用コード生成部
３２ 検証済リスト格納部
４ ｗｅｂ情報公開部
４１ 証明情報生成部
１０１〜１１８，２０１〜２２１，３０１〜３０９ ステップ
４０１〜４０３，５０１〜５０３，６０１〜６０５ ステップ
【特許請求の範囲】
【請求項１】
ＵＲＬ検証装置においてＵＲＬを検証する方法であって、
ＵＲＬ情報証明部が、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理し、
ＵＲＬ情報検証部が、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する
ＵＲＬ検証方法。
【請求項２】
前記ＵＲＬ情報検証部は、利用者がｗｅｂサイトに送信する情報を入力する前に前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する、請求項１に記載のＵＲＬ検証方法。
【請求項３】
前記ＵＲＬ情報検証部は、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの正当性検証を行なう、請求項１または２に記載のＵＲＬ検証方法。
【請求項４】
ｗｅｂ情報取得部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を画像化し、前記ＵＲＬ情報検索部は、該画像を撮影することによってＵＲＬ情報を取得後、正当なｗｅｂサイトのＵＲＬリストでの検索を行ない、ｗｅｂサイトの正当性検証を行なう、請求項１から３のいずれかに記載のＵＲＬ検証方法。
【請求項５】
前記ＵＲＬ情報検証部は、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュする、請求項１から４のいずれかに記載のＵＲＬ検証方法。
【請求項６】
正当なｗｅｂサイトとして判断されるためのディレクトリの許容範囲を設定する、請求項１から５のいずれかに記載のＵＲＬ検証方法。
【請求項７】
証明情報生成部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮する、請求項１から６のいずれかに記載のＵＲＬ検証方法。
【請求項８】
ＵＲＬを検証するＵＲＬ検証装置であって、
Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理する、第三者機関に設けられたＵＲＬ情報証明部の前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知するＵＲＬ情報検証部を
有するＵＲＬ検証装置。
【請求項９】
コンピュータを、請求項８に記載のＵＲＬ検証装置として動作させるためのプログラム。
【請求項１】
ＵＲＬ検証装置においてＵＲＬを検証する方法であって、
ＵＲＬ情報証明部が、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理し、
ＵＲＬ情報検証部が、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する
ＵＲＬ検証方法。
【請求項２】
前記ＵＲＬ情報検証部は、利用者がｗｅｂサイトに送信する情報を入力する前に前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知する、請求項１に記載のＵＲＬ検証方法。
【請求項３】
前記ＵＲＬ情報検証部は、利用者がｗｅｂサイトを閲覧、もしくは情報を送信しようとしている端末とは異なる装置を用いてｗｅｂサイトの正当性検証を行なう、請求項１または２に記載のＵＲＬ検証方法。
【請求項４】
ｗｅｂ情報取得部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を画像化し、前記ＵＲＬ情報検索部は、該画像を撮影することによってＵＲＬ情報を取得後、正当なｗｅｂサイトのＵＲＬリストでの検索を行ない、ｗｅｂサイトの正当性検証を行なう、請求項１から３のいずれかに記載のＵＲＬ検証方法。
【請求項５】
前記ＵＲＬ情報検証部は、過去に正当なｗｅｂサイトであると判断されたＵＲＬ情報を検証済リストとして利用者側の端末にキャッシュする、請求項１から４のいずれかに記載のＵＲＬ検証方法。
【請求項６】
正当なｗｅｂサイトとして判断されるためのディレクトリの許容範囲を設定する、請求項１から５のいずれかに記載のＵＲＬ検証方法。
【請求項７】
証明情報生成部が、利用者が閲覧、もしくは情報を送信しようとしているｗｅｂサイトのＵＲＬ情報を圧縮する、請求項１から６のいずれかに記載のＵＲＬ検証方法。
【請求項８】
ＵＲＬを検証するＵＲＬ検証装置であって、
Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂを介してサイトを公開しているｗｅｂサイトに対して利用者が個人情報を送信する際に、送信先となるＵＲＬを、正当なサイト中の、個人情報の送信先となるＵＲＬを証明情報格納部内にホワイトリストとして管理する、第三者機関に設けられたＵＲＬ情報証明部の前記ホワイトリストにおいて検索し、前記ｗｅｂサイトが正当なものであるか否かを判断し、結果を利用者に通知するＵＲＬ情報検証部を
有するＵＲＬ検証装置。
【請求項９】
コンピュータを、請求項８に記載のＵＲＬ検証装置として動作させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−３３８４８６（Ｐ２００６−３３８４８６Ａ）
【公開日】平成１８年１２月１４日（２００６．１２．１４）
【国際特許分類】
【出願番号】特願２００５−１６４０４１（Ｐ２００５−１６４０４１）
【出願日】平成１７年６月３日（２００５．６．３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成１８年１２月１４日（２００６．１２．１４）
【国際特許分類】
【出願日】平成１７年６月３日（２００５．６．３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]