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: Fri, 17 Apr 2009 08:16:30 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B401DA0DC7@mtldsvr01.DotMobi.local>
To: "Charles McCathieNevile" <chaals@opera.com>, "Francois Daoust" <fd@w3.org>
Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
Comments below.

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Charles McCathieNevile
> Sent: 15 April 2009 23:59
> To: Francois Daoust
> Cc: Mobile Web Best Practices Working Group WG
> Subject: Re: ACTION-925: CT - same origin policy conformance
> 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...

Except that it is not in our charter to define security policies for browsers which is what we would be doing.

Plus of course HTML5 may very well change so it doesn't seem practical to me.

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

For every version of every browser? And what is the test?

I expect we can write some tests that show that for some set of domains, ports etc the proxy correctly separates the cookies that are forwarded, according to an arbitrary definition of correctness. We could also show that a proxy doesn't forward scripts to browsers. Perhaps we could show that a proxy executes scripts safely. The problem comes back to there being no normative definition of correctness or safety. And it's not clear to me that forwarding scripts is necessarily unsafe, though clearly there are cases where it is.

> 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 Friday, 17 April 2009 07:17:07 UTC

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