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)
Core
Security
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>
Comment 1•23 years ago
|
||
Browser, not engine. Reassigning to Security:General
Assignee: rogerl → mstoltz
Component: Javascript Engine → Security: General
QA Contact: pschwartau → ckritzer
Comment 2•23 years ago
|
||
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
Reporter | ||
Comment 3•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
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?
Reporter | ||
Comment 5•23 years ago
|
||
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."
Comment 6•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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).
Assignee | ||
Comment 9•23 years ago
|
||
> 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
Comment 10•23 years ago
|
||
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
Comment 11•23 years ago
|
||
*** Bug 87460 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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
Comment 14•19 years ago
|
||
(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.
Description
•