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:13:48 UTC