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

Hi Jo,

Part of the below follows from discussions with Thomas and a couple of 
security folks, not part of the Web Security Context working group. The 
responses I got were: don't do it. If you must do it, don't do it. If 
you really must do it, then at least make sure that the resulting 
content is static. And don't rely on test suites.

They pointed me to the security handbook I had mentioned back in the F2F 
as the most comprehensive reference on the same-origin policy. It does 
address all the security issues related to the same-origin policy in 
modern browsers. It is perhaps not as exciting as reading a tabloid, but 
it is worth a read! I think we should digest it first. I haven't tried 
to contact the author, but he might be the one to get in touch with if 
we have questions.

In any case, if we are to bang on the Web Security Context working 
group's door again (and I'm sure they would be happy to answer!), then 
we should bang with precise questions, and realize that the final piece 
of advice we'll receive will always be "don't do it", but that we would 
still need to balance the theoretical security point of view and 
concrete use cases in practice to take a final decision ('coz we're the 
happy best practices folks, you know).

What kind of precise question should we ask them?
What kind of information do we think we might still have missed, that 
would require more expert eyes?

Francois.



Jo Rabin wrote:
> 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 17:15:27 UTC