リファラーとは、あるWebサイトのページのリンクをクリックして別のページに移動したときの、リンク元のページのことを言います。
つまり、ユーザーが、あるサイトにたどり着く前に閲覧していたサイトです。
Webサーバーのアクセスログに記録される項目の1つで、リファラーをたどっていくことで、ユーザーがどのサイトから訪問したか、サイト内でどんな軌跡をたどったかなどについて調べることができます。
リファラーは貴重なソース
リファラーを調べることで、ユーザーがなぜ自分たちのWebサイトにやって来たのかあたりを付けられるようになります。
※なぜ自分のWebサイトに来たのかは、結局本人しかわかりません。もしくはWebサイトにやってきたユーザー本人も分からないかもしれません。
また、ユーザーがどこから来たのかがわかれば、さらにもう少し多くのことを知ることができます。
その結果、ユーザーにとって有益なコンテンツを考え出すことができるかもしれません。
今はGoogleは検索キーワードは公開していないので、リファラー情報は貴重なソースだと言えます。
リファラーのアクセス元URLが残る
アクセスログにはリファラー（アクセス元URL）が残ります。
当サイトの場合はこんな感じで残ります。
| www.go-journey.club 60.36.xxx.xxx – – [10/May/2017:08:12:55 +0900] “GET /archives/1430 HTTP/1.1” 200 101078 “https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=15&ved=0ahUKEwjIy6_x9-PTAhVIkJQKHY70AEo4ChAWCEEwBA&url=https%3A%2F%2Fgo-journey.club%2Farchives%2F1430&usg=AFQjCNH3cPynAYet1JwXkpuvOwuxDsiidg&sig2=BPPq22A5UFpFjjzOUYgY3A” “Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko” |
リフアラはクリック以外でも記録される
リンク元がアクセスログにリファラーとして残ります。
しかし、リンクをクリックした時だけ記録されるものかというと違います。
実は、画像を読み込んだときにも記録されます。
HTMLでは画像は<img>タグで表現されますが、画像のあるページを表示する時、ブラウザは要求されたURLについてHTMLを解析し、Webページとして表示しようとします。。
しかしimgタグを見つけると、要求されたURLとは別に画像のURLを要求し、返ってきた画像をページの中に埋め込んで表示します。
つまり、画像はその画像を含んでいるペー ジから呼ばれていることになり、画像を含んでいたページがリフアラとして記録されるのです。
ここから何が分かるかというと、黙って画像の「直リンク」をしている場合、どのサイトで画像の直リンクをしているのかバレてしまいます。
リファラーは偽造することが可能
リファラーはブラウザが自己申告している値なので偽造もできます。
Linuxならtelnetでリファラーを偽造することができます。
試しにリファラーを偽造してみましょう。
構成
Webサーバー：さくらVPS（xxx-xxxx-34861.vs.sakura.ne.jp）
クライアント：自宅Linux（centos7 ）
自宅Linuxからインターネット上にあるさくらVPSの80番ポートにtelnetアクセスします。
telnetで接続したら、ドキュメントルートのindex.htmlをリクエストして、更にリファラーを設定します。
その後、サーバーのaccess.logに手動で設定したリファラーが残っていることを確認し、リファラーが偽造できることを確認します。
まずはtelnetをインストールします。
| [root@centos7 ~]# yum install telnet 読み込んだプラグイン:fastestmirror Loading mirror speeds from cached hostfile * base: ftp.riken.jp * extras: ftp.riken.jp * updates: ftp.riken.jp 依存性の解決をしています –> トランザクションの確認を実行しています。 —> パッケージ telnet.x86_64 1:0.17-60.el7 を インストール –> 依存性解決を終了しました。 依存性を解決しました ============================================================================================ トランザクションの要約 総ダウンロード容量: 63 k インストール: 完了しました! |
次に偽造したリファラーでHTTPリクエストをサーバーへ送ります。
| [testuser@centos7 ~]$ telnet xxx-xxxx-34861.vs.sakura.ne.jp 80 ← telnetで、さくらVPSサーバーの80番ポートへアクセスします。 Trying 160.16.217.115… Connected to tk2-250-34861.vs.sakura.ne.jp. Escape character is ‘^]’. GET / HTTP/1.0 ← 「GET / HTTP/1.0」と入力して「Enter」を押下します。 Referer: http://test.com/test/test/test ← 「Referer: http://test.com/test/test/test」と入力して「Enter」を押下します。 ← 再度「Enter」を入力します。 HTTP/1.1 200 OK Date: Thu, 11 May 2017 13:47:23 GMT Server: Apache/2.4.6 (CentOS) Last-Modified: Mon, 01 May 2017 07:17:23 GMT ETag: “12-54e7136f50d8d” Accept-Ranges: bytes Content-Length: 18 Connection: close Content-Type: text/html; charset=UTF-8 test |
ここまで実行したらhttpdのログを確認します。
| [root@xxx-xxx-34861 ~]# cd /var/log/httpd [root@xxx-xxx-34861 httpd]# tail access_log 126.xx.xxx.202 – – [11/May/2017:22:47:23 +0900] “GET / HTTP/1.0” 200 18 “http://test.com/test/test/test” “-“ ← 手動で設定したリファラーがログに残っていることを確認します。 [root@xxx-xxx-34861 httpd]# |
リファラースパムとは
レンタルサーバーでWebサイトを運用していると、「リファラースパム」という用語を聞いたことがあるかもしれません。
今までのtelnetで手動でリファラーを偽造する手順を見て、「リファラースパム」の仕組みが分かったと思います。
リファラースパムとは、httpdのログにリファラーが記録されることを利用して、多数のWebサイトにリファラーを残し、アクセスログをチェックするWebサイトの管理人にクリックをさせることを言います。
Webサイトの管理人なら、どこから自分のサイトにアクセスしてきてくれたのかは、大変興味があるところです。
ついついクリックしてしまうでしょう。
何のためにリファラースパムをするのか？
何のためにリファラースパムをしているのかというと、Webサイトの管理人がクリックするリンクにウィルスを仕込んでおくとか、広告を貼っておくとかいろいろな目的があります。
ただその目的は「悪用」のためなのでリファラースパムと思われるリンクはクリックしないようにしましょう。
コメント