In HTML5 6.3.1 Relaxing The Same Origin Restriction [1] bullet 3, sub bullet 3 
there is a clause that says that if the domain is reduced down to something 
that is on the Public Suffix List, the new value is rejected.  That phrase 
caused me to pause.

I was wondering about internal attacks.  First, we need to assume a couple of 
things but they are relatively easy to assume.  The first is that the relaxing 
of the restriction has a valid use.  This seems easy or it would not be in the 
spec.  The second is that an internal domain can effectively be a public suffix 
list to users on the internal intranet.  For example, at the place I work, I 
connect my laptop to the wifi, it grabs an address and also registers the name. 
 Even if the name was not registered, it would still have some DNS entry.  The 
point is that all DNS entries within this subdomain are not trusted.

If we have a site like official_site.area_subdomain.big.com which relaxes the 
restriction to area_subdomain.big.com, it is now exposed to the potential of an 
attack from any of the systems within the same area_subdomain including laptops 
connected via wifi.  The wifi is secure.  The place I work at trusts me to some 
degree but with a large corporation, they very often try to restrict 
information on the "need to know" basis.  And, corporate espionage is a real 
threat.

I don't know how common it is for internal corporate sites to relax the same 
origin restriction but I could see it becoming more and more common as they try 
to take advantage of various technologies.

The corporations could take steps of course to secure the sites.  They could 
put all official web sites in their own subdomain and then relax to this more 
trusted subdomain.

The purposed of this email is to ask if a warning should be added in the 3rd 
bullet to advise web developers of internal sites to be careful in assuming 
that all the hosts on their internal subdomain are trusted.

Thanks,
Perry

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#relaxing-the-same-origin-restriction

Reply via email to