Last modified: Fri Apr 16 13:42:54 2004 +0900 (JST) - $Revision: 1.14 $
from RFC2616: Hypertext Transfer Protocol -- HTTP/1.1:
14.36 Referer
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
リンクをたどるときに、 「あなたのページをリクエストする前はこの URL を見ていました」 ということをクライアント (web ブラウザ) からサーバに伝えるためのヘッダです。 Referer はリンクをたどるときにのみ出力されるため、Referer の値を観察することにより「自分のページがどこからリンクされているのか」を知ることができます。
from RFC2616: Hypertext Transfer Protocol -- HTTP/1.1:
15.1.3 Encoding Sensitive Information in URI's
Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
プライバシーや社内 (ファイアウォール内部) 情報の漏曳が発生します。 また、web メールなど web 上で提供されているサービスの中には、 Referer リクエストヘッダに含まれる情報を悪用されるとサービスを乗っ取られるなどの脆弱性を有するものがあります。 適切に設計・実装されたサービスばかりが存在するなら問題ないのですが、実際には脆弱性を有するサービスは少なくないようです。 事例:
さらに、ブラウザのバグのために、link されていないにもかかわらず Referer が流出してしまうことがあります。 これも、悪用されるとプライバシー漏曳や社内情報の流出につながる恐れがあります。 事例: Re: ブラウザのRefererに関する異常動作。
Referer リクエストヘッダを送信しないようにすればいいです。
ただし、相手側 web サーバが Referer リクエストヘッダに基づくサービスを提供している場合は、Referer リクエストヘッダを送信しないようにすると動作不良が発生する可能性があります。
Referer リクエストヘッダの本来の目的は、
RFC2616
に
The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance
とあるように、利用者のナビゲート支援にあります。
Referer に基づく高度なナビゲートを提供しているサイトでは、
Referer 送信を停止するとナビゲートに支障が生じる可能性があります。
また、おうおうにして Referer をアクセス制御に用いてしまうサイトがあります。 たとえば Referer リクエストヘッダにある特定の値が設定されている場合にのみアクセスを許可する、というような形での利用です。 具体的には、アクセスカウンターや web 掲示板など CGI で提供されるサービスのかなりは Referer リクエストヘッダが特定の値 (カウンターや web 掲示板を設置してある URL) となっていないと動作しないようです。 このような方法は「カウンター荒らし」「掲示板荒らし」の対策として広く利用されているようなのですが、上記のように Referer はいくらでも偽造可能なため、 まじめな (?!) 「荒らし」の対策にはならないということを理解する必要があります。
ただし、「荒らし」フォーム/リンクを設置した悪意ある web ページに誘導するなどして、攻撃する意思のない一般ユーザに「荒らし」をさせる、などといったものに対しては、Referer によるチェックは一定の効果を持っていると考えられます。 セッション管理の脆弱性 においても、Referer: を用いた脆弱性回避方法が記述されています。
あと、web サーバ管理者は Referer をたよりにリンク元ページを検知している場合があります。 Referer がなくなるとこれが不可能になり困ると感じる人は少なくないようです。
コンパイル時に SECURE を定義します。
-noreferer オプションをつけて起動します。
Option Setting Panel で「Referer: を送らないようにする」を ON にし、[OK] を選択します。 w3m の再起動は必要ないです (from 関谷さん)。
prefs.js (UNIX なら $HOME/.netscape/preferences.js) をテキストエディタで編集し、 user_pref("network.sendRefererHeader", false); という行を追加し、Communicator を再起動します。
なお、志村さんから「$HOME/.netscape/preferences.js を書きかえても、 netscape が終了する時点で元に戻ってしまう」という現象が報告されています。 ja-netscape-communicator-4.61 (FreeBSD 3.3-RELEASE), netscape-communicator-4.7 (LASER5 Linux 6.0) で発生するそうです。 小島の手元では発生しないのでよくわかりません。
岩本さんは、Communicator を起動したまま preference.js を編集すると、 Communicator 終了時に上記現象が発生することを確認されたそうです。
2002.04.22 追記
西川さんから、上記を行っても「JavaScript を有効にしていると JavaScript の変数 document.referer に Referer 情報がきっちり記録されている」との情報をいただきました。 Netscape 6 (Mozilla) の場合は document.referer も無効になるそうです。
Windows 98 の場合、 C:\Program Files\Netscape\Netscape 6\defaults\pref\all.js の pref("network.sendRefererHeader", 2); という行を pref("network.http.sendRefererHeader", 0); と変更します。 (from [memo:551])
あるいは、ユーザプロファイルにある pref.js に user_pref("network.http.sendRefererHeader", 0); と書きます。(from [memo:826])
squid.conf で設定します。
1.x では http_anonymizer を設定します。 http_anonymizer standard あるいは http_anonymizer paranoid で Referer が削除されます。
2.x では anonymize_headers を設定します。 たとえば、 anonymize_headers deny Referer とします。squid.conf のコメントを参照してください。
上記では Referer が常に削除されてしまうため、 前記したように CGI 関連で不具合が発生します。 これを防ぐため、別ホストに移動する場合のみ Referer を削除するようにする patch をたかださんが作成されています。 Tea Room for Conference の No.238 の議論も参照してください。
squid 2.5 以降では、 acl を利用して特定の referer を送出しないようにできます。 たとえばこのように使います。
acl internal referer_regex ^http://[^/]+\.example\.co\.jp ^http://192\.168\. ^[a-zA-Z]:\\ header_access Referer deny internal
次のような cfi スクリプトを DGROOT/lib/killreferer.cfi に用意します。
#!cfi Remove/Referer:
その上で、delegate の起動オプションに FTOSV=killreferer.cfi を指定することで Referer を削除できます。 なお、この場合FTOSV="data:,#!cfi%0ARemove/Referer:%0A" としてもよいです。 参照: [DeleGate] Re: Referer リクエストヘッダの除去
wwwoffle.conf で以下のように記述すると Referer が特定の値になります:
CensorHeader
{
Referer = http://some.url.com
}
Referer = とすれば Referer を空にできます。
他に referer-self や referer-self-dir も利用できます。 詳細は wwwoffle.conf のサンプルや man wwwoffle.conf を参照してください。
Junkbuster はプライバシ強化が目的の proxy server です。 Windows と UNIX で動作するようです。 Refere を削除あるいは特定の値とするには、次のようにします:
# referer specifies treatment of the "Referer:" header # default : Kill the referrer-header from the client # . : Pass the referrer unchanged # 'text' : Always sendas the referrer # @ : Pass the referrer if the server is in the cookie file, # kill the referrer otherwise referer 'http://www.google.com/'
Doorman@JUMPERZ.NET は Windows 対応の「多目的 TCP/IP ネットワークテストツール」です。 シェアウェア 5000 円です。
Referrer の変更・削除については HTTP リクエストをカスタマイズする を参照してください。
Windows 対応の「非常に柔軟なカスタマイズが可能」な proxy server。 デフォルトの Referer 書き換えは少年ナイフのオフィシャルサイトになっているそうです。 関連記事: Webブラウジングを快適にする「The Proxomitron」。
どこを変えればいいのかは一目瞭然ですね。
from 土居@シャープさん: ネットワーク切り替え機能に Referer カットの有無を連動できるので、 あるネットワーク設定では Referer カット有り、 他のネットワークではフリーパスという風にプライバシーのレベルを切り替えることができます。
この他のブラウザ、proxy サーバに関する情報をお持ちの方はぜひおしえてください。
FWD fw-wizard ML のみなさん、 Tea Room for Conference のみなさん、 セキュリティホール memo ML のみなさん、 四方さん、関谷さん、金床さん、北條さん、なゆたさん、佐藤さん、土居さん、志村さん、岩本さん、高木さん、西川さん、山賀さん。