W3C home > Mailing lists > Public > public-bpwg@w3.org > April 2009

RE: ACTION-925: CT - same origin policy conformance

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 14 Apr 2009 17:26:02 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B401CEE950@mtldsvr01.DotMobi.local>
To: "Francois Daoust" <fd@w3.org>, "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
Thanks Francois. While we mull this over, would it be a good idea to mull this over again with the WSC folks, or have they said all they are going to on this subject?

Thanks
Jo

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Francois Daoust
> Sent: 14 April 2009 17:13
> To: Mobile Web Best Practices Working Group WG
> Subject: ACTION-925: CT - same origin policy conformance
> 
> Hi,
> 
> [I had forgotten about Monday being a bank holiday here, so I kind of
> missed the window to publish that before today's call, sorry about
> that]
> 
> 
> Context
> -----
> During last F2F, I was actioned to research existing tests to assert
> the
> existence of conformance tests around the same-origin that we could
> refer to in the Content Transformation guidelines to allow links
> re-writing (and other changes of origin). More precisely, we took the
> following resolution:
> 
> RESOLUTION: Since there doesn't appear to be a way in which the URI
> sent
> to the User Agent can be manipulated to preserve security related to
> same origin policies it is permissible for a CT proxy to act on content
> in so that security is nonetheless preserved as adjudged by conformance
> tests that are to be researched. If no such security tests can be found
> then there cannot be conformance associated with link rewriting and it
> cannot be permissible for CT proxies to do so.
> 
> Note I am talking about the same-origin policy here, and not about
> HTTPS
> links re-writing, although that is part of it.
> 
> 
> 
> In short
> -----
> There are test suites. None of them pretends to be complete.
> No existing browser fully respects the same-origin policy.
> Well, the same-origin policy does not even "exist" on a normative
> basis.
> I do not see what we could refer to in the guidelines, especially since
> the same-origin policy is only defined in the HTML5 draft so far.
> 
> Still, does it entail it has to be completely forbidden?
> See a couple of proposed resolutions at the end of the email.
> 
> 
> 
> In not so short
> -----
> 1. The same-origin policy is defined in the HTML5 document:
>   http://www.w3.org/TR/html5/browsers.html#origin

> It is not defined anywhere else (normatively, that is). HTML5 is a
> draft. Unless I missed something, the group has no existing test suite
> to ensure the same-origin policy is enforced for the time being.
> 
> 
> 2. The DOM conformance test suite mentioned during the F2F does not
> contain security-related tests, and is not of much help here.
> 
> 
> 3. The "Browser Security Handbook, part 2" by Michal Zalewski is a
> must-read on the topic:
>   http://code.google.com/p/browsersec/wiki/Part2

> 
> It helps categorize the areas of application of the same-origin policy:
>   * same-origin policy for DOM access
>   * same-origin policy for XHR calls
>   * same-origin policy for cookies
> [* we're probably less interested in Flash, Java, Silverlight, and
> Gears
> here]
> 
> It shows that no two desktop browsers behave identically, the most
> prominent difference being that the port number is not part of the
> definition of an origin (for DOM access) in IE. Mobile browsers are not
> mentioned, but I'd be very surprised if we find consistence there.
> 
> 
> 4. There are a few test suites available, none of them "official". One
> of them ships with the above mentioned handbook:
>   http://lcamtuf.coredump.cx/dom_checker/

> I am not sure what functionality it covers. I am sure that none of the
> existing desktop browsers passes the test suite so far.
> 
> There are other test suites available. The Stanford Web Security
> Research center made a lot of research around the same-origin policy,
> e.g.:
>   http://crypto.stanford.edu/websec/cross-testing/

> 
> The problem is that all of the test suites that could be run to enforce
> that the same-origin policy is respected assume that Javascript is
> enabled and are unlikely to work on mobile browsers anyway (too heavy).
> Switching Javascript off fixes 90% of the problems, but there would
> still be security problems, in particular with cookies.
> 
> 
> 5. The same-origin policy is being debated and amended to make it
> possible to run client-side cross-origin requests:
>   http://www.w3.org/TR/2009/WD-cors-20090317/

>  From a security experts perspective, rules are way too loose. From a
> developer's perspective, rules are way too strict.
> 
> I don't quite see how we could come up with mandatory conformance
> requirements on such a moving target.
> 
> 
> 6. Rewriting links is a bad idea, in particular because it adds
> potential security flaws on top of the already existing ones in the
> browsers. I note that, as opposed to our other issue on HTTPS where
> there is no way to protect the content (it has to be decrypted on the
> CT-proxy), it is still possible to ensure that the same-origin policy
> is
> respected from a purely technical perspective here. That makes it a
> "strongly NOT RECOMMENDED" guideline, IMHO, which could perhaps be
> emphasized by an additional guideline that says "if you do it, you MUST
> ensure that the resulting content sent to the client is purely static
> (no Javascript, no Cookie, no Flash, ...)".
> 
> 
> 
> Conclusion
> -----
> a) We can stick to the resolution we adopted:
> RESOLUTION: Since there doesn't appear to be a way in which the URI
> sent
> to the User Agent can be manipulated to preserve security related to
> same origin policies it is permissible for a CT proxy to act on content
> in so that security is nonetheless preserved as adjudged by conformance
> tests that are to be researched. If no such security tests can be found
> then there cannot be conformance associated with link rewriting and it
> cannot be permissible for CT proxies to do so.
> 
> Since there does not seem to be any way to refer to an existing test
> suite, links re-writing is forbidden. It means, among other things,
> that
> pagination cannot be done by conforming CT-proxies, AFAICT. This would
> also put an end to HTTPS links re-writing.
> 
> 
> b) We can stick to the resolution and decide to rely on HTML5 to come
> up
> with a conformance test suite on the same-origin policy since they are
> defining it.
> 
> 
> c) We can decide to be slightly less strict and allow that to happen
> provided the result is purely static:
> PROPOSED RESOLUTION: Links re-writing is strongly NOT RECOMMENDED
> because it jeopardizes the same-origin policy if no appropriate
> security
> measures are taken on the proxy. When links are re-written, proxies
> MUST
> ensure that the resulting content is purely static, and MUST therefore
> remove all scripting and cookies from the content served to the client.
> 
> d) We can decide to leave security considerations at an informative
> level:
> PROPOSED RESOLUTION: Links re-writing is strongly NOT RECOMMENDED
> because it jeopardizes the same-origin policy if no appropriate
> security
> measures are taken on the proxy. Areas affected include DOM access,
> Cookies, and XHR calls.
> 
> Both proposed resolutions are written using casual-discussion terms and
> would need to be more precise, but you get the idea...
> 
> 
> Francois.

Received on Tuesday, 14 April 2009 16:26:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC