■ フィッシング詐欺とは？

　フィッシング(phishing)とは、なんらかの方法によって悪意のある者が仕掛けた「罠」に誘き寄せ、ユーザを騙す手口です。現在のところ誘き寄せる手段としては、メールが使用されています。騙されたユーザが、もしIDやパスワード、クレジットカード番号、暗証番号などを偽のサイトに入力してしまった場合、それらの情報が悪意のある者に渡ってしまいます。
以前は主に英語圏においてフィッシング詐欺が流行していましたが、最近では、UFJ銀行などをターゲットにした日本語によるフィッシング詐欺も発生しています。また、フィッシング詐欺はターゲットが銀行やクレジットカード会社などの金融機関が一般的でしたが、現在ではYahooオークションやeBay、MicrosoftのWindows Updateなどの偽サイトも発見されており、ターゲットは多岐に渡っています。

■ フィッシング詐欺で何が起きるのか？

　フィッシング詐欺は、巧妙にユーザを騙します。その手口の巧妙さ次第ではありとあらゆる情報が漏洩する可能性があります。
　たとえば、ユーザIDとパスワードの他に第二認証として乱数表を使用しているオンラインサービスがあるとします。このシステムではユーザIDとパスワードが漏洩しても乱数表がない限りサービスを利用することができないようになっています。乱数表は正規のユーザのみが保有しそれぞれのユーザによって値が異なるため、第三者が推測するのは困難です。これはシステム面だけ見れば強固です。
　このシステムのセキュリティを台無しにしてしまうのがフィッシングです。偽サイトにおいて「セキュリティの強化のため乱数表の値が変更になります。現在使用している乱数表の値をそのまま入力することで、新しい乱数表を自動的に生成します」というようなもっともらしい表示があったときに、乱数表のすべての値を入力してしまうユーザがいないとも限りません。
　データベースからは最悪の場合でも登録されている情報しか洩れませんが、フィッシングの場合は、ありとあらゆる情報が洩れる可能性があります。これがフィッシング詐欺の恐ろしいところです。

■ フィッシング詐欺は誰のせいなのか？

　フィッシング詐欺で悪いのは誰でしょう。もちろん、騙そうとしている人がもっとも悪いことは明らかです。しかし、ユーザが気をつけていれば情報を盗まれることはありませんので、偽サイトに情報を入力してしまったユーザに過失が全くないとも言えません。また、本物のサイトか、偽のサイトか区別ができないような作りのWebサイトにも過失がないとも言えません。

■ フィッシング詐欺の手口

　現在最も頻繁に使用される手口であるメールを使ったフィッシング詐欺について説明します。以下は、Washington Mutual の顧客を狙ったフィッシング詐欺についての例です。
まず、騙そうとしている人間は、以下の様なメールをユーザに送りつけます。

　メール内のリンクをクリックすると、次のようなページが表示されます。

　このサイトは、偽のサイトです。URLがhttpsから始まっているにも関わらず、SSLの使用を示す右下の鍵マークが表示されていないことに注目してください。これはURLの部分をJavaScriptによって書き換えているため、このような表示になっています。

以下が本物のサイトです。

　こちらは、正しく鍵マークが表示されています。

　フィッシング詐欺の手口は様々ですが、代表的な方法としては以下が挙げられます。

1. メールを利用して、本物のサーバとは別の偽のサイトに誘導する方法
2. キャッシュ汚染やクライアントの HOSTSファイル[1] を利用して、偽のサイトに誘導する方法
3. クロスサイトスクリプティングの脆弱性を利用して、改ざんされた本物のサイトに誘導する方法

　フィッシング詐欺の手口のうち、前記2パターンは偽のサイトに誘導しているため、SSLを確認することで防止することができます。しかし、最後のクロスサイトスクリプティングを利用した手口では、本物のサイトを使っているため、SSLで確認することでは防止できません。

■ フィッシング対策として、ユーザが気にしなければならないこと

URLを確認する

