オンライン詐欺との戦いに活用できる「リファラ」フィールド

　通常「referrer（リファラ）」ヘッダーは，特定のWebサイトがどのような経路（外部Webサイトのリンクや検索エンジンなど）でアクセスされたのかを調べるため，バックリンクをたどる目的で利用する。HTTP仕様を規定しているRFC2616には，「クライアントはリファラ・リクエスト・ヘッダー・フィールドで，リクエストURIの取得に使えるリソースのアドレス（URI）を（サーバーで利用するために）特定できる（ヘッダー・フィールドは『referrer』の誤記）」とある。

　オンライン詐欺の分野だと，リファラ・フィールドは新たなフィッシング・サイトの発見にも使える。例として，以下のフィッシング・サイトを紹介しよう（このWebサイトでは，Rock Phish攻撃も行われている。関連記事：Rock Phishに対する心構え）。

　このWebサイトは，アクセスしてきた一般ユーザーからフォームを受け取ると，入力された信用情報を保存したうえで，このユーザーのアクセスを本物のオンライン・バンキング・サイトへリダイレクトする。リダイレクトが実行されると（この時点で標準的なHTTP 302「Moved Temporarily」エラーも発生する），ユーザーのWebブラウザは「Location」フィールド内にあるURLを要求する。そして，そのHTTPリクエスト・ヘッダーに，フィッシング・サイトを示す絶対URIの入ったリファラ・フィールドを作る。

　サーバー側で全HTTPリクエストのリファラ・フィールドを記録し（読者の使っているWebサーバーのドキュメントに目を通せば記録方法はすぐに分かる），未知のリファラを見つけたら警告するような通知システムを作ることは，簡単にできる。このシステムの運用開始当初は，Webサイトの正当なリンク関係をしかるべきホワイトリストとして蓄積するために，若干の調整作業が必要となるだろう。さらに，フィッシング・サイトの多くは擬装対象の合法サイトから各種リソース（画像，CSSファイル，JavaScriptファイルなど）を取得しており，サーバーのログに本物のWebサイトとよく似た記録を残す。

　この単純な早期警戒システムは，フィッシング・サイトが合法サイトからリソースを取得せず，フィッシング「セッション」の最後にユーザーをリダイレクトしないという回避策を取るだけで，やすやすと迂回されてしまう。なお，現時点で存在が知られているフィッシング・ツールのほとんどは，攻撃全体の信頼性を高めるためにこの回避策を導入している。

　もう一つ考えておく必要があるのは，多くの場合，フィッシング犯がいつ新たな詐欺サイトを開設し，サイトの動作試験段階でフィッシング・メールを送る前に何を行うか，である。考えておけば，以下に示す二つのメリットが得られる。

・新たに機能し始めたフィッシング・サイトが初めて出すリファラは，フィッシング犯の使っているIPアドレスから送信されるだろう。つまり，金融機関は犯罪者の追跡と起訴に使える重要な情報を捜査当局に提供できる

・金融機関は，フィッシング・メールが送信される前であっても新たなフィッシング・サイトを見つけられる。そのため，損害を最小限で抑えるのに重要なインシデント（事件）対応処理を，素早く開始できる（関連ブログ記事）。

　フィッシング犯が用心深く，（乗っ取ったパソコンやサーバーをプロキシとして使うなどして）身元を隠すことができるとしたら，これら情報は追跡の役に立たない。ただし我々は，たいていの場合フィッシング犯がそのような隠ぺい工作を使わないことに気付いている。つまり，あるIPアドレスが怪しいかどうかは，かなり簡単に判別できるのだ。

　最後に，フィッシング用であると確認されたURLを指しているリファラ・フィールドの件数を数えると，フィッシング・サイトにアクセスして情報を入力した人の数が分かる。人数が分かると，以前ブログ記事で取り上げたように攻撃の危険度を推測できるほか，後日さらに詳しく検討する際の足がかりとなる。

---

Copyrights (C) 2008 Symantec Corporation. All rights reserved.

本記事の内容は執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。
◆この記事は，シマンテックの許可を得て，米国のセキュリティ・ラボの研究員が執筆するブログSecurity Response Weblogの記事を抜粋して日本語化したものです。オリジナルの記事は，「"Referer" Field Used in the Battle Against Online Fraud」でお読みいただけます。