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.   `._.-(,_..'--(,_..'`-.;.'

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

[Collin Jackson]

On Thu, Sep 25, 2008 at 1:46 PM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
>> 7) New HTTP request header: Browser vendors seem to be moving away from
>> "same origin restrictions" towards "verifiable origin labels" that let the
>> site decide whether two security origins trust each other.  Recent examples
>> of this are MessageEvent's "origin" property [1], postMessage's
>> "targetOrigin" argument [2], and the HTTP "Origin" header [3] [4] [5]. We
>> can adjust proposal (1) to conform to this philosophy: instead of making it
>> an "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP response header,
>> make it an "X-Ancestor-Frame-Origin: http://www.evil.com"; HTTP request
>> header.
>
> Oh yup, I wanted to capture this possibility in #5; it's a noble long-term
> goal, but with the conflicting proposals from Microsoft, Mozilla developers,
> and several other parties, and the high complexity of getting these
> mechanisms right - I am not sure it's a viable solution for the next few
> years. Maybe in 5-10, it would be a reality.

I would actually expect #7 would be the easiest to standardize of all
the proposals. The three examples (origin, targetOrigin, and Origin)
have all been adopted by every major browser vendor (including
Microsoft) within the past year.

Collin

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

[Michal Zalewski]

On Thu, 25 Sep 2008, Collin Jackson wrote:


6) New cookie attribute: The "httpOnly" cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and "UI redress" attacks. If a cookie is set with a
"sameOrigin" flag, we could prevent that cookie from being sent on
HTTP requests that are initiated by other origins, or were made by
frames with ancestors of other origins.


Good point; the concern with this, as with most of the other schemes 
except for #3, is that it breaks some legitimate cross-domain uses such as 
gadgets and mashups (we can either permit anyone to partly or fully 
display a gadget, or deny everyone; we would ideally want to restrict 
partial rendering only).


