Here's the best part -- these websites are built terribly and are very open to this sort of thing.
After about 2 minutes of looking, I've just found that nic.io (or just io.) basically lets you type arbitrary html into the search boxes. Chrome's built in XSS auditor catches any scripts you put in there, but (at least) Firefox doesn't.
If you load it in Firefox (or any browser without an XSS auditor) it'll pop an alert, otherwise you'll just see the image I loaded and a link I inserted.
According to the article, the problem is local to Internet Explorer though.
Essentially, if "intranet" mode is enabled and a website is hosted locally, IE will ignore browser same-origin policy. So a script from http://networkmachine can access all your cookies.
IE hate is very outdated, but the fact that a website hosted locally can have access to all the data the browser stores is mind-boggling. A nondescript dialog is all that stands to protect users.
Hi. I am one of the authors of (http://www.icann.org/en/groups/ssac/documents/dotless-domain...) this report mentioned in there. Our study included a much broader scope than SAC 053 mentioned in the article. The idea was to take a very broad, holistic, view of the key infrastructure and systems on the Internet and determine the risks dotless names may pose. How would behavior be different with dotless names, etc. Our report basically answers your question, I think, so I won't answer it here :)
I suspect ICANN are thinking about the long game - if, as a matter of policy, there are no valid dotless domains, then developers of user agent software are unlikely to attempt to resolve them (other than using a search list or hosts file) in the first place.
But current clients all handle single label names via normal DNS resolution.
This is how many office PCs find their file servers. People are not going to give up the habit of using single label names on the LAN just so ICANN can start collecting rent on that namespace.
The IAB put out a statement “Dotless Domains Considered Harmful” that explains some of the risks if ICANN changed the rules to allow them. As it stands, they were already prohibited and this resolution reaffirms that.
> As it stands, they were already prohibited and this resolution reaffirms that.
Slight nitpick: they were prohibited only without prior ICANN approval (second whereas). Companies like Google attempted to get that approval (Google wanted "search"), which spurred ICANN into making a decision about what circumstances they would allow them. This decision essentially states ICANN won't approve any dotless domains.
Presumably to stop someone from registering a new top-level TLD "reports", putting an A record on it, and then your attempt to access an intranet site http://reports/ suddenly going somewhere you didn't expect.
In some intranets, users might be relying on mDNS (Bonjour) or WINS (SMB/CIFS) name resolution, rather than static DNS; both of those mechanisms, by default, get resolved at lower-priority than DNS (because they're quite slow, so you don't want your computer checking them first every time), so if there's a real DNS entry it'll get used.
Linux's mDNS support is split into two parts--mDNS presence (which uses cached/recently broadcast-announced values), and mDNS resolution (which doesn't.) If you don't have a name cached, the first part won't know about it, so you'll hit DNS lookup before failing back to full mDNS resolution. Basically, it becomes a race condition of when you last brought the machine up.
The SSAC report on dotless domains[0] has information on possible security related risks that might occur for these types of domains.
Additionally, this informational Network Working Group draft has information on the status of existing dotless domains, without expressing an opinion on security or stability[1]
I don't find it necessary for security. One way of safeguarding security across the board is to use reserved words like "intranet" for the intranet (duh) and "localhost" for the same machine.
THE END
That alone won't address all of the concerns. Another study they did, related just to their gTLD stuff, was to see which dotless name queries get leaked to the root servers. This name collision report is quite interesting and addresses the question of which names are probably in common use: http://www.icann.org/en/about/staff/security/ssr/name-collis...
Anyhow, our research and testing (I am one of authors of one of the studies mentioned in the posted article) found that the issues found with SAC 053 have the potential to be much more wide spread. There is also a scary problem called universal XSS.
There were no real smoking gun security issues, so you can make a pretty decent argument about the security impact not being too great (we had many such debates internally), but we are talking a core Internet system. The namespace collision issue is huge.
I see what you mean regarding namespace collision, but if we always set a standard based on the lowest common denominator we'll end up being stuck with practices that were followed because there was no reason not to.
As for the universal XSS, this can be solved at the browser and page level. First the gTLD as any other level should be explicitly declared in the script URL from the open page and second the browser blocks all the rest.
Page 7 of the report gets into the details a bit, from what I understand things like localhost where it's assumed that it's internal, and other assumptions made previously with regards to MX records/CAs.
So did .ai., at least for certain people (or maybe it was just the A record, but A records are enough for mail deliverability in the absence of an MX). I had one, back when I lived next to the .ai. registrar on Anguilla and shared his (very expensive) T1 via 10base2 ethernet.
DNS root domains have no names. That makes http://ai/ a fully qualified domain name. But apparently ICANN has now banned such things. Gods know why. My eyes glazed over after the 10th "whereas". That document reads like a legal document. Ugh
news.ycombinator.com is actually news.ycombinator.com. with a period at the end. http://ai./ is basically the same as http://com./, except that com doesn't have any IPs configured.
> Can something with the dot at the end have a different IP?
I guess or maybe you can do a hostname match. However, I remember back in the days Microsoft used to use
http://microsoft.com. as their test site. Now it just yields an error.
That's because Microsoft uses hostname-based virtual hosting in IIS, and IIS happens to not recognize HTTP Host headers with trailing dots. This has nothing to do with IP addressing or DNS. In the absence of a resolver search list — which conventionally only applies to names without trailing dot — "microsoft.com" and "microsoft.com." result in the same DNS query, and therefore the same set of IP addresses.
Whether this behavior is an obscure bug, a security feature, or both, is left as an exercise.
Wildcard certificates are only valid for the subdomain level directly under it. [1]
If I get a wildcard certificate for example.com (the common name is set to *.example.com), foo.bar.example.com will throw an error.
The specification isn't particularly clear, but it seems to me that RFC 2818 section 3.1 [1] could permit some dangerously broad wildcards like ".com", "www..com", or even ".". Combined with subject alternate names, it may be possible to create a certificate that's valid for almost anything.
IIRC, top-level and "match all" wildcard certificates were originally permitted by design (e.g., for intranet and proxy applications), but most modern browsers block them for security reasons.
;%3C/script%3E%3Ch3%3E){kind=link}
[1]https://superevr.com/blog/2012/top-level-universal-xss/