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

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

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 16 Apr 2009 00:59:13 +0200
To: "Francois Daoust" <fd@w3.org>
Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
Message-ID: <op.usf94zt8wxe0ny@widsith.local>
On Wed, 15 Apr 2009 11:41:33 +0200, Francois Daoust <fd@w3.org> wrote:

> Charles McCathieNevile wrote:
> [...]
>>> In short
>>> -----
>>> There are test suites. None of them pretends to be complete.
>>  So perhaps it behooves us to complete them to our satisfaction.
>
> I guess we would need more than just to complete them. We would need to  
> complete them, and then to adapt them so that they can successfully  
> check that a proxy that re-write links does not change the rules.

Not really. You write the tests, then you run a browser against them, or a  
browser+proxy, and see what happens. Even I can imagine a simple way to  
make a cross-site XHR test that passes if access to the resource is  
denied, but fails if you manage to make the request. It's not perfect  
since you are actually assuming the underlying network didn't cause the  
failure, but that's not a complex problem to get around for a reasonable  
degree of security.

>>> 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.
>>  I would be surprised if we *didn't* find convergence as a trend...
>
> Yes, I was looking for existing consistence here. Convergence should be  
> the trend, the problem being that the converging point is not fully  
> defined or testable yet, as the ongoing works on HTML5 and cross-origin  
> resource sharing demonstrate. Having guidelines on a moving target does  
> not seem to be such a good idea, and having guidelines based on existing  
> implementations that are not really consistent does not seem to be such  
> a good idea either. That may be too simplistic a view, though...

Yeah, I think so.

>>> 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.
>> This does not seem to make sense. Among other reasons, because it  
>> ignores the ability of a proxy that rewrites links to ensure it is  
>> getting all the content to handle the same-origin security policies at  
>> the proxy by not providing the resource.
>>
>>> 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.
>>  Which is effectively the same thing as a, no?
>
> This possibility would allow links rewriting but introduce something  
> along the lines of "proxies that re-write links MUST conform to the  
> same-origin policy defined in HTML5", with the drawback that we would  
> then probably need to wait for HTML5 to move forward on the Rec track.

Nothing stops us from taking that piece of HTML5, speccing it out, and  
publishing it. But that still introduces problems...

>>> 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...

>>  These both allow (as I read them) for the idea that it is possible to  
>> handle the security consideration, although insisting on a model that  
>> assumes there are no secure cross-site requests (which is not  
>> necessarily a valid assumption). I think they are further along the  
>> right track though.
>>  In particular, a transcoding proxy should respect the policy of the  
>> browser which is receiving its transcoded content (asking it to do less  
>> seems a bad idea, asking it to do more seems unreasonable, although  
>> asking it to check that policy is also an interesting prospect that  
>> might lead us bakc to having to do the serious work of figuring out how  
>> to handle same-origin policy and legitimate exceptions to it...)
>
> Yes, that sounds reasonable to me, and not actionable in practice at a  
> normative level, which is why I propose the possibilities mentioned  
> above.

To take the simple approach, the test passes if the results are the same  
when the browser used is run with and without a proxy. Otherwise it fails.

To take an approach that simplifies the lives of proxies, the test fails  
when something that the browser on its own didn't allow is allowed by the  
proxy service.

To take an approach like "specify same origin ourselves" the test fails  
under certain reference conditions where we decide that the test is  
checking a security breach. Although we could add some nuance to this, by  
implementing tests for CORS where the pass conditions are different,  
allowing for authorised access.

I don't see that this is terribly hard to develop tests for. In practice  
the issue is being able to run the browser both with and without the  
proxy, but that is an implementation question for proxies (as opposed to  
distributed browsers - you simply couldn't do this with the Mini client,  
but you can with the clientless version) that isn't monstrously horrible  
to resolve...

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Wednesday, 15 April 2009 23:00:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 April 2009 23:00:01 GMT