Last Comment Bug 154957 - iframe content background defaults to transparent
: iframe content background defaults to transparent
Status: RESOLVED WONTFIX
security
: csectype-spoof
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Chris Petersen
Mentors:
: 221174 252319 346398 405727 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-29 02:06 PDT by Jesse Ruderman
Modified: 2013-06-09 18:17 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (618 bytes, text/html)
2002-06-29 18:15 PDT, Jesse Ruderman
no flags Details

Description Jesse Ruderman 2002-06-29 02:06:10 PDT
IFrame content defaults to being transparent.  This is bad for security, because
it means I can show a page like Yahoo in an iframe and add items to that page.

IFrames should only be transparent when the *content* of the iframe sets html or
body (or both) to background:transparent.  That means that the background
property of the <iframe> tag should only matter when the iframe content is
transparent.

It sounds like Mozilla's current behavior is intentional: bug 50623 comment 50
and 51.
Comment 1 Hixie (not reading bugmail) 2002-06-29 05:04:47 PDT
> IFrames should only be transparent when the *content* of the iframe sets html 
> or body (or both) to background:transparent.

That is exactly what we do.
Comment 2 Jesse Ruderman 2002-06-29 18:15:10 PDT
Created attachment 89700 [details]
testcase

With this testcase, the iframe background is transparent half of the time and
opaque half of the time.  Reload to see the different behaviors.
Comment 3 Jesse Ruderman 2002-06-29 18:15:33 PDT
Oops, forgot to attach my testcase.
Comment 4 Hixie (not reading bugmail) 2002-06-30 03:45:04 PDT
that bug is a separate bug than the one you originally filed. please don't morph
bugs. in any case, that testcase works reliably on my trunk build (linux kernel),
so that is a Windows XP bug, presumably.

Note that the testcase is slightly inaccurate; the <iframe> in that testcase
should be transparent, not opaque as it ambiguously claims.
Comment 5 Jesse Ruderman 2002-06-30 13:44:54 PDT
I originally reported this bug incorrectly, so marking as invalid.  I re-filed
my problem as bug 155106.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-06-30 16:50:22 PDT
There may be some confusion here. The description of this bug is correct: IFRAME
backgrounds default to transparent. This bug is invalid because the behavior is
intended and it is correct (well, at least as correct as any other behavior).

> This is bad for security, because
> it means I can show a page like Yahoo in an iframe and add items to that
> page.

Transparent IFRAME backgrounds have no effect on security because you can always
add items by positioning them in front of the IFRAMEd content. In fact, you can
always just mock up a Yahoo-lookalike page and do whatever you like with it.
There is not, and never has been, a way to associate IFRAMEd content with a
particular site, and users must not trust IFRAMEd content in untrusted sites.

The other bug that Jesse filed IS valid. The testcase should always show the
IFRAME as transparent.
Comment 7 Jesse Ruderman 2002-06-30 19:07:23 PDT
> users must not trust IFRAMEd content in untrusted sites

I disagree.  If an IFrame contains both my name and an Amazon logo, I'm likely
to assume that the entire contents of the iframe actually from Amazon. 
Furthermore, clicking in the IFrame *does* do something involving my Amazon
login, possibly causing me to purchase a book or send my money to another web
site.  If a page can position elements to cover an iframe from another site,
that's also a bug IMO.

I find it strange that iframe transparency was designed in a way that is both
less intuitive and less secure than requiring the iframe content to declare its
background as transparent.  I would like this bug to be fixed before web sites
begin to rely on this method.  It would really suck if we decide later that it
is a security hole and are not able to fix the browser without breaking existing
sites.
Comment 8 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-06-30 19:58:41 PDT
> If an IFrame contains both my name and an Amazon logo, I'm likely
> to assume that the entire contents of the iframe actually from Amazon.

Then if a bad guy gets your name somehow and you visit his site, he will easily
fool you into thinking you're at Amazon no matter what we do. We can't stop him
from copying Amazon's logo or any of their other content.

Note that if the bad guy doesn't have your personal information, he can fake a
login screen (as if your cookies were gone). Obviously if you type into that,
you're a goner.

> If a page can position elements to cover an iframe from another site,
> that's also a bug IMO.

We had a lot of DHTML bugs filed against us because we didn't allow elements to
cover IFRAMEs. For example, there are many sites which put ads in IFRAMES. We
wreck those sites if their DHTML pop-up menus pop up under the ad.

We could try to do something about foreign IFRAMEs specifically, but it's a real
can of worms. "Don't let foreign IFRAMEs be covered" isn't good enough; what if
a page has two overlapping IFRAMEs both from foreign sites?

