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: if (window != window.top) window.top.location.href = window.location.href; in effect, right? This last already works in all browsers except IE, which is presumably

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

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:

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 w

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

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 visu

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

figuration? Cheers Richard Maher - Original Message - From: "Maciej Stachowiak" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: ; "Michal Zalewski" <[EMAIL PROTECTED]> Sent: Tuesday, September 30, 2008 12:22 PM Subject: Re: [whatwg] Dealing with UI red

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

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 "same

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

not speaking for HP here... Elliotte Harold wrote: > I don't have time to respond in detail to each of the valid points > your raise. I may later. However each of them can be handled in a > different way that doesn't require third party content and mashups. > The reason we have designed these sy

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

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 g

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 corre

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 co

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 pla

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: 4e13de73de2d1a1c350eb4

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

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

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 fund

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 stri

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

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

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

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

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

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

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

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 scr

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

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

On Tue, Sep 30, 2008 at 11:16 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Tue, 30 Sep 2008, Robert O'Callahan wrote: > > > > > > I don't think this would really work for Google. Many widgets (e.g. > > > the mapping widget) are expected to be placed on any site, but how > > > could the widget p

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

On Sep 29, 2008, at 9:42 PM, Ian Hickson wrote: On Mon, 29 Sep 2008, Maciej Stachowiak wrote: On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: I'm suggesting just reusing the Access Controls spec for that. So for example, the server could say: Same-Origin-Only-Unless-Access-Controls-Sa

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

On Tue, 30 Sep 2008, Robert O'Callahan wrote: > > > > I don't think this would really work for Google. Many widgets (e.g. > > the mapping widget) are expected to be placed on any site, but how > > could the widget provider know who is evil and who isn't? What about > > if an otherwise not evil s

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

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

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

On Tue, Sep 30, 2008 at 5:42 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 29 Sep 2008, Maciej Stachowiak wrote: > > On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: > > > > > > I'm suggesting just reusing the Access Controls spec for that. > > > > > > So for example, the server could

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

On Mon, 29 Sep 2008, Maciej Stachowiak wrote: > On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: > > > > 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-C

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

On Sep 28, 2008, at 2:15 PM, Robert O'Callahan wrote: 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'

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

On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote: 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

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

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

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 ve

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

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

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

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 developer

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

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 i

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

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

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 thoug

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 comp

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 POST requests. Yup, I mean t

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 p

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

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

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

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

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

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

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

On Sun, 28 Sep 2008, Robert O'Callahan wrote: There is no way in the world that Microsoft would implement your option 3 in a security update to IE6. Sure, I'm not implying this. I simply have doubts about any other major security changes making it into MSIE8 or Firefox 3. Cheers, /mz

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

On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote: > other browsers are getting cross-domain XMLHttpRequest headers > Using the W3C Access Controls spec, which I am suggesting to reuse here. If you're not familiar with that spec, it's here: http://www.w3.org/TR/access-co

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, "

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 w

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

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

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-

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

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

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 th

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

On Sat, 27 Sep 2008, Anne van Kesteren wrote: Could you list these comprehensive designs perhaps? I mean, proposals to make it possible for sites to opt in for explicitly controlling various cross-domain interactions now permitted by default (which includes including scripts, making POST req

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

On Sat, 27 Sep 2008 13:41:06 +0200, 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. E

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

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

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

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elliotte Harold Sent: Saturday, September 27, 2008 7:46 AM To: WHAT WG List Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web Kristof Zelechovski wrote: > If a user in Amer

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

On Sat, Sep 27, 2008 at 9:43 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote: > Your whack-a-mole analogy is of course true, but it applies so much more to > many ongoing browser security efforts, most notably including implementing > robust cross-domain DOM access security checks; hardly a simple a

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

On Sat, 27 Sep 2008, Smylers wrote: 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 withi

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 c

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

Michal Zalewski writes: > On Fri, 26 Sep 2008, Maciej Stachowiak wrote: > > > 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 th

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

Kristof Zelechovski wrote: 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. No, it wouldn't. Assuming the blog is viewed many more times than it's written, th

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 pe

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 se

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] > 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 def

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, a

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 s

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 maj

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

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 som

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

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

On Fri, Sep 26, 2008 at 11:31 AM, Elliotte Harold <[EMAIL PROTECTED]>wrote: > 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. Thi

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

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

On Sep 26, 2008, at 3:22 AM, Michal Zalewski wrote: 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?

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

On Fri, 26 Sep 2008, Elliotte Harold wrote: 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

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 3

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

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

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 pa

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

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 t

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 be

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 rect

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

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 d

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 IFRAME

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

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 effects (in conjunction with SVG , or CS

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 vie

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 o

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 pro

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 menu

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

On Thu, 25 Sep 2008, Michal Zalewski wrote: > > I am posting here on the advice of Ian Hickson; I'm new to the list, so > please forgive me if any of this brings up long-dismissed concepts; > hopefully not. Thanks for the e-mail. > Problem definition: a malicious page in domain A may create a

  1   2   >