[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <lcamtuf at dione.cc> wrote:

> other browsers are getting cross-domain XMLHttpRequest headers
>

Using the W3C Access Controls spec, which I am suggesting to reuse here. If
you're not familiar with that spec, it's here:
http://www.w3.org/TR/access-control/

Now consider that "I-Do-Not-Want-To-Be-Loaded-Across-Domains" is also
> inherently incompatible with mashups, content separation, gadgets, etc, and
> there is a very vocal group of proponents and promotors for these
> technologies (which is why browser vendors are implementing cross-domain
> XMLHttpRequest to begin with). So we would probably rather want to say
> "I-Want-To-Be-Loaded-Only-By: <list_of_domains>".


I'm suggesting just reusing the Access Controls spec for that.

So for example, the server could say:
Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes
Access-Control-Allow-Origin: http://example.com

If we do that, then we are not far from the (IMO half-baked) site security
> policy concept. Some other person then adds several extra checks to prevent
> XSRF on top of this, and you have a system indistinguishable from SSP ;-).


I don't understand why you think that. SSP (now Content Security Policy; I
hope we're both talking about this
http://people.mozilla.org/~bsterne/content-security-policy/details.html ) is
about using HTTP headers to constrain the behaviour of pages you serve. You
can't use it to stop other random sites from loading resources from your
server.

Which is not to say much, just explaining why I made the leap. There would
> probably be a temptation to come up with a coherent and unified design,
> which may result in some bloat.


I have to admit I haven't fully thought through my suggestion here. But so
far I think by reusing Access Controls the "bloat" is minimal.


>  So what? The same goes for all your options --- slow browser migration
>> delays the uptake of any client-side solution.
>>
>
> Not really; minor versions usually have better uptake rates, thanks to
> auto-updates, etc (it's far from perfect, but it's nowhere near the
> estimated, if I recall published stats correctly, 20% of people still using
> MSIE6 after a year of MSIE7?) - not to mention, not having a change shelved
> until the next major version of a browser 2-4 years from now, means that
> even with poor uptake, it would be broadly available sooner.


There is no way in the world that Microsoft would implement your option 3 in
a security update to IE6.

Obviously I can't *prove* that but it's true. Microsoft is incredibly
conservative in their maintenance updates to Trident. Your option 3 would
definitely break the user experience in some sites, therefore they would not
do it. Furthermore the invasive changes to layout, rendering and event
handling would raise unacceptable risks of extra unintended regressions.
Furthermore it would be a ton of engineering effort; you're talking about
three different implementations (IE6-Trident, IE7-Trident,
IE8-whatever-the-new-engine-is-called) and two of them in basically dead
codebases.

Look at it this way ... get a written commitment from Microsoft to ship some
version of your option 3 in an IE6 update, and I promise to implement it in
Firefox myself :-).

Complex changes often get deferred, so any feature that is easy to smuggle
> in a minor version is probably better than a feature that needs to wait for
> MSIE 9, Firefox 4 (now, #3 is still considerably cheaper than a fully-blown
> SSP).
>

You don't need a fully-blown SSP.

However, even implementing all the features in
http://people.mozilla.org/~bsterne/content-security-policy/details.htmlseems
more palatable to me than implementing your option 3.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080928/b40cee17/attachment-0001.htm>