現在地 HOME > 掲示板
> ＩＴ7 > 306.html
★阿修羅♪
|
現在地 HOME > 掲示板
> ＩＴ7 > 306.html
★阿修羅♪
|
|
| Tweet |
参照スレ http://www.asyura2.com/0406/kanri7/msg/840.html">http://www.asyura2.com/0406/kanri7/msg/840.html
投稿のためには REFERRERを有効に 投稿者 管理人さん 日時 2005 年 1 月 27 日 23:02:13:Master
今回の件ですがWindowsでNorton使ってなくても、私の様にLocalに proxy
(キャシュサーバー )を立ててバナーを叩き落したり Redirectするついでに
header_access Referer deny all
している環境では OS、ブラウザに関係なく全部 Forbiddenで蹴られてしまいました。
それ以外でもRefererを送らないのがdefaultになっている環境もあると思います。
(自分が管理者ではないproxyを通してしか外に出られないとか)
別に悪いことをしようというのではありません。悪いことをされないようにということ
なのですが。で、ごにょごにょして FirefoxだけRefererを「任意」にAllowするように
しましたが、投稿したら元に戻します。
ブラウザからどんな情報が流出？しているかは
確認くん http://www.ugtop.com/spill.shtml">http://www.ugtop.com/spill.shtml
Envchecker http://www.cybersyndrome.net/evc.html">http://www.cybersyndrome.net/evc.html/
板荒し対策で、「up.cgiに直リン貼られたらタマラン」という理由でReferer
でのアクセス制限をとすれば以下にあるようにRefererの偽装が容易な
ことも留意する必要があります。.......どう偽装するのかって.......まあ、その
とにかく、よくわからないままで許可するのはcookieよりはるかに危ない
のではないでしょうか。
RFC2616のhttp://www.mars.dti.ne.jp/~torao/rfc/rfc2616-ja.txt"> 和訳もあります。
引用元http://www.st.ryukoku.ac.jp/~kjm/security/memo/referer.html">http://www.st.ryukoku.ac.jp/~kjm/security/memo/referer.html
-------------------------------ここから引用 -------------------------------------
fromftp://ftp.st.ryukoku.ac.jp/pub/internet/rfc/rfc2616.txt">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の値を観察することにより「自分のページがどこからリンクされているのか」を知ることができます。
fromftp://ftp.st.ryukoku.ac.jp/pub/internet/rfc/rfc2616.txt">RFC2616:Hypertext Transfer Protocol -- HTTP/1.1:
15.1.3Encoding Sensitive Information in URI's
Because the source of a link might be private information or mightreveal 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リクエストヘッダに含まれる情報を悪用されるとサービスを乗っ取られるなどの脆弱性を有するものがあります。適切に設計・実装されたサービスばかりが存在するなら問題ないのですが、実際には脆弱性を有するサービスは少なくないようです。
事例 :http://securit.etl.go.jp/SecurIT/advisory/webmail-1/"> Cookieを使用せず URLに埋め込む ID に頼ったセッション管理方式の脆弱性 (1);REFERER情報取得による脆弱フリーメールサイトの乗っ取り問題
[JavaHouse-Brewers:33024]http://java-house.etl.go.jp/ml/archive/j-h-b/033024.html">任意のホストに接続できてしまうセキュリティ上の欠陥がもたらす危険性
さらに、ブラウザのバグのためにlinkされていないにもかかわらず Refererが流出してしまうことがあります。これも、悪用されるとプライバシー漏曳や社内情報の流出につながる恐れがあります。
事例 :http://www.st.ryukoku.ac.jp/~kjm/security/memo/referer-bug.txt">Re:ブラウザの Referer<に関する異常動作。
Refererリクエストヘッダを送信しないようにすればいいです。
ただし、相手側 webサーバが Refererリクエストヘッダに基づくサービスを提供している場合はRefererリクエストヘッダを送信しないようにすると動作不良が発生する可能性があります。
Refererリクエストヘッダの本来の目的は、ftp://ftp.st.ryukoku.ac.jp/pub/internet/rfc/rfc2616.txt">RFC2616に TheReferer request-header allows a server to generate lists ofback-links to resources for interest, logging, optimized caching,etc. It also allows obsolete or mistyped links to be traced formaintenance とあるように、利用者のナビゲート支援にあります。 Refererに基づく高度なナビゲートを提供しているサイトでは、 Referer送信を停止するとナビゲートに支障が生じる可能性があります。
また、おうおうにして Refererをアクセス制御に用いてしまうサイトがあります。たとえば Refererリクエストヘッダにある特定の値が設定されている場合にのみアクセスを許可する、というような形での利用です。具体的には、アクセスカウンターや web掲示板など CGIで提供されるサービスのかなりは Refererリクエストヘッダが特定の値 (カウンターや web掲示板を設置してある URL)となっていないと動作しないようです。このような方法は「カウンター荒らし」「掲示板荒らし」の対策として広く利用されているようなのですが、上記のように Referer/はいくらでも偽造可能なため、まじめな(?!)「荒らし」の対策にはならないということを理解する必要があります。
ただし、「荒らし」フォーム /リンクを設置した悪意ある webページに誘導するなどして、攻撃する意思のない一般ユーザに「荒らし」をさせる、などといったものに対しては、Refererによるチェックは一定の効果を持っていると考えられます。
http://www.japu.org/cgi/security/session_vulnerability.html">セッション管理の脆弱性においても、 Referer:を用いた脆弱性回避方法が記述されています。
あと、 webサーバ管理者は Refererをたよりにリンク元ページを検知している場合があります。 Refererがなくなるとこれが不可能になり困ると感じる人は少なくないようです。
(※バルタン注:Firefoxなら手で書き換えるような危険な方法でなくpref.jsを操作できるPrefBarという拡張機能があります。)
http://www.squid-cache.org/">squid(※バルタン注:このディレクティブはSquid-2.4.Xのものです。2.5STABLEでは書式が変わっています。)
acl internal referer_regex ^http://[^/]+\.example\.co\.jp ^http://192\.168\. ^[a-zA-Z]:\\header_access Referer deny internal
#!cfiRemove/Referer:
CensorHeaderReferer = http://some.url.com
# referer specifies treatment of the "Referer:" header
# default : Kill the referrer-header from the client
# . : Pass the referrer unchanged
# 'text' : Always send as the referrer
# @ : Pass the referrer if the server is in the cookie file,
# kill the referrer otherwise
referer 'http://www.google.com/'
この他のブラウザ、 proxyサーバに関する情報をお持ちの方はぜひおしえてください。
http://www.firewall.gr.jp/">FWDfw-wizard ML のみなさん、http://www.office.ac/tearoom/noframe.cgi">Tea Room for Conference のみなさん、 http://memo.st.ryukoku.ac.jp/">セキュリティホール memoMLのみなさん、四方さん、関谷さん、金床さん、北條さん、なゆたさん、佐藤さん、土居さん、志村さん、岩本さん、高木さん、西川さん、山賀さん。
-------------------------------引用おわり -------------------------------------
題名には必ず「阿修羅さんへ」と記述してください。