If we have to do something to protect the presentation of foreign IFRAMEs, then
I think the simplest, least error-prone thing to do is to just disable foreign
IFRAMEs completely. If you can think of something better, please tell.

> I find it strange that iframe transparency was designed in a way that is both
> less intuitive and less secure than requiring the iframe content to declare
> its background as transparent.

I have explained why it is just as secure as the status quo, which allows
elements to be positioned over an IFRAME. I also think it's perfectly intuitive:
if you don't ask for a background, you don't get one.
Comment 9 Jesse Ruderman 2002-06-30 22:09:34 PDT
> Then if a bad guy gets your name somehow and you visit his site, he will easily
> fool you into thinking you're at Amazon no matter what we do.

Ok, but you haven't addressed the problem that clicking in an Amazon iframe can
have financial consequences.  I think it's important to prevent other sites from
changing the display of Amazon iframes.

>what if a page has two overlapping IFRAMEs both from foreign sites?
>[what about] ads in iframes [and] DHTML pop-up menus?

We could make a partially covered iframe become gray and not respond to clicks.
 That wouldn't look great on sites with dhtml pop-up menus, but a site with a
banner ad and a dhtml pop-up menu is very unlikely to look nice to begin with.

>if you don't ask for a background, you don't get one

A page that doesn't specify any colors expects to be rendered using the user's
chosen colors.  We should encourage sites to honor the user's chosen colors when
possible rather then telling them that they must specify a background color (and
therefore all colors) in order to be secure.  Furthermore, users can disable
background colors using a UI pref, and those users do not expect same-site or
cross-site iframes to suddenly have transparent backgrounds.
Comment 10 Hixie (not reading bugmail) 2002-07-01 03:11:15 PDT
According to the specs, the default background of the root element is
'transparent'. Thus what we are doing is correct.

The security issues are not affected by this decision, as roc has explained.

-> INVALID.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-07-01 07:08:04 PDT
> Ok, but you haven't addressed the problem that clicking in an Amazon iframe
> can have financial consequences.  I think it's important to prevent other
> sites from changing the display of Amazon iframes.

I'm not sure what the attack is that you're thinking of here. Are you thinking
of some kind of attack where someone alters the display of an Amazon IFRAME,
inducing you to perform a transaction which benefits them somehow?

I suppose I can imagine something like that happening with a site like Ebay.
Perhaps someone could paper over the description of an item to induce you to
place a higher bid.

> a site with a banner ad and a dhtml pop-up menu is very unlikely to look nice
> to begin with.

This amounts to "90% of the web is ugly, so it's OK to make it more ugly", and I
don't agree with that reasoning. Your idea is interesting though. Hmm.

IFRAMEd content that you care about will be secure (otherwise you've already
lost). The security icon doesn't help us here because the bad guys can run a
secure server and most people won't check the certificate. But, how about we
don't allow secure, foreign content to be loaded into IFRAMEs? Wouldn't that
suffice?

> Furthermore, users can disable background colors using a UI pref

If a user chooses "always use my chosen colors", IFRAMEd documents get those
colors too.

> We should encourage sites to honor the user's chosen colors when
> possible rather then telling them that they must specify a background color
> (and therefore all colors) in order to be secure.

I explained many times why background transparency has no effect on security. We
are not going to tell anyone they must specify a background colour.

> A page that doesn't specify any colors expects to be rendered using the
> user's chosen colors.

And it will be when it stands on its own. When it's merely a component of
another page, control passes from the component author to the author of the
complete page. In general, that's both inevitable and desirable.

We should probably change our handling of CSS2 system colors so that the user's
color preferences override the system Window and WindowText colors. This would
simplify the way we handle those color prefs and also provide a
standards-compliant way for page authors to *demand* the user's preferred colors
for their document (or elements within the document), even if their document is
framed. Someone should file a bug about that.

I think you should file a new bug about protecting the display of foreign,
secure IFRAMEs (possibly by disabling them altogether).
Comment 12 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-07-01 10:01:11 PDT
> According to the specs, the default background of the root element is
> 'transparent'. Thus what we are doing is correct.

What does our default background color preference mean, then?
Comment 13 Jesse Ruderman 2002-07-01 10:19:39 PDT
>Are you thinking of some kind of attack where someone alters the display of an 
>Amazon IFRAME, inducing you to perform a transaction which benefits them 
>somehow?

Yes.  Most likely something like "Welcome, Jesse Ruderman.  Please help keep
www.evil.com running.  To encourage Web users to start using our donation
service, the first $5 you donate to any web site is free!"  Or maybe right below
the one-click button, "One-click order this item now and get 75% of the price
refunded as a gift certificate to a friend of your choice!".

