Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Ian Hickson wrote, On 18/02/2009 12.43: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and browser vendors seem reluctant to go down this road. Incidentally, NoScript's ClearClick is a working implementation of this difficult approach, effective also with same-origin plugin content (like in the original Clickjacking PoC by RSnake Grossman). http://noscript.net/faq#clearclick -- G Ian Hickson wrote, On 18/02/2009 12.43: On Thu, 25 Sep 2008, Michal Zalewski wrote: Problem definition: a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as delete all items, click to add Bob as a friend, etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications. Proposed fixes: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken - Can't be used for cases where IFRAME content mixing has a legitimate purpose (for example, cross-domain gadgets, certain types of mashups) In particular, this breaks Image Search tools from various vendors as well as navigation aids like the Reddit toolbar. - Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice - Along with the aforementioned security features, threatens to result in HTTP header or HTML HTTP-EQUIV size bloat that some sites may care about. This solution is what IE8 has apparently chosen to use. Specifically, IE8 will recognise an HTTP header or meta pragma directive with the name X-Frame-Options, and will process it as follows: If the value is a case-insensitive match for deny and the browsing context being navigated is not a top-level browsing context, replace the document with a UA-defined error message. If the value is a case-insensitive match for sameorigin and the browsing context being navigated is not a top-level browsing context and the origin of the top-level browsing context is not the same as the origin of the document in question, replace the document with a UA-defined error message. (The sameorigin rule seems like it should check all ancestor browsing contexts, not just the top-level one, because otherwise a site X, e.g. images.google.com, showing a frame with a document on site Y, e.g. hostile.example.com -- which might happen e.g. on something like Google Image Search -- would be able to embed another page from site X, e.g. your image search preferences, and do clickjacking on it.) This feature could also be extended to apply to other resources, e.g. scripts, images, style sheets, fonts, to prevent them from being used cross-origin. This would help, e.g., with securing scripts that contain private data. 2) Add a document-level mechanism to make if nested show this else show that conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. This is an interesting idea, though it would be subsumed by Hallvord's suggestion with Origin given below, in conjunction with idea 1 above in the absence of Origin information. 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Michal Zalewski wrote: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken Right. And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. There _is_ an issue here if script is disabled, of course. In that case, are there still situations where the parent frame can effectively mislead the user? 2) Add a document-level mechanism to make if nested show this else show that conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. Right, addressing the concern above. The pro is that it ties information directly to the document. The con is that it's harder to deploy site-wide Is that a concern? -Boris
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Boris Zbarsky wrote on 2/18/2009 9:27 AM: On Thu, 25 Sep 2008, Michal Zalewski wrote: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken Right. And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. Supposedly, a future release of IE8 will fix this (see Issue #4): http://ha.ckers.org/blog/20081007/clickjacking-details/ There _is_ an issue here if script is disabled, of course. In that case, are there still situations where the parent frame can effectively mislead the user? One solution I've seen is to position a giant div over the page so that nothing is clickable when JavaScript is disabled: scriptif (top != self) top.location = location/script noscriptdiv style=position:absolute;left:0;top:0;z-index:999;width:1px;height:1px;background-color:black;color:white;This page requires JavaScript/div/noscript Of course, that breaks the site for anyone surfing without JavaScript. - Bil
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Bil Corry wrote, On 18/02/2009 21.31: Boris Zbarsky wrote on 2/18/2009 9:27 AM: And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. Supposedly, a future release of IE8 will fix this (see Issue #4): http://ha.ckers.org/blog/20081007/clickjacking-details/ I doubt we'll see a fix for iframe security=restricted ;) -- G
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Hi Maciej, Does OS X (or the iPhone for that matter) support Java 6 yet? And were all these security bug reports you keep seeing to do with Java in general, or the Apple version in particular? Would Strict Same Origin policy not be useful as an optional (perhaps default) configuration? Cheers Richard Maher - Original Message - From: Maciej Stachowiak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org; Michal Zalewski [EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:22 PM Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote: Michal Zalewski wrote: I kinda assumed this suggestion was tongue-in-cheek, but if not - banning cross-domain IFRAMEs to fix one flaw, without providing viable methods for sandboxing untrusted same-origin content, would leave web developers with no tools to deal with quite a few classes of major security issues. It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. Java's security policy is also looser in some ways. For example, it allows the applet to connect to any port on the origin server. This has at times caused Java applets to be subject to vulnerabilities that did not affect plain HTML+JS+CSS (more recently than in the past 10 years). The general Web same-origin policy considers the port as well as the host to be part of the origin. More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. And finally, the key question for whether strict same-origin can work it not one of security but of functionality and usability. The trend in recent years has been for browsers to punch more controlled holes in the same-origin policy to fulfill the frequent desire of Web application developers to communicate with other servers from the client side. This is desirable so that AJAX apps (where most of the logic and functionality is client-side) can make use of third-party Web services APIs, in the same way that native apps can, without having to round-trip through their own server. I do not see this trend reversing any time soon. In conclusion I think limiting the Web to 100% strict same-origin would not be desirable even in an ideal world where compatibility issues are not a concern. I don't expect this to happen, however, because many large players are exploiting existing security design flaws in the web to do things they shouldn't be allowed to do in the first place, especially tracking users. Any scheme that limits the ability of advertisers and others to track users will be strenuously resisted. For the record, neither Apple nor the WebKit project have any strong commercial interest in the ability of advertisers or others to track users. Regards, Maciej
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Collin Jackson wrote: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or UI redress attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account. This flag could potentially use the cookie concept of same origin rather than the HTML5 concept of same origin: ignore port, ignore scheme unless secure flag is set, domain attribute can be used to relax domain comparison. Wouldn't such cookies still be sent if you trick the user into first clicking a link inside the frame, thus making it a same-site navigation, and then getting the user to click on the 'transfer money' link or whatever you are trying to trick the user to do? / Jonas
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, Oct 11, 2008 at 11:29 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Collin Jackson wrote: [snip] If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. [snip] Wouldn't such cookies still be sent if you trick the user into first clicking a link inside the frame, thus making it a same-site navigation, and then getting the user to click on the 'transfer money' link or whatever you are trying to trick the user to do? I think the idea is that when the click occurs inside the frame, one of the frame's ancestors is from another security origin and so the cookie would not be sent. Adam
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 10:33 PM, Michal Zalewski [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008, Robert O'Callahan wrote: If I understand correctly, with Michal's option 3, those sites would also stop working as soon as the user scrolled down in the framed page (so that the top-left of the framed page is out of view). Nope, the restriction applies strictly to the top-left corner of the *container* getting scrolled of the screen - not that of the content displayed within that container. In all the cases outlined by Ian, the IFRAMEs stay on screen, it's just that the content gets scrolled. I don't think that's secure. The outer page can set the IFRAME's URL to contain a #xyz fragment identifier, scrolling the 'xyz' element into view for any element with id 'xyz'; for many pages, this could allow the outer page great flexibility in scrolling the framed content to a desired position. That gives you the same visual effect as moving the top-left of the container off the screen (especially if you add scrolling=no to the IFRAME so scrollbars are suppressed), so it should be treated the same way. I suppose you could handle that by disabling input to the IFRAME while its URL has a fragment identifier. But that doesn't work because AJAXy pages like to store state in the fragment identifier. So you need to disable input to the IFRAME while its URL has a fragment identifier that was set by the outer page. Ugh. 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 Wed, 1 Oct 2008, Robert O'Callahan wrote: I don't think that's secure. The outer page can set the IFRAME's URL to contain a #xyz fragment identifier That's really covered in the original proposal. Honest :P In a kludgy manner, of course (permitting fragments, but not permitting onload scrolling based on fragments in cross-domain settings), but we thought of this one. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Kristof Zelechovski wrote: If you set up a mirror with the same host name as the content provider has, you will probably get sued for identity theft, cybersquatting, forgery or whatever. No, only the content provider (really the domain name owner) can set up these mirrors. This is nothing new. This is how the web and DNS work *today*. Many high volume sites such as www.google.com, www.amazon.com, www.nytimes.com, and so forth--send you to different physical boxes depending on where you're connecting from. These boxes are usually chosen to be close to the end user. For instance, a reader on the east Coast might get www.nytimes.com in New York but one on the West Coast might get a box in Los Angeles. A reader in Japan might get a box in Japan. (I don't know if this is actually how the NYT seets up its servers or not. Some tracerouting from different locations might find out quickly.) Large content providers already move their content closer to the end user. They do this by physically locating boxes with the same host name and fancy DNS and router tricks. The details are complex, which is why CCNAs get the big bucks. But they do not do this by linking to 3rd party content. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
I am afraid we are going in circles here. You suggested that the embedded content should be stored on the server that provides the interface. Now you explain how it can be stored on the media provider's server. That is nothing new - except that it has nothing to do with your original position. Chris -Original Message- From: Elliotte Harold [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 5:03 PM To: Kristof Zelechovski Cc: 'WHAT WG List' Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web Kristof Zelechovski wrote: If you set up a mirror with the same host name as the content provider has, you will probably get sued for identity theft, cybersquatting, forgery or whatever. No, only the content provider (really the domain name owner) can set up these mirrors. This is nothing new. This is how the web and DNS work *today*. Many high volume sites such as www.google.com, www.amazon.com, www.nytimes.com, and so forth--send you to different physical boxes depending on where you're connecting from. These boxes are usually chosen to be close to the end user. For instance, a reader on the east Coast might get www.nytimes.com in New York but one on the West Coast might get a box in Los Angeles. A reader in Japan might get a box in Japan. (I don't know if this is actually how the NYT seets up its servers or not. Some tracerouting from different locations might find out quickly.) Large content providers already move their content closer to the end user. They do this by physically locating boxes with the same host name and fancy DNS and router tricks. The details are complex, which is why CCNAs get the big bucks. But they do not do this by linking to 3rd party content. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 29, 2008, at 23:52, Adam Barth wrote: On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: I thought the issue with Referer was that it exposed path information, but I guess the problem with Origin is that it reveals the intranet server name? The query string and the path are probably the most privacy-sensitive. Yes, the concern is revealing the name of an intranet server. Most names are probably innocuous (like www, hr, or wiki), but there are others that might be an issue (like secretproject). It's hard for me to evaluate how concerning this privacy leak is. This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Elliotte Harold writes: Smylers wrote: That's a sometimes convenient feature for site developers, but there's nothing you can do with content loaded from two sites you can't do with content loaded from one. Here's some I can think of: * Many sites are funded by displaying adverts from a third-party service which picks appropriate ads for the current user-page combination. Serve ads from the host site. That's fine if the host site can do it. But often the point of subcontracting something to a third party is through lack of ability to do it oneself. A website on a particular topic may be financially viable by running third-party-provided ads; that requires merely a standard template in each page, a one-off cost which can be forgotten about. Whereas running ads themselves would take ongoing effort by the site (uploading them, making the pages link to them). That may reduce the time those running the site have available to work on the site's content. Or they may have to pay somebody else to set up the ads. Either of which could make the site no longer financially viable. Further, I don't see how users can be tracked across multiple sites. This is useful to serve users a variety of different ads, rather than the same one lots of times, even as they read multiple sites which all use the same third party ad service. That's a feature, not a bug. Or another way: users shouldn't be able to be tracked across sites. That they are is a bug, not a feature. If I'm going to see ads, I'd rather get different ads than repeatedly encounter the same ones. * Third party traffic analysis services, ranging from simple image hit-counters to something like Google Analytics, require being part of a page's loading. Not all such services do require this though. That's true. I don't have time to respond in detail to each of the valid points your raise. I may later. No, I understand your general point, and I'm sure for each of them I could come up with an alternative technical implementation. It's just that I think such alternatives require sites to make other changes -- changes to their business models, such as switching to a more advanced hosting package, or having to perform in-house tasks which were previously outsourced. And of course they break the business models of some of the outsources, whose products could no longer be used. If we break these things such that third party content is no longer the simplest solution that could possibly work, then developers and sites will move on to the next simplest solution. Or they won't bother, and sites that currently exist will give up. Addressing the root cause will cause pain because a lot of systems you mention will have to be rewritten to work in the new world. Indeed; that's my major concern here. HTML in general is a sub-optimal. XHTML 2 tried the approach of accepting transition pain in order to move to a saner place, but that doesn't seem to have gained traction. I'm simply not persuaded that those who would have to pay the cost of that pain will accept it. The first time a browser is released that implements this idea, many existing sites will fail. Users will blame the browser (we know that because Mozilla-based browsers got blamed for things it did correctly but differently from IE, such as alt text not being in a tooltip). At that point, all other browsers (and older releases of that browser) will still work. Why would users bother switching? And if users don't switch, why would sites bother updating themselves? Nor do I see that it is within the remit of HTML 5 to outlaw certain business models that were permitted under HTML 4. We're saying that such sites aren't welcome on the web? What if such sites are served with valid HTML 4; should they still have HTML 5's new rules applied to them? So be it. For any suggestion on this mailing list it's proponents could dismiss its costs with so be it. That doesn't in any way justify why those costs are worthwhile. You appear to be arguing here that the costs are worth it no matter how high they are. Simon
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Elliotte Harold writes: Large content providers already move their content closer to the end user. They do this by physically locating boxes with the same host name and fancy DNS and router tricks. Yup. But those are _large_ content providers. We shouldn't design HTML 5 such that smaller players are at a disadvantage (because they aren't big enough to warrant doing such things themselves, and they can't outsource things to a third party because we've blocked such services from working). Smylers
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 9:31 AM, Henri Sivonen [EMAIL PROTECTED] wrote: This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). Interesting idea. So you're suggesting something like: Origin-SHA1: 4e13de73de2d1a1c350eb4ae429bb7b009a21a84 This sounds like it would work well if the site owner knew exactly all the origins he was expecting, but it makes it difficult to enforce a policy like process this request if it came from a subdomain of example.com. Also, as a server operator, if I start getting a bunch of requests with a new origin hash, I'd have to guess whether this was an attack or another service on my network that I forgot about. (Traffic volumes might be a good clue about this.) Adam
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Adam Barth wrote: This could be addressed by sending a cryptographic hash of the origin (using an algorithm that is commonly available in libraries used by server-side programmers). Interesting idea. So you're suggesting something like: Origin-SHA1: 4e13de73de2d1a1c350eb4ae429bb7b009a21a84 This sounds like it would work well if the site owner knew exactly all the origins he was expecting, but it makes it difficult to enforce a policy like process this request if it came from a subdomain of example.com. More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site - hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site - hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. Salt it. Problem solved.
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: More importantly, since the dictionary of possible inputs is rather limited, it would be pretty trivial to build a dictionary of site - hash pairs and crack the values. May protect xyzzy2984.eur.int.example.com, but would still reveal to me you are coming from playboy.com. Salt it. Problem solved. Not really? I just need to rebuild my dictionary for that salt, but to check against say a million or ten million of common domains, it wouldn't be very expensive. And it's not very expensive to build such a list of domains, too. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: Not really? I just need to rebuild my dictionary for that salt, but to check against say a million or ten million of common domains, it wouldn't be very expensive. And it's not very expensive to build such a list of domains, too. In that case, you are certainly correct; adding a salt only hinders an attacker. But if we're worried about Origin giving away a secret intranet website, I think things should be reasonable. Of course, they can still dictionary brute-force it... (whoops, forgot to CC list)
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, 30 Sep 2008, Edward Z. Yang wrote: In that case, you are certainly correct; adding a salt only hinders an attacker. But if we're worried about Origin giving away a secret intranet website, I think things should be reasonable. Of course, they can still dictionary brute-force it... I guess the concern is primarily over home users, as they seem to be particularly fond of referrer-blocking plugins and so forth - and if Origin becomes nearly as often blocked over rational or irrational fears, it would become much less useful. Corporations with large intranets probably care less, and there might be better ways to help them if they do (from RFC1918 checks on browser end, to proxies or internal redirectors that remove internal addresses only). /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 30, 2008, at 7:57 AM, Elliotte Harold wrote: Maciej Stachowiak wrote: More generally, I am on Apple's internal incoming security bug list, and I see Java applet security bugs all the time, so I think whatever the strength of the model may be, it does not lead to Java applets being secure in practice. Are those bugs in the model or in the VM? Stack overflow issues, buggy code, and such are of a different character than fundamental design flaws. Simple bugs can be fixed much more easily. Many of the bugs I see are about what applet has access to what network or local resources, i.e. failures of the access control model. I do not have direct knowledge of how easy these are to fix compared to other Java applet bugs. - Maciej
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
2008/9/25 Toby A Inkster [EMAIL PROTECTED]: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. Something like focus-follows-mouse plus autoraise for IFRAMEs might work. Not likely. The entire point of an IFRAME is to blend in seamlessly with the rest of the parent site's content. I think it is just about impossible to come up with a UI that will violate this meshability of the IFRAME in a non-intrusive way AND signal clearly to Mr. Newbie User that this part of the page comes from another site than the rest and should be given a different level of trust. Plainly: I believe there are no acceptable UI solutions to this problem. What follows is my personal opinion which I've also explained on internal Opera mailing lists (I've seen some people agree but I want to make it clear that I'm not expressing any developer consensus or expressing Opera's point of view just yet). To give webmasters more ways to deal with this situation, I think we should implement the Access Control Origin HTTP-header only (assuming that it should refer to the top site in the frameset hierarchy). Reasoning: Sites may want to use any of several policies in a somebody framed me situation. For example, these are all policies a site may want to deploy: 1. nobody may frame my content 2. selected sites only may frame my content 3. anyone may frame my content but not re-use an existing session 4. anyone may frame my content Giving the site an Origin: http://www.example.com; HTTP header in the intial request lets the backend implement any of these policies. Instead of responding with a payload that always includes some variant of the proposed X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes header, the site can send or redirect to a framebreaking embedding forbidden page for policy #1. It can do so selectively based on origin site and/or requested content for policy #2. It can kill existing cookies, void session and set new origin-specific cookies for policy #3.) IMO the only UI precaution we can/should do if possible is to make transparent IFRAMEs transparent to events - basically un-focusable. -- Hallvord R. M. Steen
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, Sep 29, 2008 at 9:54 PM, Hallvord R M Steen [EMAIL PROTECTED]wrote: To give webmasters more ways to deal with this situation, I think we should implement the Access Control Origin HTTP-header only (assuming that it should refer to the top site in the frameset hierarchy). Reasoning: Sites may want to use any of several policies in a somebody framed me situation. For example, these are all policies a site may want to deploy: 1. nobody may frame my content 2. selected sites only may frame my content 3. anyone may frame my content but not re-use an existing session 4. anyone may frame my content Giving the site an Origin: http://www.example.com; HTTP header in the intial request lets the backend implement any of these policies. Instead of responding with a payload that always includes some variant of the proposed X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes header, the site can send or redirect to a framebreaking embedding forbidden page for policy #1. It can do so selectively based on origin site and/or requested content for policy #2. It can kill existing cookies, void session and set new origin-specific cookies for policy #3.) That's good to have and we should definitely do it, but there are a couple of reasons Same-Origin-Only-Unless-Access-Controls-Says-Otherwise would be useful as well: -- a bit simpler to implement on the server -- for privacy reasons some UAs in some situations might not want to expose the origin to the IFRAME's server; allowing the origin check to happen on the client would handle that IMO the only UI precaution we can/should do if possible is to make transparent IFRAMEs transparent to events - basically un-focusable. If you check for opacity:0, I can use opacity:0.01. At what level of opacity would the IFRAME become transparent to events? And it would leave a whole lot of other attacks wide open. So I don't think it's worth doing anything here. 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 Mon, 29 Sep 2008, Hallvord R M Steen wrote: To give webmasters more ways to deal with this situation, I think we should implement the Access Control Origin HTTP-header only (assuming that it should refer to the top site in the frameset hierarchy). I definitely like the Origin proposal the most of all the opt-in schemes, simply because it permits trusted domains to be whitelisted for many applications that rely on same-origin separation to implement security sandboxes. It still completely ignores the question of how we protect gadgets / mashups / whatever that are *designed* to be embedded on potentially untrusted sites, but depend on having the integrity of their UIs preserved, so I think we need - or well, should - tackle this aspect separately if this is the consensus for now. Note that the current implementation proposals for Origin headers (which I believe are limited to non-GET, non-HEAD requests) would not prevent this attack, nor some other potential attack vectors; they would probably need to be modified to include Origin header on SRC= GET requests on IFRAME / EMBED / OBJECT / APPLET. Extending the scheme to include SCRIPT would also cover script-inclusion attacks; extending it to all automated navigation (SRC=, REL=, scripted form submissions and location updates, etc) would prevent a broader set of XSRF and XSS attacks than the original proposal, but that's purely optional. But the bottom line is, there are some extra birds we could hit with that stone. Sites may want to use any of several policies in a somebody framed me situation. For example, these are all policies a site may want to deploy: 1. nobody may frame my content 2. selected sites only may frame my content 3. anyone may frame my content but not re-use an existing session 4. anyone may frame my content As noted, one important scenario which we do not account for is 5. anyone may iframe my content, but I want my UI not to get clobbered. This would realistically be the expectation for almost any privileged / authenticated gadget to be embedded on third-party pages. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008 13:41:59 +0200, Michal Zalewski [EMAIL PROTECTED] wrote: Note that the current implementation proposals for Origin headers (which I believe are limited to non-GET, non-HEAD requests) would not prevent this attack, nor some other potential attack vectors; they would probably need to be modified to include Origin header on SRC= GET requests on IFRAME / EMBED / OBJECT / APPLET. A cross-site XMLHttpRequest request would always include Origin. I haven't really seen other specifications start using it yet, but I believe there are some experimental implementations for including it in cross-site form POST requests. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008, Anne van Kesteren wrote: A cross-site XMLHttpRequest request would always include Origin. I haven't really seen other specifications start using it yet, but I believe there are some experimental implementations for including it in cross-site form POST requests. Yup, I mean the non-XMLHttpRequest Origin header as proposed / implemented by Adam Barth and Collin Jackson for generic POSTs (though I might be not doing the implementation justice, so it's probably best for them to chime in). /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
2008/9/29 Michal Zalewski [EMAIL PROTECTED]: I definitely like the Origin proposal the most of all the opt-in schemes, simply because it permits trusted domains to be whitelisted for many applications that rely on same-origin separation to implement security sandboxes. It still completely ignores the question of how we protect gadgets / mashups / whatever that are *designed* to be embedded on potentially untrusted sites, but depend on having the integrity of their UIs preserved After giving this quite some thought over the weekend, my conclusion is that this basically isn't doable - simply because it is a UI issue, UI is all about communicating to end users and the likelyhood of finding a solution that communicates the complexity of this in a way users will understand is practcally 0. The idea I liked most was a sort of automatically raise IFRAMEs to topmost z-index when focused combined with some way to temporarily flash the address - but IMO it's not doable because we'll mess up the UI of existing solutions in unexpected ways, and users don't understand URLs and have a quite fuzzy understanding of the basic different site concept. I know where you are coming from and hope a UI genius proves me wrong. :) -- Hallvord R. M. Steen
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008, Hallvord R M Steen wrote: It still completely ignores the question of how we protect gadgets / mashups / whatever that are *designed* to be embedded on potentially untrusted sites, but depend on having the integrity of their UIs preserved After giving this quite some thought over the weekend, my conclusion is that this basically isn't doable - simply because it is a UI issue, UI is all about communicating to end users and the likelyhood of finding a solution that communicates the complexity of this in a way users will understand is practcally 0. Well, so I agree. Yet, given the choice between: 1) Telling developers that they can't do any privileged gadgets safely at all, not theirs, and for reasons that are hard to explain to regular developers too - and pretending that the problem does not exist while people continue to depend on the unsafe logic (because whether we like it or not, seems that gadgets, mashups, and other methods of tightly integrating various applications and data sources on client side is here to stay), ...and... 2) Implementing a kludge that does not severely and inherently degrade user experience, whilst giving developers at least some security that they should have in the first place (most of the security problems they are dealing with these days can be tracked back to poor or uncoordinated security design decisions in the early days of the Web), I would be kinda willing to side with 2, which is why we came up with the kludgy proposal #3 to begin with. It's ugly, it's not perfect, it may require multiple workarounds to account for various scenarios, but it's the only way to tackle the UI problem we could think of. It also has a chance of working in a reasonably seamless manner if carefully reviewed and done right, although it might be a bumpy ride. Not presenting users with overly complex choices or failure scenarios is a noble goal, but realistically, it's not how web browsers work these days, and so when applied selectively, it might be not the strongest argument possible. As of now, understanding browser settings and error / warning / prompt messages requires a fair dose of expertise and experience, and it is extremely difficult to operate these applications without this knowledge. Some of the ongoing efforts improve this a bit (for example, browsers moving away from cryptic SSL security prompts to cryptic interstitials), other efforts take us a step back (for example, yellow security notification bars that are fully spoofable by web pages, and not properly anchored into browser chrome). The idea I liked most was a sort of automatically raise IFRAMEs to topmost z-index when focused combined with some way to temporarily flash the address - but IMO it's not doable because we'll mess up the UI of existing solutions in unexpected ways, and users don't understand URLs and have a quite fuzzy understanding of the basic different site concept. Yup. Plus, it leaves some open questions. Do we simply raise an IFRAME when clicked? If yes, the harm might be already done. Do we require Eolas-patent-style click-to-activate? If yes, we might seriously annoy operators of some IFRAME-based advertisement systems. Do we raise the frame just on mouseover? This would result in confusing flickering and page layout changes, would mess up drop-down menus expanded over different-origin document windows, etc. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
The current proposal is to sent the Origin header for non-GET, non-HEAD requests. The main reason not to send the header all the time is that it raises similar privacy concerns as the Referer header, which have caused the Referer header to be suppressed a non-trivial fraction of the time. Sending the Origin header more often is better for security, but it is a gamble. If we decide to send it too often, users/network operators will just suppress the header and we won't have improved the situation. Sending the header for form POSTs seems like a clean design point because sites don't POST to untrusted sites nearly as often as they hyperlink to them. Adam On Mon, Sep 29, 2008 at 5:20 AM, Michal Zalewski [EMAIL PROTECTED] wrote: On Mon, 29 Sep 2008, Anne van Kesteren wrote: A cross-site XMLHttpRequest request would always include Origin. I haven't really seen other specifications start using it yet, but I believe there are some experimental implementations for including it in cross-site form POST requests. Yup, I mean the non-XMLHttpRequest Origin header as proposed / implemented by Adam Barth and Collin Jackson for generic POSTs (though I might be not doing the implementation justice, so it's probably best for them to chime in). /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, 29 Sep 2008 16:06:09 -0400, Adam Barth [EMAIL PROTECTED] wrote: The current proposal is to sent the Origin header for non-GET, non-HEAD requests. The main reason not to send the header all the time is that it raises similar privacy concerns as the Referer header, which have caused the Referer header to be suppressed a non-trivial fraction of the time. Sending the Origin header more often is better for security, but it is a gamble. If we decide to send it too often, users/network operators will just suppress the header and we won't have improved the situation. Sending the header for form POSTs seems like a clean design point because sites don't POST to untrusted sites nearly as often as they hyperlink to them. Hmm, we went through this before I believe. I thought the issue with Referer was that it exposed path information, but I guess the problem with Origin is that it reveals the intranet server name? On the other hand, for the not-link following case how common is it for intranet applications to load images and resources cross-site? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Hmm, we went through this before I believe. Yeah, we talked about this in the context of CSRF. I thought the issue with Referer was that it exposed path information, but I guess the problem with Origin is that it reveals the intranet server name? The query string and the path are probably the most privacy-sensitive. Yes, the concern is revealing the name of an intranet server. Most names are probably innocuous (like www, hr, or wiki), but there are others that might be an issue (like secretproject). It's hard for me to evaluate how concerning this privacy leak is. On the other hand, for the not-link following case how common is it for intranet applications to load images and resources cross-site? I don't have numbers to back this up, but my guess is that hyperlinks are far-and-away the most predominant. For CSRF, it doesn't make sense to send the Origin header for some kind of GET requests but not for others (the attacker will just use the method that doesn't send the header). For UI redress / clickjacking, the attacker can make the request using hyperlinks also. For example: 1) http://attacker.com/ embeds a frame to http://attacker.com/ready 2) http://attacker.com/ready has a hyperlink to http://victim.com/ that gets clicked by JavaScript (say via the click() method). Keep in mind, that the attacker can often launder the IFRAME request through a respected third-party. For example, the image search features offered by Live.com, Google, and Yahoo all happily create IFRAMES to a URL of the attacker's choice. Adam
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Incidentally, these issues are why Collin's proposal at the start of this thread was to list send the origin of all the ancestor frames: On Thu, Sep 25, 2008 at 12:57 PM, Collin Jackson [EMAIL PROTECTED] wrote: make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. This header could be a list of all the origins that are ancestors of the frame that triggered the request. If the site decides it does not like the ancestor frame origin it could reject the request. This could be added as a property of MessageEvent as well to detect client-side UI redress attacks. This proposal blocks the attack after the user clicks the bad button (instead of when the bad site tries to load the good site in a frame). The proposal works in the cases below because the attacker's frame is one of the ancestor frames when the clickjack click occurs. (The proposal is the visual analog of stack inspection in other systems.) Adam On Mon, Sep 29, 2008 at 1:52 PM, Adam Barth [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Hmm, we went through this before I believe. Yeah, we talked about this in the context of CSRF. I thought the issue with Referer was that it exposed path information, but I guess the problem with Origin is that it reveals the intranet server name? The query string and the path are probably the most privacy-sensitive. Yes, the concern is revealing the name of an intranet server. Most names are probably innocuous (like www, hr, or wiki), but there are others that might be an issue (like secretproject). It's hard for me to evaluate how concerning this privacy leak is. On the other hand, for the not-link following case how common is it for intranet applications to load images and resources cross-site? I don't have numbers to back this up, but my guess is that hyperlinks are far-and-away the most predominant. For CSRF, it doesn't make sense to send the Origin header for some kind of GET requests but not for others (the attacker will just use the method that doesn't send the header). For UI redress / clickjacking, the attacker can make the request using hyperlinks also. For example: 1) http://attacker.com/ embeds a frame to http://attacker.com/ready 2) http://attacker.com/ready has a hyperlink to http://victim.com/ that gets clicked by JavaScript (say via the click() method). Keep in mind, that the attacker can often launder the IFRAME request through a respected third-party. For example, the image search features offered by Live.com, Google, and Yahoo all happily create IFRAMES to a URL of the attacker's choice. Adam
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 2:44 AM, Michal Zalewski [EMAIL PROTECTED] wrote: Well, so I agree. Yet, given the choice between: 1) Telling developers that they can't do any privileged gadgets safely at all, not theirs, and for reasons that are hard to explain to regular developers too - and pretending that the problem does not exist while people continue to depend on the unsafe logic (because whether we like it or not, seems that gadgets, mashups, and other methods of tightly integrating various applications and data sources on client side is here to stay), We can easily offer these developers the following options: a) developers of privileged gadgets can whitelist domains that they trust to not subvert the UI b) privileged gadgets can be offered to the world as long as the IFRAME's own UI is not trusted. For example, gadgets whose purpose is to offer a postMessage API to untrusted container pages would be just fine. c) spawn new windows/tabs to perform or confirm privileged operations d) mix of strategies ... for example, gadgets could offer privileged UI to trusted container pages, but for untrusted containers, attempts to use the privileged UI would spawn a separate window/tab to perform the operation We might also be able to help by extending the browser UI, for example by supporting extra panes like the old Netscape sidebar UI (but better). But to explore that further, I'd want to better understand the use cases that are not served by a) b) c) or d) above. I honestly think that, compared to an extremely complex, mysterious and ever-changing set of UI threat mitigation strategies, which will inevitably diverge across browsers and across browser versions and will constantly interfere with the user experience, the above approach will be actually end up more attractive to developers. 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 Tue, Sep 30, 2008 at 9:06 AM, Adam Barth [EMAIL PROTECTED] wrote: The current proposal is to sent the Origin header for non-GET, non-HEAD requests. The main reason not to send the header all the time is that it raises similar privacy concerns as the Referer header, which have caused the Referer header to be suppressed a non-trivial fraction of the time. This is why it would be helpful to also support a don't load me across origins header sent by the server. 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 Tue, 30 Sep 2008, Robert O'Callahan wrote: We can easily offer these developers the following options: a) developers of privileged gadgets can whitelist domains that they trust to not subvert the UI How is this achieved? If I have a chat (talk to site owner using your $foo chat account) or calendar overlay (see scheduled events overlaid on your calendar) gadget that is to be embedded freely by third-parties, and offers a privileged UI - even if I require sites to pre-register or otherwise build a whitelist of these untrusted domains, I have no assurance they would play nice. b) privileged gadgets can be offered to the world as long as the IFRAME's own UI is not trusted. For example, gadgets whose purpose is to offer a postMessage API to untrusted container pages would be just fine. Sure, but then it makes the model drastically different, and suitable for different uses (many privileged gadgets may specifically not want to disclose any presented information to the top level page). c) spawn new windows/tabs to perform or confirm privileged operations That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 11:14 AM, Michal Zalewski [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008, Robert O'Callahan wrote: We can easily offer these developers the following options: a) developers of privileged gadgets can whitelist domains that they trust to not subvert the UI How is this achieved? If I have a chat (talk to site owner using your $foo chat account) If the chat gadget is configured to only talk to the site owner, how can it be abused? I suppose the site owner can discover the chat nick of a visitor who otherwise wouldn't want to disclose it. That's a risk that the chat system developers might very well be willing to accept. or calendar overlay (see scheduled events overlaid on your calendar) gadget that is to be embedded freely by third-parties, If it's read-only, again, what's the risk? The user might want to interact with the IFRAME to scroll and search, but even if those are spoofed, there's no way for the container to abuse this, as far as I can tell. I understand there are more interesting examples, but these ones don't seem to make your case. c) spawn new windows/tabs to perform or confirm privileged operations That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Maybe we can make it a better user experience, for example, by allowing the new window/tab to appear as a new pane at the top or bottom of the existing tab. That would nicely handle your chat example, IMHO. 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 Tue, 30 Sep 2008, Robert O'Callahan wrote: If the chat gadget is configured to only talk to the site owner, how can it be abused? I suppose the site owner can discover the chat nick of a visitor who otherwise wouldn't want to disclose it. That's a risk that the chat system developers might very well be willing to accept. Assume you are logged in with Facebook, Google, or any other common party that provides general chat / calendar services or anything of that kind; and let's say this party permits site operators embed a gadget that shows every visitor a schedule of events advertised on a page overlaid on top of visitor's schedule (with the option to add these to your calendar, or edit your calendar data - it does not have to be read-only); or gives you the opportunity to chat, review and annotate documents, or otherwise collaborate with site owners using similar facilities provided by gadget operator in their third-party domain, in your capacity as the user logged in with said services. [If the visitor is not logged in, such a gadget would not display, or would offer a login link that pops up a new https:// window.] This is not a very far-fetched scenario - I've seen designs of this type - and they are very much possible and safe to arrange without disclosing any user-specific information to the page that embeds said gadgets. The only security problem arises with UI redress flaws; so it would be nice to offer viable alternatives for such applications, too. That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Maybe we can make it a better user experience, for example, by allowing the new window/tab to appear as a new pane at the top or bottom of the existing tab. That would nicely handle your chat example, IMHO. Possibly. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Tue, Sep 30, 2008 at 12:09 PM, Michal Zalewski [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008, Robert O'Callahan wrote: If the chat gadget is configured to only talk to the site owner, how can it be abused? I suppose the site owner can discover the chat nick of a visitor who otherwise wouldn't want to disclose it. That's a risk that the chat system developers might very well be willing to accept. Assume you are logged in with Facebook, Google, or any other common party that provides general chat / calendar services or anything of that kind; and let's say this party permits site operators embed a gadget that shows every visitor a schedule of events advertised on a page overlaid on top of visitor's schedule (with the option to add these to your calendar, or edit your calendar data - it does not have to be read-only); I don't see what's so terrible about showing the user's calendar and the overlaid events inline, and having the Add to Calendar button open a new page for confirmation. Note that GMail's add to Google Calendar functionality already takes me to a new tab for confirmation, even though presumably Google could avoid that if they wanted to. or gives you the opportunity to chat, review and annotate documents, or otherwise collaborate with site owners using similar facilities provided by gadget operator in their third-party domain, in your capacity as the user logged in with said services. If these services are limited to specific chat channels or documents that are associated with the site owner (which can be ensured by the gadget operator), then I don't see a problem; site owner UI redress would be pointless. That's a terrible user experience, by most accounts, and goes against the concept of a gadget; I believe it is often avoided at all costs except when absolutely necessary (e.g., login, where the user needs the opportunity to verify URL, SSL status, etc). Maybe we can make it a better user experience, for example, by allowing the new window/tab to appear as a new pane at the top or bottom of the existing tab. That would nicely handle your chat example, IMHO. Possibly. Think it over :-) 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 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/
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 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 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
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: 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]
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
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 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
Elliotte Harold writes: People want to get pictures, text, and other media from the web. People want to play games and use some apps. Users don't care where the media is loaded from. If it can be loaded form a single server, then the users' needs are met. I see no genuine user use cases that require multisite access within a single page. Well it depends what you mean by genuine. I can think of several scenarios where it currently has to be done that way, but any of them could be dismissed as not genuine if you're prepared to impose additional (technical, financial, business model, development, networking) restrictions on folk running websites That's a sometimes convenient feature for site developers, but there's nothing you can do with content loaded from two sites you can't do with content loaded from one. Here's some I can think of: * Many sites are funded by displaying adverts from a third-party service which picks appropriate ads for the current user-page combination. To work on a single host would require all potential adverts' content to be supplied to the website before they can be used -- thereby forcing the website authors into regular maintenance of adding to the pool of ads, denying them the opportunity to leave their website alone and let the income accrue from the third-party ads. And that the third party be happy to provide the software for picking which ad to use in a request, which is probably proprietary -- and also gives them the burden of supporting authors using the software and issuing updates to the software. And that the author's site is running on a server which allows the third party software to run; it can no longer be a purely static website. Further, I don't see how users can be tracked across multiple sites. This is useful to serve users a variety of different ads, rather than the same one lots of times, even as they read multiple sites which all use the same third party ad service. * Some sites allow users to add comments to pages, with limited HTML allowed in the comments. The permitted HTML can include img tags, linked to images served elsewhere. In the case of comments being provided in an HTML form it would of course be possible to develop the software to include the capabililty for uploading files with a comment, and only allow img tags to link to such content. But that involves the website software (which may have been written years ago, by a third party no longer involved in the site) being changed. And it's conceivable (though I admit, unlikely) that comments could be provided by other means, such as text messages, yet still contain HTML links to images -- in which case it's unclear how the user could upload the image. * If a popular campaign issues a video, encouraging fans to include it on their websites, they currently just need to paste the supplied HTML into their site. Having to download and re-upload the video adds to the effort needed to show their support. * Further, if successful there'll be thousands of different copies of this video on the net. This hampers ISPs' (and even browsers') abilities to cache it, in the way that they could if everybody was linking to a single instance of it. * Sometimes such campaigns include countdowns or release schedules to a particular event (10 days to go until ...). If the iframe or image or whatever is hosted by those running the event then they can update it accordingly, and it will be correct on all the supporting sites kindly linking to it. But if the 'fans' have to download each change and re-apply it to their own sites, many will likely get out of date. Or, similarly, an image linking to a specific book on a bookseller's website -- which the bookseller ensures always contains the current price. * Third party traffic analysis services, ranging from simple image hit- counters to something like Google Analytics, require being part of a page's loading. Of course, hit counters are trivial to code, but require dynamic hosting accounts. And the third parties performing the advanced analysis are unlikely to provide their server-side code. Even if they did, I guess both it and the embedded JavaScript undergo frequent revisions, which currently authors can ignore. * The copyright owners of some media may be happy for others to embed it, but not to copy it and host it elsewhere. For example, because they want to make it available for only a limited period, or so they can count how many hits are served. So it would be illegal for an author to copy it and serve it directly. * Some HTML mail contains links to images hosted on the sender's website. This isn't really third-party content, but by the time I'm reading the message, it's a local file: URL so all images are external. Web-based mail readers would suffer similarly on such messages. Images can be embedded
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Kristof Zelechovski wrote: In order to store guest media: 1. The mirror host would need a broadcasting licence. 2. The mirror host would have to support the encoder (if it supports dynamic resolution adjustment). 3. If it is Flash, the player might refuse to play if loaded from a different URL than expected. I don't mean mirrors with different host names. I mean mirrors with the same hostnames, exacltly as is done today for high volume web sites. www.yahoo.com is not just one box after all. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
If you set up a mirror with the same host name as the content provider has, you will probably get sued for identity theft, cybersquatting, forgery or whatever. Chris -Original Message- From: Elliotte Harold [mailto:[EMAIL PROTECTED] Sent: Saturday, September 27, 2008 3:22 PM To: Kristof Zelechovski Cc: 'WHAT WG List' Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web Kristof Zelechovski wrote: In order to store guest media: 1. The mirror host would need a broadcasting licence. 2. The mirror host would have to support the encoder (if it supports dynamic resolution adjustment). 3. If it is Flash, the player might refuse to play if loaded from a different URL than expected. I don't mean mirrors with different host names. I mean mirrors with the same hostnames, exacltly as is done today for high volume web sites. www.yahoo.com is not just one box after all. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sun, Sep 28, 2008 at 12:41 AM, Michal Zalewski [EMAIL PROTECTED] wrote: On Sat, 27 Sep 2008, Robert O'Callahan wrote: Default permission of cross-domain loads is responsible for *a lot* of problems. Allowing sites to escape that would address a lot of problems, even if it is opt-in. Eventually we could hope to reach a state where all browsers support it, and most sites request it --- a much saner Web IMHO. Yup, by all means, it solves a lot of other problems - and devising a *comprehensive* solution (not a new specialty HTTP header to deal with IFRAMEs and OBJECT/EMBED/APPLETs specifically), even if opt-in, has the benefit of actually reducing complexity for web app developers (in terms of custom XSRF / script inclusion checks, etc, that they could ditch). Glad you think so. The issue is, a considerable implementation effort is involved in most of these comprehensive designs (given how current same-origin checks, and code taking cross-domain actions with no same-origin checks, is typically scattered), lots of open questions (e.g., there are some important performance trade-offs depending on the granularity of resources, the types of requests we want to run checks on; site-wide policies and per-URL policies; etc). On top of that, there seem to be several incompatible proposals from various groups, with vendors seemingly not willing to back off. Microsoft is pursuing their proposal for cross-domain policies in MSIE8, Mozilla devs had another (and every other security researcher has probably their own and better design in the drawer, about to bring it out the moment they are asked for advice). 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. On top of that, I'd add the W3C Access Controls spec for finer-grained control --- a spec that all the major vendors have signed on to. (So I'm really suggesting X-Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes.) I think this would be much easier to implement than your option 3. Option 3 requires hooking into layout, rendering, and event handling, and doing constant ongoing checks and state changes where we currently don't have any security checks. Furthermore there's an ongoing maintenance burden as every new layout and rendering feature has to be security-analyzed to see if it need to participate in the option 3 algorithm, and hooked up if so. OTOH option 1 requires only checks at load time, where we're already doing a lot of checks. But feel free to ask other implementors what they think. Bottom line is, I would be very surprised if such a functionality would be in a state that can be relied upon by web applications in the next 5-8 years (more if the abysmally slow MSIE6 - MSIE7 migration is bound to repeat with next major versions)... and I am not entirely comfortable with UI redress attacks being around for so long; I suppose most browser vendors are not happy too, given the recent / likely upcoming press attention. So what? The same goes for all your options --- slow browser migration delays the uptake of any client-side solution. In fact, a solution that servers opt in to is likely to see *faster* client uptake because vendors and users will see a lower risk of Web applications breaking. The real concern about an opt-in solution is Web apps taking a long time to use it. But it seems to me that most sites could just add the option 1 header for all pages on the site and the site would Just Work. 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 Thu, 25 Sep 2008, Maciej Stachowiak wrote: I meant, corner of the container, rather than actual document rendered within. Then can't you work around the restriction by scrolling the contents inside the iframe and sizing it carefully? (One way to scroll an iframe to a desired position is to load a URL containing an anchor link This was addressed in the original proposal (anchors and within-IFRAME focus() calls). There should be no other useful ways to scroll different-domain IFRAMEs, I'm hoping (window.scroll* methods are mercifully restricted in such a case in most browsers). For example, iGoogle widgets would become disabled if scrolled partially off the top of the page under your proposal. And even if scrolled back into view, would remain disabled for a second. With possibly a jarring visual effect, or alternately, no visual indication that they are disabled. Hard to decide which is worse. As per the other thread, this is easily preventable (and a clause for UI action optimizations is already in the original proposal). I don't see this as a sufficient argument to dismiss the proposal, quite frankly - it does not indicate a fatal flaw, but rather a minor issue that is rather easily worked around. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008 22:17:00 +0200, Collin Jackson [EMAIL PROTECTED] wrote: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or UI redress attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account. This flag could potentially use the cookie concept of same origin rather than the HTML5 concept of same origin: ignore port, ignore scheme unless secure flag is set, domain attribute can be used to relax domain comparison. Pros: - Only need to change one line of code where the login cookie is set, entire site is protected Cons: - Opt-in (sites remain vulnerable unless action is taken) - Would need to test this to make sure it doesn't break legacy browser cookie handling (Adam and I got this idea from someone else, but we don't remember who it was.) Probably somewhere on the public-webapps or public-webapi list in context of cross-domain XMLHttpRequest. Anyway, this wouldn't work for login based on HTTP authentication or based on IP address or something. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Prohibiting third-party embedded content would disable media embedded in blogs. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliotte Harold Sent: Friday, September 26, 2008 5:21 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web 6) Admit that iframes and 3rd party embedded content are broken by design. Eliminate the iframe element completely, and set browsers to *never* load content or communicate with any site except the primary URL of the page. No 3rd party cookies, no 3rd party images, no 3rd party frames, no 3rd party scripts, no 3rd party nothing. Everything on the page comes from the same host. No exceptions. Simple. Secure. Easy to understand. Easy to implement.
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Kristof Zelechovski wrote: Prohibiting third-party embedded content would disable media embedded in blogs. Absolutely false. The media simply needs to be served from the same host the blog itself is. This is how almost all the media in my blogs works today. What little content comes from a 3rd party site in my blogs (mostly from laziness) could easily be moved to the sites that serve the blogs. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, 26 Sep 2008, Maciej Stachowiak wrote: Maybe I didn't read very well, but I don't see how the clause for UI action optimizations would prevent what I described. Could you spell it out for me please? It seems to me that the embedded iframes for iGoogle gadgets (or similar) will indeed be disabled when scrolled partly off the top of the page (or maybe dead to UI events only when you bring the mouse near them, which amounts to the same thing). What I meant is that we can conceivably inhibit disabling IFRAMEs if they end up off the screen as a result of non-scripted user-initiated scrolling - a change that does not require the design to be scraped. I was simply referring to the fact that similar optimizations were already present in the design, so it is not a very far-fetched idea to extend it to incorporate this. We did not, because it seemed to be a non-issue. All this assuming that the inability to interact with a cross-domain gadget whose top part is off the screen is an usability problem by itself, to a degree that invalidates any security benefit for such a scheme. Many of the earlier security improvements within browsers did rule out far more pronounced usage scenarios, retrospectively breaking other people's applications. Examples include file:/// scripting restrictions, Internet - file:/// access restrictions, document.cookie restrictions on non-HTTP schemes, CANVAS readback once non-same-origin images are rendered, third-party cookie restrictions, etc. Not all of these solutions were perfect, but they do provide some context. I am also not sure what you mean by the other thread. Err, sorry - the other branch of this one. P.S. I cited this example because it is a Google property, but I am sure there are many others like it. We can't expect content authors to immediately fix them all. 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. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Ozob the Great wrote: The bandwidth cost of hosting video makes this option unworkable for some blogs. And yet someone's hosting that bandwidth today. This need not involve any net increase in bandwidth. It would just involve a rejiggering of hosting models. -- Elliotte Rusty Harold [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
If a user in America watches a media stream hosted in America but embedded on a blog page hosted in Europe, the media stream would have to cross the ocean twice. This is not a trifle. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliotte Rusty Harold Sent: Friday, September 26, 2008 11:10 PM Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web Ozob the Great wrote: The bandwidth cost of hosting video makes this option unworkable for some blogs. And yet someone's hosting that bandwidth today. This need not involve any net increase in bandwidth. It would just involve a rejiggering of hosting models. -- Elliotte Rusty Harold [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: I kinda assumed this suggestion was tongue-in-cheek, but if not - banning cross-domain IFRAMEs to fix one flaw, without providing viable methods for sandboxing untrusted same-origin content, would leave web developers with no tools to deal with quite a few classes of major security issues. It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. I don't expect this to happen, however, because many large players are exploiting existing security design flaws in the web to do things they shouldn't be allowed to do in the first place, especially tracking users. Any scheme that limits the ability of advertisers and others to track users will be strenuously resisted. -- Elliotte Rusty Harold [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, Sep 27, 2008 at 9:19 AM, Elliotte Rusty Harold [EMAIL PROTECTED] wrote: I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. You also see that Java is almost never used in the public Web. Java doesn't prove anything. 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 Fri, 26 Sep 2008, Elliotte Rusty Harold wrote: It's tongue-in-cheek that I don't expect it to be adopted or seriously considered (this year). It's not tongue-in-cheek in that I very much wish it were adopted. That is, I think it's in the realm of the desirable, not the possible. Oh yup, agreed there; with current DOM manipulation capabilities, and with the hopefully upcoming flexible, site-controlled security policies, IFRAMEs could probably safely go away in a decade or so for most intents and purposes. I am curious what issues you see with same origin content. They certainly exist, but I tend to feel those are orthogonal to the issues at hand, and subject for a separate discussion. Yup, these are best addressed by introducing better security controls wrt content sniffing, sandboxing, etc, rather than keeping IFRAMEs around. It's just that killing IFRAMEs before these improvements are introduced would probably do some harm. The general problem is, let's assume my application wants to show you a third-party gadget, a document of an unknown format sent to you in an e-mail, or a raw HTML page that cannot be scrubbed down, or that we do not believe we can scrub well enough (this is a very difficult task by itself, given browser-specific HTML parsing quirks). Further assume that I want to do it within some other, trusted UI, to offer a more intuitive and streamlined user experience, instead of creating new minimal, non-interactive tabs. The only way to do it right now without risking the content gaining control of the UI is to keep it in a separate, untrusted sandbox domain, and use IFRAMEs to embed the data within the UI. Quite a few web apps adopted this approach for better or worse to implement useful functionality. Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Robert O'Callahan wrote: On Sat, Sep 27, 2008 at 9:19 AM, Elliotte Rusty Harold [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I do think we have an existence proof that security in this realm is possible. That's Java. Modulo some outright bugs in VMs (since repaired) the default Java applet security model has worked and worked well since 1.0 beta 1. (1.0 alpha 1 wasn't quite strict enough.) I have seen no security design flaws exposed in Java applets in over ten years. That's why I suspect duplicating Java's security policy in HTML is a safe way forward. I'm skeptical that anything less will suffice. You also see that Java is almost never used in the public Web. Java doesn't prove anything. \ As I said, it's an existence proof. Sun's inability to provide decent developer tools (unlike Adobe) doesn't reflect on the capability of the model. -- Elliotte Rusty Harold [EMAIL PROTECTED]
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sat, Sep 27, 2008 at 11:55 AM, Elliotte Rusty Harold [EMAIL PROTECTED] wrote: As I said, it's an existence proof. Sun's inability to provide decent developer tools (unlike Adobe) doesn't reflect on the capability of the model. That has nothing to do with it. You're saying Java's security model is adequate for what people want to do on the Web. I say that is unproven since people are not using Java on the Web. *Why* they are not using Java on the Web is irrelevant. In fact, people are doing a lot of things on the Web, using cross-origin IFRAMEs, that are not possible with the Java model. Or maybe you're not saying that. Maybe you're just saying the Java model is secure and not claiming it meets people's needs. In that case, you may be right, but that's not very interesting --- it's easy to come up with safe, simple security models that don't provide the functionality people want. 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
Robert O'Callahan wrote: You're saying Java's security model is adequate for what people want to do on the Web. I say that is unproven since people are not using Java on the Web. *Why* they are not using Java on the Web is irrelevant. Java's security model is absolutely adequate for what people want to do on the Web. Given sufficient time and resources you could write a fully featured web browser that ran as an applet. (Not much point but it could be done.) The one fundamental problem you'd hit would be the inability to load content from a host other than the server the applet came from. If we allow different windows for different pages, there's nothing an applet can't do. (They're a few things it wouldn't do very efficiently, but that;s another story.) People want to get pictures, text, and other media from the web. People want to play games and use some apps. Users don't care where the media is loaded from. If it can be loaded form a single server, then the users' needs are met. I see no genuine user use cases that require multisite access within a single page. That's a sometimes convenient feature for site developers, but there's nothing you can do with content loaded from two sites you can't do with content loaded from one. There might be ways to give clients more control over what they load and see so that the *client* can choose to load and merge content from several different hosts, but that's exactly what's being avoided here. Web standards and even more so web software has consistently favored the needs of the server over the needs of the client. That's why we still have way too many sites trying to control how their users consume and view content. I challenge anyone to demonstrate a single multisite web page that cannot be reproduced as a single-site page. Do not confuse details of implementation with necessity. Just because we sometimes put images, ads, video, tracking scripts, and such on different sites doesn't mean we have to. The web would be far more secure if we locked this down, and simply made multisite pages impossible. -- Elliotte Rusty Harold [EMAIL PROTECTED] Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Michal Zalewski wrote: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. Something like focus-follows-mouse plus autoraise for IFRAMEs might work. -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED] wrote: Other quick fixes are easy to come up with, but in general prove problematic in many usage scenarios. Based on our internal conversations, we have a number of proposals for approaches to how to address the issue, along with their pros and cons outlined. All these could be tweaked, combined, etc.; none of them seems quite ideal. Here are two ideas to add to the mix: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or UI redress attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account. This flag could potentially use the cookie concept of same origin rather than the HTML5 concept of same origin: ignore port, ignore scheme unless secure flag is set, domain attribute can be used to relax domain comparison. Pros: - Only need to change one line of code where the login cookie is set, entire site is protected Cons: - Opt-in (sites remain vulnerable unless action is taken) - Would need to test this to make sure it doesn't break legacy browser cookie handling (Adam and I got this idea from someone else, but we don't remember who it was.) 7) New HTTP request header: Browser vendors seem to be moving away from same origin restrictions towards verifiable origin labels that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's origin property [1], postMessage's targetOrigin argument [2], and the HTTP Origin header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes HTTP response header, make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. This header could be a list of all the origins that are ancestors of the frame that triggered the request. If the site decides it does not like the ancestor frame origin it could reject the request. This could be added as a property of MessageEvent as well to detect client-side-only UI redress attacks. Pros: - Doesn't break existing sites - Easy to check using firewall rules Cons: - Opt-in (sites remain vulnerable unless action is taken) - Minor increase in HTTP request size (but only for iframe-heavy sites) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#messageevent [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#postmessage0 [3] http://www.w3.org/TR/access-control/#origin0 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=446344 [5] https://bugs.webkit.org/show_bug.cgi?id=20792
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Collin Jackson wrote: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. Good point; the concern with this, as with most of the other schemes except for #3, is that it breaks some legitimate cross-domain uses such as gadgets and mashups (we can either permit anyone to partly or fully display a gadget, or deny everyone; we would ideally want to restrict partial rendering only). Just as importantly, some sites are moving to different-domain content hosting domains specifically to work around countless bugs, oddities, and design flaws in modern browsers (starting with MSIE text/plain / image/* behavior and utf-7 sniffing, through Content-Disposition bypass issues, to the complete inability to safely serve certain types of non-sanitized resources in sensitive domains). Customizable policy frameworks may help with this in the long run, but for now, it's a necessity. Any solution that puts blanket cross-domain restrictions on IFRAME nesting would need to be completely disabled in such scenarios. This is why I and several people like #3 best, despite its relative complexity - because it does not require you to fully expose your content to third-party domains. 7) New HTTP request header: Browser vendors seem to be moving away from same origin restrictions towards verifiable origin labels that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's origin property [1], postMessage's targetOrigin argument [2], and the HTTP Origin header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes HTTP response header, make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. Oh yup, I wanted to capture this possibility in #5; it's a noble long-term goal, but with the conflicting proposals from Microsoft, Mozilla developers, and several other parties, and the high complexity of getting these mechanisms right - I am not sure it's a viable solution for the next few years. Maybe in 5-10, it would be a reality. /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, Sep 25, 2008 at 1:46 PM, Michal Zalewski [EMAIL PROTECTED] wrote: 7) New HTTP request header: Browser vendors seem to be moving away from same origin restrictions towards verifiable origin labels that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's origin property [1], postMessage's targetOrigin argument [2], and the HTTP Origin header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes HTTP response header, make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. Oh yup, I wanted to capture this possibility in #5; it's a noble long-term goal, but with the conflicting proposals from Microsoft, Mozilla developers, and several other parties, and the high complexity of getting these mechanisms right - I am not sure it's a viable solution for the next few years. Maybe in 5-10, it would be a reality. I would actually expect #7 would be the easiest to standardize of all the proposals. The three examples (origin, targetOrigin, and Origin) have all been adopted by every major browser vendor (including Microsoft) within the past year. Collin
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 25, 2008, at 10:24 AM, Michal Zalewski wrote: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. [ I like this one the most myself, but we were far from reaching any consensus. ] Algorithm description: A) Permit frames to be nested arbitrarily by default. B) If anything is to be drawn partly or fully on top of a region occupied by a nested IFRAME (in a callback from the renderer), look up the parent of the obstructing visual element drawn (that is, the party in charge of element's positioning). Always allow the element to be drawn, but if the parent is not same-origin with the target of an obstructed IFRAME, set a flag to disable UI input to that obstructed IFRAME (i.e., have the browser sink all UI events from now on). We may also gray out the disabled IFRAME (and maybe allow CSS to customize this behavior for specific IFRAMES). C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison. Isn't this likely to come up any time you have a scrollable iframe, or one with overflow: hidden? And why top left but not bottom right? D) Once the obstruction is removed (say, a menu folded back), initiate a security timer (500-1000 ms or so) to eventually re-enable UI input to the IFRAME. E) Cases where a non-same-origin IFRAME is newly spawned by Javascript, or same-origin - non-same-origin location updates takes place, should be treated as special cases of the IFRAME being uncloaked, and result in UI event lockout until a security timer expires. F) Regardless of the aforementioned mechanism, do not permit an IFRAME target that is not same-origin with its parent document to invoke .focus() or to reposition content using URL anchors. This is to make sure that the top-left corner of the page as seen by the user always displays the top-left corner of the actual page. A potential optimization for D) and E), to minimize any potential impact where attacks are unlikely to succeed, is to: - Permit a short window of opportunity (0.5 second, perhaps) following initial page load, as well as possibly mouse clicks, during which cross-domain IFRAMEs may be revealed with no timer penalty, based on the assumption that immediate and involuntary UI actions are unlikely to follow. ...or alternatively: - Disable UI events or initiate timeouts only if cursor is within a certain radius of the uncloaked non-same-origin frame, based on the same assumption. Pros: - Works by default Cons: - Moderately complex and kludgy - In implementations, would require callbacks from the renderer to detect obstruction, as opposed to making decisions without this knowledge - Further investigation is needed to verify that this doesn't break the legitimate and common practice of some sites I would add: - Seems complicated to implement correctly. - Seems very difficult to validate correctness of the security policy. - Likely to break user experience of some existing sites. I do not think this one is viable. Regards, Maciej
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 25, 2008, at 1:17 PM, Collin Jackson wrote: On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED] wrote: Other quick fixes are easy to come up with, but in general prove problematic in many usage scenarios. Based on our internal conversations, we have a number of proposals for approaches to how to address the issue, along with their pros and cons outlined. All these could be tweaked, combined, etc.; none of them seems quite ideal. Here are two ideas to add to the mix: 6) New cookie attribute: The httpOnly cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and UI redress attacks. If a cookie is set with a sameOrigin flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or UI redress attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account. This flag could potentially use the cookie concept of same origin rather than the HTML5 concept of same origin: ignore port, ignore scheme unless secure flag is set, domain attribute can be used to relax domain comparison. Pros: - Only need to change one line of code where the login cookie is set, entire site is protected Cons: - Opt-in (sites remain vulnerable unless action is taken) - Would need to test this to make sure it doesn't break legacy browser cookie handling (Adam and I got this idea from someone else, but we don't remember who it was.) 7) New HTTP request header: Browser vendors seem to be moving away from same origin restrictions towards verifiable origin labels that let the site decide whether two security origins trust each other. Recent examples of this are MessageEvent's origin property [1], postMessage's targetOrigin argument [2], and the HTTP Origin header [3] [4] [5]. We can adjust proposal (1) to conform to this philosophy: instead of making it an X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes HTTP response header, make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP request header. This header could be a list of all the origins that are ancestors of the frame that triggered the request. If the site decides it does not like the ancestor frame origin it could reject the request. This could be added as a property of MessageEvent as well to detect client-side-only UI redress attacks. Pros: - Doesn't break existing sites - Easy to check using firewall rules Cons: - Opt-in (sites remain vulnerable unless action is taken) - Minor increase in HTTP request size (but only for iframe-heavy sites) Another variant of this or Michal's #1 is an HTML-level concept (such as a meta keyword). Or if it remains an HTTP header, it should be allowed for meta http-equiv (which in HTML5 allows only a small subset of http headers). In general, your 6 and 7 sound much more practical than Michal's #3 and less likely to have unexpected bad effects on existing sites. Regards, Maciej [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#messageevent [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#postmessage0 [3] http://www.w3.org/TR/access-control/#origin0 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=446344 [5] https://bugs.webkit.org/show_bug.cgi?id=20792
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Maciej Stachowiak wrote: C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison. Isn't this likely to come up any time you have a scrollable iframe, or one with overflow: hidden? And why top left but not bottom right? I meant, corner of the container, rather than actual document rendered within. If deals strictly with the frame beginning outside the current viewport to hide some of its contents, but leave small portions of the UI exposed to misdirected clicks. Doing the same check for bottom right is very much possible, although does not seem to thwart any particularly plausible attacks. - Seems complicated to implement correctly. It is relatively complex, as acknowledged. The whole reason for this complexity is that we hoped to devise a solution that: a) Works by default, without the need to implement specific server-side mechanisms (all things aside, placing the burden on server side is counterintuitive and likely to make these problems persist forever, even more so than XSS and XSRF), b) Does not break any plausible usage scenarios we could think of (with a particular attention to IFRAMEd non-same-origin document views, ads, gadgets). I would love to see better solutions along these lines to arise on this forum; failing this, we may resort to a solution that requires sites to opt in en masse for a particular mechanism, or to give up defenses to permit certain types of applications to be built - but I see this as suboptimal. - Seems very difficult to validate correctness of the security policy. This one I'm not sure I follow; very few browser security mechanisms are provable, and even the ones that are, usually do not get proven. It is relatively easy to intuitively break down and analyze the attack surface here, however. - Likely to break user experience of some existing sites. Any particular examples? Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, Sep 26, 2008 at 7:33 AM, Toby A Inkster [EMAIL PROTECTED]wrote: Something like focus-follows-mouse plus autoraise for IFRAMEs might work. I actually like this idea quite a lot. It would have to allow the IFRAME to escape clipping (and other graphical effects) as well (except for viewport clipping), but that's doable. You'd probably still need a timer so that the element has to be raised for a certain amount of time before input is allowed. 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
Other than sliding content over the top of the IFRAME, there are fun ways to get exactly the appearance the attacker wants ... keep in mind when designing a solution: -- make the IFRAME opacity:0 (or 0.01) and draw whatever you want underneath it -- use SVG filter effects (in conjunction with SVG foreignObject, or CSS extensions to apply filters to non-SVG content) to simply replace the rendering of the IFRAME with something else. 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 Fri, Sep 26, 2008 at 10:23 AM, Michal Zalewski [EMAIL PROTECTED] wrote: I meant, corner of the container, rather than actual document rendered within. If deals strictly with the frame beginning outside the current viewport to hide some of its contents, but leave small portions of the UI exposed to misdirected clicks. Doing the same check for bottom right is very much possible, although does not seem to thwart any particularly plausible attacks. Seems like this will create a really bad user experience. The user scrolling around in the outer document will make IFRAMEs in it mysteriously become enabled or disabled. Jesse Ruderman suggested this in 2002, more or less, and I didn't like then, and I don't like it any more now. Anyway, this option 3) will require extension to deal with opacity:0 and SVG filter attacks. That's probably not hard to do, but it's a warning sign that it might not be very robust as the Web evolves. It also needs to treat size changes to the IFRAME as decloaking requiring a UI input lockout. In fact, pretty much any change that makes a lot more of the iframe be exposed needs to be detected, including stuff like sudden CSS transform rescaling... Ugh. 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 Fri, 26 Sep 2008, Robert O'Callahan wrote: Seems like this will create a really bad user experience. The user scrolling around in the outer document will make IFRAMEs in it mysteriously become enabled or disabled. Well, to put this in perspective - we are talking about cross-domain IFRAMEs only, and only a short security timeout; we could also quite conceivably make an exception for cases where a frame is scrolled into view as a result of the user interacting with the scroll bar, as opposed to page scripts (some optimizations of this type are already mentioned in the proposal). That said, yeah, there are some trade-offs and gotchas. I do not think that bad user experience is inherent to the design, but that does not change the fact that it's a kludge. I am not touting option #3, or any option on that list for that matter, as a perfect solution; in fact, they all suck for one reason or the other. I'm hoping we can come up with something workable, though. As noted, my greatest concern is having us pick an easy way out that essentially delegates all responsibility for compensating for an arguably broken design to web applications (as is the case with most of the opt-in solutions) - web developers already face a remarkable burden here, and tend to fail way too often - or devising a fix that cripples some less obvious but common uses (such as gadgets / mashups, or IFRAMEd advertisements). [ Not very related, but one such example of problem shifting was the fix that some browser vendors implemented to improve privacy, by refusing third-party cookies. It helped with the particular problem, and seemed insanely elegant - but also caused massive problems with certain types of gadgets, certain authentication schemes, and a handful security mechanisms that relied on different-origin separation to safely host untrusted content, lacking other options. ] Cheers, /mz
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Fri, Sep 26, 2008 at 12:27 PM, Michal Zalewski [EMAIL PROTECTED] wrote: On Fri, 26 Sep 2008, Robert O'Callahan wrote: Seems like this will create a really bad user experience. The user scrolling around in the outer document will make IFRAMEs in it mysteriously become enabled or disabled. Well, to put this in perspective - we are talking about cross-domain IFRAMEs only, and only a short security timeout; The timeout only applies after the obstruction is removed, right? Until then everything is disabled. So as long as the top-left corner of the IFRAME's viewport is not visible, e.g. because it's scrolled out of view in the top-level document, the IFRAME must remain disabled. we could also quite conceivably make an exception for cases where a frame is scrolled into view as a result of the user interacting with the scroll bar, as opposed to page scripts (some optimizations of this type are already mentioned in the proposal). Sure, but each such extension add complexity for implementors, authors and users. Making the disabling happen less often in this way makes it all the more mysterious when it does happen. As noted, my greatest concern is having us pick an easy way out that essentially delegates all responsibility for compensating for an arguably broken design to web applications (as is the case with most of the opt-in solutions) - web developers already face a remarkable burden here, and tend to fail way too often - or devising a fix that cripples some less obvious but common uses (such as gadgets / mashups, or IFRAMEd advertisements). Indeed. IMHO the basic problem here is allowing IFRAMEs to be cross-origin by default. That causes many problems, some of which you know well, and others you probably don't (e.g. http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html ). In fact, in an ideal world, I think we'd default to same-origin restrictions on everything --- IFRAMEs, images, scripts, etc --- and use a spec like Access Controls to let sites opt-in to allowing their resources to be loaded from specific other origins. In the real world, we can't do that, but I kinda like option 1 because it (sort of) lets sites opt into that ideal world. (And I'm pushing for all new kinds of resource loads, such as fonts and external SVG resource documents, to use that approach.) 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 Thu, Sep 25, 2008 at 4:08 PM, Ian Hickson [EMAIL PROTECTED] wrote: form of experimental implementations. Personally I think the idea of disabling the contents of a cross-origin iframe that has been partially obscured or rendered partially off-screen is the best idea, but whether we can adopt it depends somewhat on whether browser vendors are willing to adopt it and implement it. It requires no standards changes to implement. If further restrictions are added to iframes there should be a way to opt out of them, particularly anything that disables the iframes and any kind of timeouts. I have a legitimate application where iframes are regularly being created dynamically, resized, hidden, re-displayed, moved slightly off screen, and where there may be multiple iframes overlapping each other at any given moment. My application is a user interface library where the iframes can be opened in resizable panels and in resizable, draggable, and hide-able(minimized) DHTML windows. The following is a web applications example. There is also a demo for a web desktop. The web desktop is probably where my users would run into the most issues, since the windows often have cross-domain iframe widgets and gadgets in them, which again, can be resized, moved slightly offscreen, hidden, and moved so that they overlap. http://mochaui.com/demo/ Also, two or three months back I had asked for a way to disable iframes manually. We came to the conclusion that Internet Explorer's setCapture and releaseCapture methods would solve the issue I had. I don't know if that functionality might also increase some of the options to the problem trying to be solved here. - Greg
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote: On Thu, 25 Sep 2008, Maciej Stachowiak wrote: C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison. Isn't this likely to come up any time you have a scrollable iframe, or one with overflow: hidden? And why top left but not bottom right? I meant, corner of the container, rather than actual document rendered within. Then can't you work around the restriction by scrolling the contents inside the iframe and sizing it carefully? (One way to scroll an iframe to a desired position is to load a URL containing an anchor link If deals strictly with the frame beginning outside the current viewport to hide some of its contents, but leave small portions of the UI exposed to misdirected clicks. Doing the same check for bottom right is very much possible, although does not seem to thwart any particularly plausible attacks. - Seems complicated to implement correctly. It is relatively complex, as acknowledged. The whole reason for this complexity is that we hoped to devise a solution that: a) Works by default, without the need to implement specific server- side mechanisms (all things aside, placing the burden on server side is counterintuitive and likely to make these problems persist forever, even more so than XSS and XSRF), b) Does not break any plausible usage scenarios we could think of (with a particular attention to IFRAMEd non-same-origin document views, ads, gadgets). I think these are laudable goals, but I think you have failed to achieve (b). I would love to see better solutions along these lines to arise on this forum; failing this, we may resort to a solution that requires sites to opt in en masse for a particular mechanism, or to give up defenses to permit certain types of applications to be built - but I see this as suboptimal. - Seems very difficult to validate correctness of the security policy. This one I'm not sure I follow; very few browser security mechanisms are provable, and even the ones that are, usually do not get proven. It is relatively easy to intuitively break down and analyze the attack surface here, however. I don't mean validate in the sense of a formal proof, I mean just in the sense of an informal but convincing argument. There are many ways to partially obscure or alter the contents of an iframe. Your original proposal missed the cases of altering opacity, scrolling the contents of the iframe, using filters to alter the frame's appearance, and probably more that we aren't thinking of. How about using a CSS transform to significantly alter the appearance? Or maybe there are pages where showing just the upper left to the user can be effective as an attack? In other words, adopting this proposal would mean signing up for a game of security whack-a-mole. - Likely to break user experience of some existing sites. Any particular examples? For example, iGoogle widgets would become disabled if scrolled partially off the top of the page under your proposal. And even if scrolled back into view, would remain disabled for a second. With possibly a jarring visual effect, or alternately, no visual indication that they are disabled. Hard to decide which is worse. Regards, Maciej
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Sep 25, 2008, at 8:07 PM, Maciej Stachowiak wrote: On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote: On Thu, 25 Sep 2008, Maciej Stachowiak wrote: C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison. Isn't this likely to come up any time you have a scrollable iframe, or one with overflow: hidden? And why top left but not bottom right? I meant, corner of the container, rather than actual document rendered within. Then can't you work around the restriction by scrolling the contents inside the iframe and sizing it carefully? (One way to scroll an iframe to a desired position is to load a URL containing an anchor link Sorry, got cut off here. One way to scroll is to load a URL including a fragment identifier pointing to an element inside the target document. - Maciej
