Closed Bug 81084 Opened 23 years ago Closed 23 years ago

Hostile Javascript can prevent 'view only this frame' from working

Categories

(Core :: Security, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: zackw, Assigned: security-bugs)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19-pipefix i686; en-US; rv:0.9) Gecko/20010505 BuildID: 2001050521 Javascript embedded in a page can detect that the page has been loaded without its frame set, and forcibly reload the frame set. This defeats 'view only this frame', 'open frame in new window', etc. Like all Javascript which interferes with the navigation user interface, this should be considered malicious code and Mozilla should refuse to execute it. Reproducible: Always Steps to Reproduce: 1. Load page at listed URL. 2. Select 'view only this frame' for the content, from the context menu. 3. See the page override your request and redisplay the frame set. Actual Results: I get the frame set again. Expected Results: Mozilla should ignore the script and display just the frame I want to see. Here is a sample hostile script: <script LANGUAGE="JavaScript" TYPE="text/javascript"> <!-- if ((top.location.href == location.href) || (top.location.hostname != location.hostname)) { if (location.pathname.indexOf ('/focus/') == 0) { top.location.replace ('http://' + location.hostname + '/frames/?focus=' + location.pathname.substring (7, location.pathname.indexOf ('/', 7)) + '&content=' + location.pathname + escape (location.search)); } else top.location.replace ('http://' + location.hostname + '/frames/?content=' + location.pathname + escape (location.search)); } // --> </script>
Browser, not engine. Reassigning to Security:General
Assignee: rogerl → mstoltz
Component: Javascript Engine → Security: General
QA Contact: pschwartau → ckritzer
So... should accesses to top.location be disabled in documents which have been loaded with "view only this frame"? What about document.write'ing a meta refresh tag? What about calling history functions ( history.go() and company) ?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
I'm not that familiar with Javascript, so I can't give you a list of what should and should not be allowed. The guiding principle I'd like to see - applied to *all* active page features, not just this one - is: if it interferes with the user interface for navigation, it is hostile code and should not be executed. For the specific issue discussed under this bug: well, the user asked the browser to show only this frame, so any and all scripting features that can prevent that from happening need to be disabled. I think it's reasonable to assume that the user is willing to put up with snazzy page features breaking in this context. If it's too hard to come up with a complete list of Javascript functionality that could cause this effect, that should be a big fat hint that Javascript is too powerful - and the appropriate response would be to start nuking features wholesale, until you got down to a core that couldn't be abused.
Zach, what's the point of a powerless DOM scripting language? You have the view that the JS is an adjunct to the page. This is becoming less and less true, for good reasons. The problem with what you want is that it's impossible to tell my "document.write a meta refresh tag" scenario from a page that has a meta refresh tag to start with.... or from a page that document.writes all its content. Nevertheless, disabling access to top.location for pages which we are trying to view outside their frameset seems worth looking at. Mitchell? Any reasonable way of doing that?
Frankly, I have never much seen the point of a browser-embedded scripting language at all. I find that nine times out of ten Javascript interferes with what I want to do with the Web, which boils down to "Give me the content and nothing else dammit." The one time in ten where it's actually useful is sufficiently useful that I do leave Javascript on, and I still can't get per-site Javascript whitelisting to work, so that isn't an acceptable workaround for me. Note that that one time in ten is, as far as I see, always either generating static-as-displayed content on the fly, or performing client-side mangling of a form submission. I think that a limited Javascript that could only do those things, but was barred from interfering with the user interface, would be both practical to implement and useful for web page designers. Note also that I very much want to do lots of things that web page designers don't want me to be able to do. Take the original example: not only do I want to be able to do 'view only this frame' and see only that frame, but I want to be able to hand the URL for the frame to someone else, and when they load it they get just the sub-frame. Or look at my other bug reports - most of them are of the form "I want to be able to prevent Mozilla from doing X no matter what the page says."
These two comments: "I'm not that familiar with Javascript..." "Frankly, I have never much seen the point of a browser-embedded scripting language at all. " go hand-in-hand. If you are not that familiar with JS, then you may not be familiar with the solution to the problem. I don't know what your specific level of familiarity is with regards to JS, but since I am quite familiar with JavaScript (but by no means as good as /be), I'll go out on a limb and say that there is more likely than not a web-based (rather than code-based) solution to your issue. Don't get me wrong Zach - I'm not trying to bust your chops here, and I can empathize with what you are saying. I flat-out *refused* to learn JavaScript for 2 years, and when I was finally forced to learn it, I discovered an incredible range of things I simply could not do with HTML markup. I spent two years writing testcases for DOM Level 1, and utilize JS & DOM in almost every webpage because of the convenience it provides me *as* a web programmer. If I actually had the time right now, I'd consult my trusty JS Reference Manual and find an answer. I'm sure you have one, but in the off chance you don't, I personally recommend O'Reilly "JavaScript: The Definitive Guide". My understanding of the whole point of Standards Compliance in Web Browsers it to make it easier on web developers and, as you are doubtless aware, DOM and JS are a big part of that. Now, in all fairness, if the problem you are running into is the 10th time out of 10, I have also found that Mitchell Stoltz is a reasonable person and good engineer. I certainly cannot promise you anything, nor do I expect Mitch to feel obligated to my statements, but if the code-based answer is something he can do and is something he feels doesn't create a security issue, he is good at implementing such things. I would also very much like to get his take on this issue, as he has a good sense of what is problematic (security-wise) to implement and what isn't.
What you say is interesting, but you are still coming at it from the point of view of the web page _author_. I'm thinking about this exclusively from the point of view of the web page _reader_. If there is any way for the user of the browser to dink with Javascript supplied by a web server he has no control over, well, that is a great surprise to me. There is certainly no simple in-browser interface to that... As such, your statement that "there is more than likely a web-based solution to your issue" is pretty much moot, because this isn't about writing my own web pages, this is about what happens when what the page reader wants clashes with what the page author wanted... ... and - yes, this is a biased point of view - the page reader must always win that argument, or the browser ceases to be a tool in my hand and becomes a dangerous weapon in the hand of the page author. Maybe I should file a new bug with a more general scope... my real beef isn't the specific frame problem (though I still want to see that fixed), it's that I see Mozilla's scripting capabilities turning it into the next Internet security disaster, if the sandbox is not improved. Maybe it's not possible to embed Javascript in an HTML mail message and turn it into a worm, the way one can do with Outlook and VBA scripts. But how can I have confidence in that when I continually find web sites taking control of the browser's user interface?
The problem refered to in the description of this bug could be fixed if a frame could be "maximised" (take a look at Forte Free Agent http://www.forteinc.com/ to see what I mean).
> Maybe it's not possible > to embed Javascript in an HTML mail message and turn it into a worm, the > way one can do with Outlook and VBA scripts. But how can I have confidence > in that when I continually find web sites taking control of the browser's > user interface? Zack, you wound me. We draw a distinction between dangerous code (that can read or modify your private information), and annoying code, which reloads its frameset or opens multiple windows. IMHO, we have been very successful at blocking dangerous code. While we do what we can to stop annoying code, that's a difficult problem, and frankly it's of lower priority than preventing dangerous code. Distinguishing annoying code, like the site you mention above, from legitimate code, turns out to be a very hard problem. As Boris pointed out, we can't distinguish "code that interferes with navigation" in all instances. We could implement something that blocks the setting of window.location if the window was loaded using "show only this frame" or "open in new window," but this would break a lot of sites for a lot of people who really don't care whether the page reloads its frameset. I think the better approach is customization, and that's what I'm working towards. You can simply prevent that particular site, and any others you choose, from setting window.open. You can do this currently, using configurable security policies...there's just no UI for it yet. You have to hand-edit your prefs file right now. What I'd like to see happen is that concerned citizens like yourself could publish a security config file that blocks particular annoying sites from doing annoying things, and others could add this file to their browser's security policy. That way, people who care about this can block annoying behavior, and legitimate sites that set window.location from within a frame won't be broken for everyone else. I'm just not sure we can distinguish what securityfocus does from other sites' use of location that isn't for the purpose of reloading the frameset. I can guarantee that if you suggest "nuking features wholesale" you will not be taken seriously by anyone who has a say over what the browser's features are. Configurability is the key. If you think Javascript is useless, you can simply turn it off. Better yet, you can use configurable security policies (complete documentation coming soon, I promise) to restrict what Javascript can do. You can make it so that JS can only do "client-side mangling of a form submission," if that's your pleasure.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Marking VERIFIED WONTFIX on: -MacOS91 2001-05-23-08-trunk -Win98SE 2001-05-23-09-trunk -LinRH62 2001-05-23-08-trunk
Status: RESOLVED → VERIFIED
*** Bug 87460 has been marked as a duplicate of this bug. ***
I disagree with the WONTFIX. There is an easy way to prevent this problem, which is what I wrote in bug 87460: Just pretend the frameset is still there, but show only the selected frame. This way the JavaScript won't be able to see the difference (since the frameset is already there, just hidden), but the only part shown is what the user wants.
I've reopened bug 87460 and made it into an rfe for a change in the implementation of show only this frame as described by Cesar
(In reply to comment #9) > We could implement something that blocks the setting of > window.location if the window was loaded using "show only this > frame" or "open in new window," but this would break a lot of sites > for a lot of people who really don't care whether the page reloads > its frameset. <snip> I don't understand at all. Firstly, how would it break the site for people who don't care, as opposed to those who _want_ it to break straight back into frames? Secondly, why would anyone select "show only this frame" or "open frame in new window" in the first place if he/she/it wants it to go straight back into the frameset?
You need to log in before you can comment on or make changes to this bug.