Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, Sep 29, 2008 at 12:17 AM, Michal Zalewski <[EMAIL PROTECTED]> wrote: > On Sun, 28 Sep 2008, Robert O'Callahan wrote: > > There is no way in the world that Microsoft would implement your option 3 >> in a security update to IE6. >> > > Sure, I'm not implying this. I simply have doubts about any other major > security changes making it into MSIE8 or Firefox 3. > As one of the people who makes these decisions, I can tell you that I'd be a lot more comfortable cramming option 1 into Firefox 3 or 3.1 than option 3. Apart from the other reasons I've already raised, option 1, being much simpler and with few degrees of freedom, would take a lot less time to analyze and converge on a spec. 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]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
MSIE7 is not offered as an update for Windows XP running on Pentium II. I dared not check whether it is possible to install it nevertheless. That might explain that 20%. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michal Zalewski Sent: Sunday, September 28, 2008 11:53 AM To: Robert O'Callahan Cc: whatwg@lists.whatwg.org; Smylers Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web On Sun, 28 Sep 2008, Robert O'Callahan wrote: 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.
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, 28 Sep 2008, Robert O'Callahan wrote: There is no way in the world that Microsoft would implement your option 3 in a security update to IE6. Sure, I'm not implying this. I simply have doubts about any other major security changes making it into MSIE8 or Firefox 3. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <[EMAIL PROTECTED]> 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: ". 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]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
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: ". 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
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, 28 Sep 2008, Michal Zalewski wrote: If you have faith that all these places can be patched up because we tell them so, and that these who want to would be able to do so consistently and reliably - look at the current history of XSRF and XSS vulnerabilities. ...and consequently, the worst-case scenario for breaking a page that did not need the protection to begin with is that the owner easily opts out, in a manner that is trivial to verify across his resources; on the other hand, the worst-case scenario for leaving one out of thousands resources on Facebook, MySpace, eBay, or my wife's cat fanciers' forum, accidentally not protected by an opt-in mechanism in some obscure code path... is more or less widespread misery that is extremely hard and sometimes expensive to clean up. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, 27 Sep 2008, Jim Jewett wrote: Yet opt-in proposals expect content authors to immediately add security checks everywhere, which is considerably less realistic than having a handful of webpages adjust their behavior, if we indeed break it (which I don't think would be likely with the design). It feels better, but I am inclined to think it is considerably less beneficial. Why? Most sites won't add the checks because they don't need them. Static pages do not (but would likely see no ill effects, too). Almost all web applications, where the user has a distinct authenticated context, do. Given that something like 90%+ of the list of top 100, 500, or whatever websites visited by typical users belongs to the latter category (well, looking at public stats at least), easily extrapolated to tens of millions of other less successful but still used resources (web forums, shops, chats, customer portals, etc), that all these are almost always significantly more complex that any static content (thousands of pages and hundreds of distinct features are not uncommon) - I indeed see a problem that is best addressed in an on-by-default mode. If you have faith that all these places can be patched up because we tell them so, and that these who want to would be able to do so consistently and reliably - look at the current history of XSRF and XSS vulnerabilities. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, 27 Sep 2008, Jim Jewett wrote: uhm... that is exactly when involuntary actions are *most* likely. It's not about merely clicking something accidentally - it's about clicking at a very specific place, as intended by the attacker, to trigger a very specific functionality on a targeted page. So I do not quite see how random "frustration" / wrong window focus clicks could apply (and it's a problem that no application is really designed to handle [1]). Many programs become unresponsive during launch and/or setup. I typically switch to another program (or another page), but the mouse events (and even keyboard keys) don't always go to the right place. That's odd, and I would be willing to say that this is a problem that needs to be addressed by your window manager or OS vendor. Window focus management and message queues should be independent of any particular application's responsiveness to messages sent to it. I honestly do not recall any situation where I would end up sending click events to the wrong application because the focus switch operation I just executed seemed to work, but in reality did not (if the application is not responsive, it would very likely not redraw itself, which means I would have nothing to click on). Cheers, /mz [1] Well, except for http://www.bitboost.com/pawsense/