>I explained many times why background transparency has no effect on security. We
>are not going to tell anyone they must specify a background colour.

You haven't "explained it many times".  We've been *debating* that for most of
the bug. 

>But, how about we don't allow secure, foreign content to be loaded into IFRAMEs?

I don't think Amazon uses https for its "donate" iframes, and there's no reason
to force them not to.

If I file a new bug, it will be the same as this one but only for the case where
the hostname, port, or protocol is different between the parent page and the
iframe.  I would prefer if Mozilla were consistent (easier to develop for, fewer
bug reports), backwards-compatible (don't radically alter the nature of <iframe>
because of an ambiguous statement in a CSS spec), and not full of distributed
security checks (less likely to have a code-level security hole or
pref-dependent security hole).
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-07-01 10:34:32 PDT
Why don't we apply the default background color in preferences to documents
within IFRAMES, just like other documents?  I agree with Jesse -- and when I
reviewed the transparent background in IFRAMEs patch, I was under the
understanding that it would require explicit specification of transparent
backgrounds in the content to override that default background color preference.
Comment 15 Hixie (not reading bugmail) 2002-07-01 11:04:37 PDT
>> According to the specs, the default background of the root element is
>> 'transparent'. Thus what we are doing is correct.
>
> What does our default background color preference mean, then?

It sets the default for when there's nothing to be transparent onto. i.e. it
sets the default colour of the root canvas.


Jesse: the reason transparent IFRAMEs are no more of a risk than before is that
they haven't increased the potential number of exloits. Pretty much everything
you can do now you could do before.
Comment 16 Hixie (not reading bugmail) 2002-07-01 11:07:46 PDT
To do that we'd need to use different preferences stylesheets for our HTML and
XML documents, and we would never be able to move that out of C++. Also, we'd
still have to have the fallback for the root canvas.

I don't really see the point.
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-07-01 12:54:36 PDT
> You haven't "explained it many times".  We've been *debating* that for most
> of the bug.

I told you right at the beginning that every attack you can do with transparent
IFRAMEs you can do much more effectively by positioning elements above the
IFRAME --- something you've been able to do forever in Mozilla and IE --- and
therefore transparent IFRAMEs don't introduce any new security issues. You have
not yet contradicted me.

If you still believe that transparent IFRAMEs should be non-default for reasons
of security, please provide a scenario where an IFRAME with a transparent
background allows an attack that is not possible by other existing means.

> I don't think Amazon uses https for its "donate" iframes, and there's no
> reason to force them not to.

