On Sun, 9 May 2010, Perry Smith wrote:
>
> 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.
I would be happy to add such a warning, but I'm not sure I understand the
attack you had in mind.
Is this the scenario you have in mind?:
User A controls a laptop within Example Corp's firewall and has a host
name of laptop1.corp.example.com.
User B is also within the firewall.
Service V is at service.corp.example.com, and it uses document.domain
to relax its same-domain restrictions to "example.com".
User A tricks User B into visiting a file hosted on his laptop.
That file relaxes its same-domain restriction to "example.com", loads
service V in an iframe, and uses the DOM to perform an attack on V
using B's credentials.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
