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

[Giorgio Maone]

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

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

[Bil Corry]

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:
> 
>   
> 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 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  over the page so that 
nothing is clickable when JavaScript is disabled:

if (top != self) top.location = location
This
 page requires JavaScript

Of course, that breaks the site for anyone surfing without JavaScript.



- Bil

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

[Boris Zbarsky]

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:

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

[Giorgio Maone]

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  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  else
   " 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 brow

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

[Ian Hickson]

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  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  else
>" 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 browser vendors seem 
reluctant to go down this road.


> 4) Enforce a click-to-work mechanism (resembling the Eolas patent
>workaround) for all cross-domain IFRAMEs.

Experience with the Eolas patent workaround suggests this wouldn't be 
popular, to put in mildly.


> 5) Rework everything we know about HTML / browser security models to
>make it possible for domains and pages to specify very specific opt-in
>/ opt-out policies for all types of linking, referencing, such that
>countering UI redress attacks would be just one of the cases controlled
>by this mechanism.

This seems like it would still basically need one of the other mechanisms 
as well. Without a more concrete proposal here it's hard to tell what 
exactly this would be.

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

[Richard's Hotmail]

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: ; "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

[Adam Barth]

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

[Jonas Sicking]

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

[Bonner, Matt]

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 systems this way is because it was
> quick and easy, not because it was the only way to do these tasks. 

That seems overly simplified.  Allowing links across sites creates
networks. I can link to a graph of the TED spread [1], to a real-time 
picture of the traffic on a nearby freeway and to a calendar gadget 
from three different sites because those sites are authorities for 
those topics.

Of course there's your way around all that: making local copies. But 
that brings obvious costs in network and disk usage. Also, the same-
host restriction raises the barrier to the average user making a web 
page.  And quite obviously, many companies would take umbrage if page
authors copied their contents. There are doubtless other problems w/
the same-host approach, but these are a few big ones I see.

Matt

[1] http://en.wikipedia.org/wiki/TED_spread


smime.p7s
Description: S/MIME cryptographic signature

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

[Maciej Stachowiak]

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

[Michal Zalewski]

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

[Edward Z. Yang]

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

[Michal Zalewski]

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

[Edward Z. Yang]

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

[Michal Zalewski]

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

[Adam Barth]

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

[Smylers]

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

[Smylers]

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

[Henri Sivonen]

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

[Kristof Zelechovski]

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

[Elliotte Harold]

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

[Elliotte Harold]

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.


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

[Elliotte Harold]

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.


  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.



* 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. Google Analytics 
implementation decisions are not the only ones possible.


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 systems this way is because it was quick and easy, 
not because it was the only way to do these tasks. 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.


The bottom line is that bad implementation decisions made years ago with 
respect to third party content are causing security issues now. We can't 
paper over these problems. Anything less than addressing the root cause 
will fail.


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. So be it. 
Nothing else will work, and the sooner we recognize that, the sooner 
everything will be fixed.


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

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

[Robert O'Callahan]

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

[Robert O'Callahan]

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 provider know who is evil and who isn't? What about
> > > if an otherwise not evil site is compromised? (This happens regularly,
> > > especially with, e.g., sites with forum software or blog software.) We
> > > don't want a vulnerability in a widget host site to immediately allow
> > > this kind of attack on all the widgets that that site hosts.
> >
> > Choose your friends carefully.
>
> I'm not sure how that helps here. Are you saying widget providers
> shouldn't do business with site owners who use popular blogging tools?
>

I'm saying that widget providers shouldn't let privileged UI be framed by
sites they don't trust to do their job right.

Maybe that sounds harsh. But of course it's less harsh than the reality of
the situation we find ourselves in today.

> But really, why does this mapping widget need to expose UI that can be
> > abused to do evil things with my Google account?
>
> In the case of the mapping widget it doesn't, but consider a chat widget,
> that enables users to chat with the site owner. If this widget had a
> button that sent a message, a hostile site could perform a DDOS attack on
> the site owner by embedding the widget host itself in an iframe, and
> aligning everything such that all the users tricked into going to that
> page and logged in to the chat widget would cause the victim site owner to
> get messaged, potentially resulting in thousands of such messages.


In this example, the site owner is at fault because they should have ensured
that their widget-hosting page was not frameable by the hostile site. So it
doesn't show a weakness in the model.

So far in this discussion, we have a shortage of examples where a gadget has
to be widely embeddable, and it has to have UI that triggers privileged
operations, and those operations have to enable harmful consequences to
agents other than the embeddor, and opening a new window or tab to confirm
those operations is unreasonable. These are the examples that demand
elaborate "option 3" measures. Since the claim is that these examples are
common, I'd like to know more about them.


> > > Secondly, consider Google Image Search, or Reddit with its "open link
> > > with reddit toolbar" option, or any other site that allows arbitrary
> > > Web navigation in a frame or iframe while hosting some sort of toolbar
> > > content from its own page in another frame or container page. This
> > > option would mean that many sites would stop working with these
> > > containers, despite these containers not doing anything evil (there's
> > > no overlapping content, the user is fully aware of what's going on,
> > > etc).
> >
> > 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).
>
> Any solution that breaks those sites is a non-starter IMHO.
>

Apparently "option 3" doesn't break them, although I have some questions
about that.

But it seems strange to say that breaking such sites is a "non-starter".
Suppose a major browser added support for universal Origin headers and
Access Controls and some kind of "Requires-Access-Controls" server header.
If I run a site and I care about security and I don't care about being
framed in Google Image Search or these other framing sites (assuming they
don't drive much traffic to my site, or at least the parts of my site I want
to protect) --- why shouldn't I welcome these measures and deploy them?

Are you saying it would be irresponsible of browser vendors to support such
features, because it would allow selfish behaviour of some sites to disrupt
services provided by third parties?

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

[Maciej Stachowiak]

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-Says-Otherwise: yes
Access-Control-Allow-Origin: http://example.com


I think this is a really good proposal. It would allow Web sites to
place all content under a single uniform policy for access control,  
as

opposed to the state today where cross-site access depends on how the
resource is embedded.


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 site is compromised? (This happens regularly, especially  
with,

e.g., sites with forum software or blog software.) We don't want a
vulnerability in a widget host site to immediately allow this kind of
attack on all the widgets that that site hosts.

Secondly, consider Google Image Search, or Reddit with its "open  
link with

reddit toolbar" option, or any other site that allows arbitrary Web
navigation in a frame or iframe while hosting some sort of toolbar  
content
from its own page in another frame or container page. This option  
would

mean that many sites would stop working with these containers, despite
these containers not doing anything evil (there's no overlapping  
content,

the user is fully aware of what's going on, etc).


I did not think of that. But I don't think there has been a solution  
proposed yet that wouldn't break some content under some  
circumstances. This proposal at least has the advantage of not  
involving the layout code in security policy.


Regards,
Maciej

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

[Ian Hickson]

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 site is compromised? (This happens regularly, 
> > especially with, e.g., sites with forum software or blog software.) We 
> > don't want a vulnerability in a widget host site to immediately allow 
> > this kind of attack on all the widgets that that site hosts.
> 
> Choose your friends carefully.

I'm not sure how that helps here. Are you saying widget providers 
shouldn't do business with site owners who use popular blogging tools?


> But really, why does this mapping widget need to expose UI that can be 
> abused to do evil things with my Google account?

In the case of the mapping widget it doesn't, but consider a chat widget, 
that enables users to chat with the site owner. If this widget had a 
button that sent a message, a hostile site could perform a DDOS attack on 
the site owner by embedding the widget host itself in an iframe, and 
aligning everything such that all the users tricked into going to that 
page and logged in to the chat widget would cause the victim site owner to 
get messaged, potentially resulting in thousands of such messages.

This isn't really that hypothetical, either. Such chat widgets are 
starting to appear.

I think we need to consider that such widgets will become common and could 
easily be vulnerable to this kind of thing, and should be protected.


> > Secondly, consider Google Image Search, or Reddit with its "open link 
> > with reddit toolbar" option, or any other site that allows arbitrary 
> > Web navigation in a frame or iframe while hosting some sort of toolbar 
> > content from its own page in another frame or container page. This 
> > option would mean that many sites would stop working with these 
> > containers, despite these containers not doing anything evil (there's 
> > no overlapping content, the user is fully aware of what's going on, 
> > etc).
> 
> 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).

Any solution that breaks those sites is a non-starter IMHO.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Michal Zalewski]

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.


[ The only thing that #3 tries to prevent is having a cross-domain IFRAME
  positioned with CSS at negative screen offsets or with negative margins
  / padding, then carefully set IFRAME height and width, to effectively
  "crop" whatever is left displayed on screen. This is a weaker, but still
  plausible variant of the attack. ]



/mz

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

[Robert O'Callahan]

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 say:
> > > Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes
> > > Access-Control-Allow-Origin: http://example.com
> >
> > I think this is a really good proposal. It would allow Web sites to
> > place all content under a single uniform policy for access control, as
> > opposed to the state today where cross-site access depends on how the
> > resource is embedded.
>
> 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 site is compromised? (This happens regularly, especially with,
> e.g., sites with forum software or blog software.) We don't want a
> vulnerability in a widget host site to immediately allow this kind of
> attack on all the widgets that that site hosts.
>

Choose your friends carefully. But really, why does this mapping widget need
to expose UI that can be abused to do evil things with my Google account?

Secondly, consider Google Image Search, or Reddit with its "open link with
> reddit toolbar" option, or any other site that allows arbitrary Web
> navigation in a frame or iframe while hosting some sort of toolbar content
> from its own page in another frame or container page. This option would
> mean that many sites would stop working with these containers, despite
> these containers not doing anything evil (there's no overlapping content,
> the user is fully aware of what's going on, etc).
>

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

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

[Ian Hickson]

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-Control-Allow-Origin: http://example.com
> 
> I think this is a really good proposal. It would allow Web sites to 
> place all content under a single uniform policy for access control, as 
> opposed to the state today where cross-site access depends on how the 
> resource is embedded.

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 site is compromised? (This happens regularly, especially with, 
e.g., sites with forum software or blog software.) We don't want a 
vulnerability in a widget host site to immediately allow this kind of 
attack on all the widgets that that site hosts.

Secondly, consider Google Image Search, or Reddit with its "open link with 
reddit toolbar" option, or any other site that allows arbitrary Web 
navigation in a frame or iframe while hosting some sort of toolbar content 
from its own page in another frame or container page. This option would 
mean that many sites would stop working with these containers, despite 
these containers not doing anything evil (there's no overlapping content, 
the user is fully aware of what's going on, etc).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Maciej Stachowiak]

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


As one of the people who helps decide for Safari, I would agree that  
option 1 is a lot more likely to make it into a security update than  
option 3.


Regards,
Maciej

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

[Maciej Stachowiak]

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 with that spec, it's here: http://www.w3.org/TR/access-control/


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


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

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


I think this is a really good proposal. It would allow Web sites to  
place all content under a single uniform policy for access control, as  
opposed to the state today where cross-site access depends on how the  
resource is embedded.


Would "Require-Access-Control" be an adequate synonym for "Same-Origin- 
Only-Unless-Access-Controls-Says-Otherwise", on the assumption that  
same-origin access always satisfies access control?


Regards,
Maciej

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

[Maciej Stachowiak]

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

[Robert O'Callahan]

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

[Michal Zalewski]

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

[Robert O'Callahan]

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

[Michal Zalewski]

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

[Robert O'Callahan]

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

[Robert O'Callahan]

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

[Adam Barth]

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

[Adam Barth]

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

[Anne van Kesteren]

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

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

[Adam Barth]

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

[Michal Zalewski]

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

[Hallvord R M Steen]

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

[Michal Zalewski]

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

[Anne van Kesteren]

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



--
Anne van Kesteren

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

[Michal Zalewski]

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

[Robert O'Callahan]

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

[Hallvord R M Steen]

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

[Robert O'Callahan]

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

[Křištof Želechovski]

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

[Michal Zalewski]

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

[Robert O'Callahan]

On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote:

> other browsers are getting cross-domain XMLHttpRequest headers
>

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

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


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

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

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


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

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


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


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


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

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

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

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

You don't need a fully-blown SSP.

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

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

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

[Michal Zalewski]

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


I'm not sure what you're talking about here. I'm specifically NOT talking
about Content-Restrictions or Site-Security-Policies or any other policies
for controlling what a page may do once it has loaded.

I'm expressing approval for your option 1, 
"X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes", preferably 
generalized to "X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes" so 
that it can be used for scripts and images too.


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


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


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

[Michal Zalewski]

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

[Michal Zalewski]

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

[Michal Zalewski]

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

[Robert O'Callahan]

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

[Kristof Zelechovski]

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

[Elliotte Harold]

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

[Michal Zalewski]

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 requests, IFRAMEing 
content, etc)... Say:


  http://people.mozilla.org/~bsterne/content-security-policy/

...(which I do not like for a number of reasons, but that's a separate 
thread), or proposals from OpenAjax, etc; I also seem to recall seeing 
something along these lines proposed by Microsoft. Many of these 
essentially extend the basic mechanisms proposed for cross-domain 
XMLHttpRequest.


/mz

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

[Anne van Kesteren]

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


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


Could you list these comprehensive designs perhaps?


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


Are you talking about cross-site requests here? FWIW, for that particular  
problem I believe all vendors agree on the same server protocol, but not  
on the request mechanism. That is, non-Microsoft will do that by evolving  
XMLHttpRequest (see XMLHttpRequest Level 2) and Microsoft does it through  
XDomainRequest.


However, that's an opt _in_ API as such requests are by default not  
allowed.



--
Anne van Kesteren

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

[Michal Zalewski]

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


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


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.


Cheers,
/mz

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

[Kristof Zelechovski]

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

-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 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, the media stream would be hosted in Europe, just like the page 
it's embedded in. It would not be possible to embed a media stream on a 
different host than the page it's embedded in. That's the whole point.

(It would still be possible to mirror hosts in different continents, as 
is done today, but that's a very different issue.)

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

[Robert O'Callahan]

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 and
> well-defined component by itself, and proved to be extremely complex to
> implement right in practice, too. Pretty much *any* effort to patch the
> existing design is bound to be in practice kludgy, regardless of how much
> text is needed to outline implementation goals.
>

Note that if we had option 1 (or in general way for sites to say "do not
allow my resources (scripts, images, pages in IFRAMES) to be loaded
cross-origin, except as I explicitly permit via Access Controls"), that
would also protect such sites from holes associated with inadequate
cross-domain DOM security checks.

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.

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

[Michal Zalewski]

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


The above changes generally clobber something from working at all, and
can provide an error message.


Except most of them don't, and just silently break stuff in situations 
that are perhaps even less intuitive to the user. They all have one 
redeeming quality: they are elegant, can be summed up in one sentence, and 
are very easy to implement for browser vendors.


I really see the points that can be made against #3 on the grounds of 
lacking simplicity, and I can quite easily imagine that clear solutions 
have a much greater appeal; that said, I was looking for a compelling 
reason to dismiss the approach altogether, and aesthetics aside, I do not 
quite see it yet; maybe I'm in the wrong, we can probably leave it at 
this.


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 and well-defined component by itself, and proved to be extremely 
complex to implement right in practice, too. Pretty much *any* effort to 
patch the existing design is bound to be in practice kludgy, regardless of 
how much text is needed to outline implementation goals.


Anyway, to move on - dismissing any particular proposal aside, can we come 
up with any other viable works-by-default scheme that would have a 
comparably beneficial net effect (that is, not making unrealistic 
assumptions about the entire world properly implementing a yet another web 
security check, or not being incompatible with gadgets, embedded ads, 
etc)? If yes, I think it should be a fairly urgent and important goal. If 
not, we should at least make sure that opt-in designs pursued do not break 
too many things (e.g., would not be required to be disabled altogether for 
mashups, gadgets, ads - as on all other fronts, we are working to make 
these safer, with cross-domain inter-frame IPCs, cross-domain 
XMLHttpRequest, etc).


Cheers,
/mz

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

[Smylers]

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

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

[Smylers]

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 them, which amounts to the same thing).
>
> ... 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.

That's adding further complexity to a design which was hardly elegant in
the first place.  We seem to be playing Whac-a-Mole in two different
directions (vulnerabilities and usability glitches) and hoping that
where they meet will be a robust spec for this feature.

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

I don't think an iframe ceasing to work because it's top border has been
scrolled off the screen by a pixel is a non-issue; that would be most
confusing, and frustrating, to users.

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

The above changes generally clobber something from working at all, and
can provide an error message.  Whereas the current proposal has whether
something works changing as it jiggles up and down the page, something
which may seem arbitrary or random to users: they experience the page
sometimes not working but don't know why.

Smylers

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

[Elliotte Harold]

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, the media stream would be hosted in Europe, just like the page 
it's embedded in. It would not be possible to embed a media stream on a 
different host than the page it's embedded in. That's the whole point.


(It would still be possible to mirror hosts in different continents, as 
is done today, but that's a very different issue.)


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

[Elliotte Harold]

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

[Robert O'Callahan]

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

[Elliotte Rusty Harold]

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

[Michal Zalewski]

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]

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

[Elliotte Rusty Harold]

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

[Kristof Zelechovski]

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

[Elliotte Rusty Harold]

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

[Ozob the Great]

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


The bandwidth cost of hosting video makes this option unworkable for some
blogs.

-- 
Ozob

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

[Michal Zalewski]

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

[Maciej Stachowiak]

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


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). I am  
also not sure what you mean by "the other thread".


Regards,
Maciej

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.

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

[Michal Zalewski]

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 moved to the sites that serve the 
blogs.


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.


/mz

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

[Elliotte Harold]

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

[Kristof Zelechovski]

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

[Elliotte Harold]

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.

Cons: requires much rework of existing web apps that are designed around 
browser security flaws.


However, this security model is most definitely possible though without 
eliminating anything useful on the web today. This is exactly the 
security regime that Java applets have lived with for years. Third party 
content just requires an intermediate proxy server. Sadly, the designers 
of HTML and most browsers were not as paranoid as Sun was.


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

[Anne van Kesteren]

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

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

[Michal Zalewski]

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

[Maciej Stachowiak]

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

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

[Maciej Stachowiak]

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

[Greg Houston]

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

[Robert O'Callahan]

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

[Michal Zalewski]

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

[Robert O'Callahan]

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

[Robert O'Callahan]

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

[Robert O'Callahan]

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

[Michal Zalewski]

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

[Maciej Stachowiak]

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  (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] 
[2] 

[3] 
[4] 
[5] 

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

[Maciej Stachowiak]

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

[Ian Hickson]

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

In addition to gadgets, one other type of site that is affected by 
anything we do here would be sites that have UIs like Google Image Search. 
I don't think we should break those either.


I would like feedback from browser vendors on this topic, ideally in the 
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.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'