If they're not using https for their donation pages, then anyone with access to
any network link between you and Amazon can take full control of your HTTP
connection and donate away. TCP connection hijacking is *easy*.
Comment 18 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-07-01 13:00:05 PDT
dbaron: it turned out to be really painful to implement what you and Jesse want.
In the style system the root element really does default to a transparent
background, so it's impossible to distinguish "transparent by default" from
"user set it to be transparent" and apply background color prefs only to the
first case. So either we do some hideous hack to the style system to expose an
interface where we can distinguish those two cases, or we change the handling of
background color prefs so they actually get applied to the root element in the
style system. I tried the latter but it broke BODY->HTML background propagation
(because now we see that a background style has been set on the HTML element so
we don't propagate the BODY style...)
Comment 19 Jesse Ruderman 2002-07-01 15:47:08 PDT
> I told you right at the beginning that every attack you can do with transparent
> IFRAMEs you can do much more effectively by positioning elements above the
> IFRAME --- something you've been able to do forever in Mozilla and IE --- and
> therefore transparent IFRAMEs don't introduce any new security issues. You have
> not yet contradicted me.

As I said in comment 7, that's a bug that should be fixed.  You even helped to
come up with a robust way to fix it in comment 8.  The existence of that
security bug is not an excuse to add another, especially since iframe
transparency is more likely to be relied upon by web developers than being able
to obscure part of an iframe using z-index.

> If they're not using https for their donation pages, then anyone with access to
> any network link between you and Amazon can take full control of your HTTP
> connection and donate away.

Blocking foreign https iframes (as you suggested in comment 11) would force
Amazon to use http.  How would that help?  Cross-origin security and encryption
should be kept separate.

Updated exploit text: "Welcome, Jesse Ruderman.  Please help keep
www.evil.com running.  If you donate $5 this month, Amazon will give you $5 off
your next $20+ bookstore purchase!"  Users would be unlikely to notice the
missing money until months later.
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-07-01 19:59:40 PDT
> iframe transparency is more likely to be relied upon by web developers than
> being able to obscure part of an iframe using z-index.

I don't know how you arrived at this conclusion. If you look at the Bugzilla
bugs filed against IFRAMEs, you will see that the opposite is true.

Whatever fix we use for elements covering IFRAMEs will probably fix whatever
transparency issues there are, too. So why don't we focus the really important
problem for now, and after we've solved it, see what, if anything, remains to be
done for transparency? (Note that elements that cover an IFRAME will intercept
mouse events, and are therefore much more dangerous than elements under an
IFRAME, which never receive mouse events.)

> Blocking foreign https iframes (as you suggested in comment 11) would force
> Amazon to use http.

Or they could just open a new window.

What are they using now? I've never seen one of these donation pages.
Comment 21 Jesse Ruderman 2002-07-03 11:39:18 PDT
It turns out that Amazon's box is an image, not an iframe.  Examples:
http://web.greens.org/etc/donate-am.shtml, http://www.archive.org/.  But using
an iframe would make more sense, because an iframe would respect the user's
color and font-size prefs.

We have to make foreign iframes default to having an opaque background.  It
would be nice to make foreign iframes and same-host iframes act the same way, in
order to confuse web authors less and be more sure that our security is sound. 
We might not be able to do that if we release several versions with the current
behavior.  Waiting until the z-index bug is fixed before fixing this bug would
be silly.
Comment 22 Hixie (not reading bugmail) 2002-07-03 15:01:30 PDT
I honestly don't understand why. You have not demonstrated that transparent
backgrounds are a security risk. Could you show us an example exploit?

We should definitely not disable this feature because of a wider problem. We
should fix the wider problem, if there really is one.
Comment 23 Jesse Ruderman 2002-07-05 19:45:03 PDT
I'm not asking to disable the feature of transparent iframes.  I'm asking to
make it so you have to use something like body { background : transparent; } in
order to get a transparent iframe.
Comment 24 Hixie (not reading bugmail) 2002-07-06 07:24:36 PDT
You do have to do that. It also happens to be the initial value, so saying
nothing is, per spec, equivalent to saying it.

We can't override the initial value, because of the complications of body/html
background propagation.
Comment 25 Jesse Ruderman 2003-02-23 16:40:24 PST
This is the second site I've encountered where the contents of an iframe are
unreadable because iframes default to being transparent:
http://flimsysilence.net/

I still think iframe backgrounds should not be transparent by default, both for
security and for backwards-compatibility.
Comment 26 Jesse Ruderman 2003-03-13 19:09:52 PST
(The first was http://arstechnica.com/etc/subscribe/premier-agreement.html,
which I saw when another bugzilla user mentioned it in bug 155106.)
Comment 27 Jesse Ruderman 2003-07-05 18:05:04 PDT
IE's solution to this security and backwards-compatibility problem is to add an
"allowtransparency" attribute to IFRAME elements:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/allowtransparency.asp
Comment 28 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-07-06 04:29:57 PDT
Interesting, but it doesn't change my opinion. If in one year you've only
encountered two sites where this caused a problem then backward-compat doesn't
seem pressing. I personally haven't encountered any. And I stand by my previous
comments regarding security.
Comment 29 Boris Zbarsky [:bz] 2003-10-03 20:22:30 PDT
*** Bug 221174 has been marked as a duplicate of this bug. ***
Comment 30 Bill Mason 2004-09-21 23:49:19 PDT
*** Bug 252319 has been marked as a duplicate of this bug. ***
Comment 31 Ryan Jones 2006-07-29 02:02:49 PDT
*** Bug 346398 has been marked as a duplicate of this bug. ***
Comment 32 Phil Ringnalda (:philor) 2007-11-27 18:28:20 PST
*** Bug 405727 has been marked as a duplicate of this bug. ***
Comment 33 Jesse Ruderman 2008-09-25 17:01:37 PDT
See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html and bug 457011 for the security bits.
Comment 34 Sufehmi 2008-10-11 17:21:00 PDT
Jesse - thanks for sharing, and congratulations for your insight. I registered just to be able to say thanks to you here. Also I don't blame Mozilla - on 2002 I understand the idea (clickjacking) may seem to be very strange / far-fetched. Now however we have XSS, SQL injections, and professional criminals actually profiting daily from various internet security holes.

We have firewall for our machine. I also have mod_security setup in Apache to act as firewall for my web-apps.
Perhaps now its time for us to have firewall for our browsers? Firefox plugin architecture is ready for that. And NoScript is already paving the way with its clickjacking-specific features.

Note You need to log in before you can comment on or make changes to this bug.