- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 14 Apr 2009 17:26:02 +0100
- 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