Closed
Bug 154957
Opened 22 years ago
Closed 22 years ago
iframe content background defaults to transparent
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jruderman, Assigned: roc)
References
Details
(Keywords: csectype-spoof, Whiteboard: security)
Attachments
(1 file)
618 bytes,
text/html
|
Details |
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•22 years ago
|
||
> 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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 2•22 years ago
|
||
With this testcase, the iframe background is transparent half of the time and opaque half of the time. Reload to see the different behaviors.
Reporter | ||
Comment 3•22 years ago
|
||
Oops, forgot to attach my testcase.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 4•22 years ago
|
||
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.
Keywords: pp
Reporter | ||
Comment 5•22 years ago
|
||
I originally reported this bug incorrectly, so marking as invalid. I re-filed my problem as bug 155106.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 6•22 years ago
|
||
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.
Reporter | ||
Comment 7•22 years ago
|
||
> 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.
Status: RESOLVED → REOPENED
Keywords: pp
OS: Windows XP → All
Hardware: PC → All
Resolution: INVALID → ---
Assignee | ||
Comment 8•22 years ago
|
||
> 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.
Reporter | ||
Comment 9•22 years ago
|
||
> 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•22 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 11•22 years ago
|
||
> 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).
> 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?
Reporter | ||
Comment 13•22 years ago
|
||
>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).
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•22 years ago
|
||
>> 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•22 years ago
|
||
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.
Assignee | ||
Comment 17•22 years ago
|
||
> 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*.
Assignee | ||
Comment 18•22 years ago
|
||
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...)
Reporter | ||
Comment 19•22 years ago
|
||
> 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.
Assignee | ||
Comment 20•22 years ago
|
||
> 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.
Reporter | ||
Comment 21•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 23•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 25•21 years ago
|
||
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.
Reporter | ||
Comment 26•21 years ago
|
||
(The first was http://arstechnica.com/etc/subscribe/premier-agreement.html, which I saw when another bugzilla user mentioned it in bug 155106.)
Reporter | ||
Comment 27•21 years ago
|
||
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
Assignee | ||
Comment 28•21 years ago
|
||
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•21 years ago
|
||
*** Bug 221174 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•21 years ago
|
Whiteboard: security
Comment 30•20 years ago
|
||
*** Bug 252319 has been marked as a duplicate of this bug. ***
Comment 31•18 years ago
|
||
*** Bug 346398 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 33•16 years ago
|
||
See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html and bug 457011 for the security bits.
Comment 34•16 years ago
|
||
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.
Reporter | ||
Updated•11 years ago
|
Keywords: csec-spoof
Resolution: INVALID → WONTFIX
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•