Just as importantly, some sites are moving to different-domain content 
hosting domains specifically to work around countless bugs, oddities, and 
design flaws in modern browsers (starting with MSIE text/plain / image/* 
behavior and utf-7 sniffing, through Content-Disposition bypass issues, to 
the complete inability to safely serve certain types of non-sanitized 
resources in sensitive domains). Customizable policy frameworks may help 
with this in the long run, but for now, it's a necessity. Any solution 
that puts blanket cross-domain restrictions on IFRAME nesting would need 
to be completely disabled in such scenarios.


This is why I and several people like #3 best, despite its relative 
complexity - because it does not require you to fully expose your content 
to third-party domains.


7) New HTTP request header: Browser vendors seem to be moving away from 
"same origin restrictions" towards "verifiable origin labels" that let 
the site decide whether two security origins trust each other.  Recent 
examples of this are MessageEvent's "origin" property [1], postMessage's 
"targetOrigin" argument [2], and the HTTP "Origin" header [3] [4] [5]. 
We can adjust proposal (1) to conform to this philosophy: instead of 
making it an "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP 
response header, make it an "X-Ancestor-Frame-Origin: 
http://www.evil.com"; HTTP request header.


Oh yup, I wanted to capture this possibility in #5; it's a noble long-term 
goal, but with the conflicting proposals from Microsoft, Mozilla 
developers, and several other parties, and the high complexity of getting 
these mechanisms right - I am not sure it's a viable solution for the next 
few years. Maybe in 5-10, it would be a reality.


/mz

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

[Collin Jackson]

On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> Other quick fixes are easy to come up with, but in general prove problematic
> in many usage scenarios. Based on our internal conversations, we have a
> number of proposals for approaches to how to address the issue, along with
> their pros and cons outlined. All these could be tweaked, combined, etc.;
> none of them seems quite ideal.

Here are two ideas to add to the mix:

6) New cookie attribute: The "httpOnly" cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and "UI redress" attacks. If a cookie is set with a
"sameOrigin" flag, we could prevent that cookie from being sent on
HTTP requests that are initiated by other origins, or were made by
frames with ancestors of other origins. In a CSRF or "UI redress"
attack scenario, it will appear as though the user is not logged in,
and thus the HTTP request will be unable to affect the user's account.

This flag could potentially use the cookie concept of same origin
rather than the HTML5 concept of same origin: ignore port, ignore
scheme unless "secure" flag is set, "domain" attribute can be used to
relax domain comparison.

Pros:

 - Only need to change one line of code where the login cookie is set,
entire site is protected

Cons:

 - "Opt-in" (sites remain vulnerable unless action is taken)
 - Would need to test this to make sure it doesn't break legacy
browser cookie handling

(Adam and I got this idea from someone else, but we don't remember who it was.)

7) New HTTP request header: Browser vendors seem to be moving away
from "same origin restrictions" towards "verifiable origin labels"
that let the site decide whether two security origins trust each
other.  Recent examples of this are MessageEvent's "origin" property
[1], postMessage's "targetOrigin" argument [2], and the HTTP "Origin"
header [3] [4] [5]. We can adjust proposal (1) to conform to this
philosophy: instead of making it an
"X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP response
header, make it an "X-Ancestor-Frame-Origin: http://www.evil.com"; HTTP
request header. This header could be a list of all the origins that
are ancestors of the frame that triggered the request. If the site
decides it does not like the ancestor frame origin it could reject the
request. This could be added as a property of MessageEvent as well to
detect client-side-only UI redress attacks.

Pros:

 - Doesn't break existing sites
 - Easy to check using firewall rules

Cons:

 - "Opt-in" (sites remain vulnerable unless action is taken)
 - Minor increase in HTTP request size (but only for iframe-heavy sites)

[1] 

[2] 

[3] 
[4] 
[5] 

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

[Toby A Inkster]

Michal Zalewski wrote:


3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin  
frame.


Something like focus-follows-mouse plus autoraise for IFRAMEs might  
work.


--
Toby A Inkster

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

[Michal Zalewski]

Hi folks,

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.


For a couple of months now, along with a number of my colleagues at 
Google, we were investigating a security problem that we feel is very 
difficult or impossible to avoid on application side, and might be best 
addressed on HTML or HTTP level in contemporary browsers. These problems 
had recently gained some mainstream attention, and so we hoped to discuss 
potential solutions, and perhaps gain some traction for long-term fixes.


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.


Practical, real-world examples of such "UI redress" attacks were 
demonstrated in the past, and recently resurfaced on an OWASP conference 
(under the name of "clickjacking"); some references include:


 * http://www.thespanner.co.uk/2008/02/11/csrf-chat/
 * https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference
 * http://lists.immunitysec.com/pipermail/dailydave/2008-September/005356.html

We feel that current web browser designs provide no adequate tools for web 
site owners to protect their applications against such attacks. The two 
workarounds often employed right now are:


1) Using Javascript hacks to detect that window.top != window to inhibit
   rendering, or override window.top.location. These mechanisms work only
   if Javascript is enabled, however, and are not guaranteed to be
   reliable or future-safe. If the check is carried on every UI click,
   performance penalties apply, too. Not to mention, the extra complexity
   is just counterintuitive and weird.

2) Requiring non-trivial reauthentication (captcha, password reentry) on
   all UI actions with any potential for abuse. Although this is
   acceptable for certain critical operations, doing so every time a
   person adds Bob as a friend on a social networking site, or deletes a
   single mail in a webmail system, is very impractical.

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.


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)

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

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.

   Pros:

   - Lightweight

   - Far more fine-grained than proposal #1 (though still not perfect)

   Cons:

   - "Opt-in" (sites remain vulnerable unless action is taken)

   - Might seem like an odd abuse of CSS / HTML

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 descript

Re: [whatwg] defining new HTTP headers

[Anne van Kesteren]

On Thu, 25 Sep 2008 12:04:46 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

Anne van Kesteren wrote:

This e-mail from January 27 never got a reply:
  
http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html  
  Several changes to the specification have since then be made,  
including changing header names again, but that happened in August.  
Between January and August nobody got back to me. I'm not really  
inclined to get the Provisional Message Header Field Registry fixed at  
this point.


Nobody is expected to get back to you.


I didn't know that.



As far as I can tell, you are supposed to email IANA:

:

   Send a copy of the template to the designated email discussion
   list [33] [34].  Allow a reasonable period - at least 2 weeks -
   for discussion and comments, then send the template to IANA at the
   designated email address [35].  IANA will publish the template
   information if the requested name and the specification document
   meet the criteria noted in Section 4.1 and Section 4.2.2, unless
   the IESG or their designated expert have requested that it not be
   published (see Section 4.4).  IESG's designated expert should
   confirm to IANA that the registration criteria have been
   satisfied.

Did you?


No, I was awaiting a reply.


--
Anne van Kesteren

Re: [whatwg] defining new HTTP headers

[Julian Reschke]

Anne van Kesteren wrote:

This e-mail from January 27 never got a reply:

http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html 



Several changes to the specification have since then be made, including 
changing header names again, but that happened in August. Between 
January and August nobody got back to me. I'm not really inclined to get 
the Provisional Message Header Field Registry fixed at this point.


Nobody is expected to get back to you. As far as I can tell, you are 
supposed to email IANA:


:

  Send a copy of the template to the designated email discussion
  list [33] [34].  Allow a reasonable period - at least 2 weeks -
  for discussion and comments, then send the template to IANA at the
  designated email address [35].  IANA will publish the template
  information if the requested name and the specification document
  meet the criteria noted in Section 4.1 and Section 4.2.2, unless
  the IESG or their designated expert have requested that it not be
  published (see Section 4.4).  IESG's designated expert should
  confirm to IANA that the registration criteria have been
  satisfied.

Did you?


BR, Julian

Re: [whatwg] defining new HTTP headers

[Anne van Kesteren]

On Thu, 25 Sep 2008 11:28:21 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

Anne van Kesteren wrote:

http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html


So, is there a case where IANA registration was attempted and expert  
review did *not* happen?


This e-mail from January 27 never got a reply:

http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00085.html

Several changes to the specification have since then be made, including  
changing header names again, but that happened in August. Between January  
and August nobody got back to me. I'm not really inclined to get the  
Provisional Message Header Field Registry fixed at this point.



--
Anne van Kesteren

Re: [whatwg] defining new HTTP headers

[Julian Reschke]

Anne van Kesteren wrote:
On Thu, 25 Sep 2008 11:16:06 +0200, Julian Reschke 
<[EMAIL PROTECTED]> wrote:

So what's the spec defining Origin? I thought it was XmlHttpRequest(2)?


Access Control for Cross-Site Requests.


Ah, forgot about that one.

If Origin is used by more than one spec, it might still be good to have 
a standalone-document defining it.


Back to your earlier mail:


As far as I can tell, you are speaking of a new header. This can be defined in 
an IETF document, in a W3C document, and in other places. You just need to 
register it with IANA, and expert review (hopefully) will happen.


Not really :/

http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html 


So, is there a case where IANA registration was attempted and expert 
review did *not* happen?


BR, Julian

Re: [whatwg] defining new HTTP headers

[Anne van Kesteren]

On Thu, 25 Sep 2008 11:16:06 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

So what's the spec defining Origin? I thought it was XmlHttpRequest(2)?


Access Control for Cross-Site Requests.


--
Anne van Kesteren

Re: [whatwg] defining new HTTP headers

[Julian Reschke]

Anne van Kesteren wrote:
On Thu, 25 Sep 2008 11:07:54 +0200, Julian Reschke 
<[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:

...
What's true is that you can't require existing HTTP/1.1 clients to 
send it with every POST request (did anybody seriously suggest that?).
 The suggestion was for POST requests the browser makes based on Web 
APIs (e.g., XMLHttpRequest, , etc.).


OK, so that sounds like syntax and semantics of Origin should be 
defined in a separate spec, and then XmlHttpRequest and HTML5 can make 
a normative requirement (for their scenarios) about when it needs to 
be supplied.


That's the way it is...


So what's the spec defining Origin? I thought it was XmlHttpRequest(2)?

BR, Julian

Re: [whatwg] defining new HTTP headers

[Anne van Kesteren]

On Thu, 25 Sep 2008 11:07:54 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:

Anne van Kesteren wrote:

...
What's true is that you can't require existing HTTP/1.1 clients to  
send it with every POST request (did anybody seriously suggest that?).
 The suggestion was for POST requests the browser makes based on Web  
APIs (e.g., XMLHttpRequest, , etc.).


OK, so that sounds like syntax and semantics of Origin should be defined  
in a separate spec, and then XmlHttpRequest and HTML5 can make a  
normative requirement (for their scenarios) about when it needs to be  
supplied.


That's the way it is...


--
Anne van Kesteren

Re: [whatwg] defining new HTTP headers

[Julian Reschke]

Anne van Kesteren wrote:
> ...
What's true is that you can't require existing HTTP/1.1 clients to 
send it with every POST request (did anybody seriously suggest that?).


The suggestion was for POST requests the browser makes based on Web APIs 
(e.g., XMLHttpRequest, , etc.).


OK, so that sounds like syntax and semantics of Origin should be defined 
in a separate spec, and then XmlHttpRequest and HTML5 can make a 
normative requirement (for their scenarios) about when it needs to be 
supplied.


BR, Julian

Re: [whatwg] defining new HTTP headers

[Anne van Kesteren]

On Thu, 25 Sep 2008 10:36:01 +0200, Julian Reschke <[EMAIL PROTECTED]>  
wrote:
As far as I can tell, you are speaking of a new header. This can be  
defined in an IETF document, in a W3C document, and in other places. You  
just need to register it with IANA, and expert review (hopefully) will  
happen.


Not really :/

http://www.ietf.org/mail-archive/web/ietf-message-headers/current/index.html


What's true is that you can't require existing HTTP/1.1 clients to send  
it with every POST request (did anybody seriously suggest that?).


The suggestion was for POST requests the browser makes based on Web APIs  
(e.g., XMLHttpRequest, , etc.).



--
Anne van Kesteren

[whatwg] defining new HTTP headers

[Julian Reschke]

<http://krijnhoetmer.nl/irc-logs/whatwg/20080925#l-43>:


# # [04:24]  Hixie: Nobody is working on a new version of HTTP, 
though: 2616bis is just revising the spec, and can't make any normative changes to it.


That's not entirely true; for instance, we can make normative changes if 
we have evidence that RFC2616 does not reflect reality.


# # [04:24]  Hixie: Which is kinda problematic if that's the place to define the header. 


As far as I can tell, you are speaking of a new header. This can be 
defined in an IETF document, in a W3C document, and in other places. You 
just need to register it with IANA, and expert review (hopefully) will 
happen.


What's true is that you can't require existing HTTP/1.1 clients to send 
it with every POST request (did anybody seriously suggest that?).


BR, Julian