Today I was at a client site who happens to have various internal websites and a funny little thing happened. I had saved some bookmarks to some of their sites, however, when I VPN'ed back into the office the dominant domain was not that of the client, but of the office, so when I went to the site, it couldn't find that site within the context of my current domain name, so it took me to another site on the tubes, which got me thinking of different failures of a browser.

In firefox there is a config item called: browser.fixup.alternate.suffix

The default setting for this is to append .com to anything it cannot resolve locally. Along with browser.fixup.alternate.prefix (www.) I realized that the current thought of security that involves having internal TLD's is quite vulnerable to some major information leakage.

Basically what happened today was this:

I wanted to visit a specific place on the internal wiki:

http://wiki/some_very_descriptive_info_of_who_the_client_is/other_information

I ended up at:

http://www.wiki.com/some_very_descriptive_info_of_who_the_client_is/other_information

Sure, including the full domain value does help in this situation, but the part that worried me is the scenario where Joe User takes his laptop to a coffee shop and accidentally hits a bookmark to go to http://wiki.internal.domain/blahblah. Being that he's on the coffee house network they won't know squat about the .domain TLD so he'll end up going to http://www.wiki.internal.domain.com.

Needless to say, I've cleared out both .suffix and .prefix from my firefox config, but with the proliferation of internal TLDs, I think browsers should have the ability to define those TLDs so that internal company information is not passed along to untrusted sites.

Thoughts?

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Yeah a client should always query a DNS cache first, then DNS, then internal browser settings. DNS has first priority before anything else. (or at least it should) if that DNS is at the ISP, locally or some place else doesn't matter much as it doesn't broadcast beyond your network.

However, on the looks of it it might leak the referer which is an information leakage. I've seen it quite often of folks who visited my website, clicking/browsing from their Intranet with referer enabled, and broadcasting along their platform, ports, and other info that can be used to target them, like CSRF them.

rvdh - exactly.. it just really should not be adding anything to the url you went to.. maybe it should verify if it connected to something on that URL and if it did, there really is no need to add .com.

the other question which someone here might know is how the browser treats these entities, does hxxp://wiki == hxxp://www.wiki.com since the browser added the prefix and sufix.. it'd be interesting to see if it does mean the same because if it does, chances are it will send along login credentials..

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

In Mozilla it queries your DNS and host file first, like: foo.local if it's unknown (which it is) it will query Google, if Google finds it, it will 302 it to that domain.

but does it handle foo.local the same way as www.foo.local.com.. at which point it will send foo.local's credentials to www.foo.local.com since it added the prefix/suffix? you guys know waaaaaay more about this stuff than I do.. :)

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Well, I look at my packet sniffer (like wireshark for example) all day, so I see it fly it by every now and then. :)