　偽のサイトに誘導しているかどうか、ステータスバーやアドレスバーを確認することで判断できる場合があります。ただしJavaScriptによる詐称の場合もありますので、注意が必要です。

SSLを使用していないWebサイトは利用しない

　SSLを使用していないWebサーバは、そのサイトが本物であることを証明する術がありません。重要な情報はSSLを経由して入力するようにしましょう。また、証明書が正しくない場合はフィッシングに対して意味を持ちません。

クライアントアプリケーションのアップデートを必ず行う

　不正なActive XやWebブラウザなどのクライアントアプリケーションの脆弱性を利用された場合、HOSTSファイルが書き換えられ、フィッシングに利用される可能性があります。アプリケーションのアップデートをこまめに行いましょう。

DNSキャッシュ、Proxyキャッシュ汚染の対策を施す

　DNSサーバのキャッシュが不正に書き換えられることでフィッシング詐欺の被害にあう可能性があります。また、HTTP Response Splitting[2] という攻撃手法により、Proxyサーバのキャッシュを不正に書き換えられ、フィッシング詐欺に利用されることも懸念されています。ユーザ側では、管理下のDNSサーバやProxyサーバのセキュリティアップデートを行うことが重要です。

もし、上記の対策が取られていない場合には情報が漏れてもユーザ自身の過失とされてしまうかもしれません。

■ フィッシング対策として、サービス提供側が気にしなければならないこと

ユーザを混乱させるような作りにしない

　Webブラウザのアドレスバーを隠したり、ポップアップで開いたウインドウに情報入力を促すようなフィッシングに利用されやすいページ構成にしないことが重要です。

SSLを必ず導入する

　SSLを利用しなければ、サービスを提供しているサーバが本物であるという証明をすることができません。裏を返せばSSLさえ利用すれば、本物のサイトであることが証明されるため、大抵のフィッシング詐欺に対して効果があります。

Webアプリケーションの脆弱性対策を施す

　WebサーバにSSLを利用し、そのサイトが本物であると証明していたとしても、クロスサイトスクリプティングやHTTP Response SplittingといったWebアプリケーション特有の脆弱性を利用することで、Webページが改ざんされてしまい、フィッシング詐欺に利用される可能性があります。
一般に、Webアプリケーションは独自に開発されていることが多いため、単純にソフトウェアのアップデートといった方法では対策できません。このため独自に脆弱性の箇所を洗い出し、問題点の修正を行わねばなりません。

　現在では、Webアプリケーションファイアウォール [3] を導入することで、これらの脆弱性の多くについて対策を施すことができます。

もし、上記を対策していない場合には、サービス提供側が責任を問われる可能性があります。

■ 解説

　フィッシング詐欺で悪いのは誰でしょう。もちろん、騙そうとしている人がもっとも悪いことは明らかです。しかし、ユーザが気をつけていれば情報を盗まれることはありませんので、偽サイトに情報を入力してしまったユーザに過失が全くないとも言えません。また、本物のサイトか、偽のサイトか区別ができないような作りのWebサイトにも過失がないとも言えません。

[1] HOSTSファイル

　IPアドレスとドメイン名の対応付けを行うシステムがDNS(Domain Name System)です。各クライアントPCが持つHOSTSファイルにその対応付けを記述することで、DNSを使用せずにIPアドレスとドメイン名の対応付けを行うことができます。両方を併用することも可能であり、その多くの場合はHOSTSファイルの設定が優先されます。

[2] HTTP Response Splitting攻撃

　Webアプリケーションが内部でリダイレクトを行っている場合に発生します。脆弱性のある箇所に改行文字を入力して意図的にWebサーバのレスポンスを分割させ、Webページの改ざんを行います。

[3] Webアプリケーションファイアウォール

　SSLを利用する前提では、End-to-Endで暗号化されるため、インライン型で設置されるようなIPS(Intrusion Prevention/Protection System)では攻撃を防ぐことはできません。Webアプリケーションファイアウォールはリバースプロキシとして動作し、本来のWebサーバの代わりとなって応答を行うため、SSLにも対応できます。