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

[Michal Zalewski]

On Sun, 28 Sep 2008, Robert O'Callahan wrote:

> I'm not sure what you're talking about here. I'm specifically NOT talking
> about Content-Restrictions or Site-Security-Policies or any other policies
> for controlling what a page may do once it has loaded.
>
> I'm expressing approval for your option 1, 
> "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes", preferably 
> generalized to "X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes" so 
> that it can be used for scripts and images too.

Well, OK, but that gets us on a slippery slope ;-) If it is just for 
IFRAMEs, then it does not reduce complexity - it increases it, because we 
already have way too many security-related headers (MSIE8 has 
"Content-Type-And-I-Really-Mean-It-So-Do-Not-Second-Guess", headers to 
control XSS filters, P3P policies, etc; other browsers are getting 
cross-domain XMLHttpRequest headers; there are some more examples to 
find), and we are adding a yet another header with a name and syntax that 
probably would not add up to a coherent picture, and costs quite a few 
bytes for high-traffic sites.

If we, on the other hand, do the "preferred generalization", as you note, 
then the next reasonable step would be to integrate all these security 
headers into a single, sane syntax that converses space, resources, and 
follows common rules.

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>". This still leaves some 
attacks (I might want my gadget to be embedded anywhere, just without 
being clobbered, which is something we averted our eyes from here), but 
let's say for a moment that it's good enough.

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

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. Or maybe not.

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

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

Cheers,
/mz