Closed Bug 45099 Opened 25 years ago Closed 24 years ago

Scripts denied access to content from different origin, breaks brokerage site

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: cheng, Assigned: security-bugs)

References

(
URL
)

Details

(Whiteboard: evangwanted) 

From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.2.16-3 i686)
BuildID:    2000071008

When I go to the above page (with PSM 1.1), I got the following error messages
in the console:

JavaScript error: 
https://tdaccess43.tdbank.ca/login2.asp line 23: 

JavaScript error: 
 line 0: uncaught exception: [Exception... "Access to property denied"  code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"  location:
"https://tdaccess43.tdbank.ca/login2.asp Line: 23"]

*** check number of frames in content area 
*** check number of frames in content area 
*** check number of frames in content area 
JavaScript error: 
 line 0: 

JavaScript error: 
 line 0: uncaught exception: [Exception... "Access to property denied"  code:
"1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"  location:
"<unknown>"]

I am unable to log in as the buttons don't respond any more.  The problem only
appeared recently, as I was able to go to this site last week.

Reproducible: Always
Steps to Reproduce:
1. Just go to the page.


This page has caused me a lot of headaches even in Netscape 4.73 (only in
Linux).  In fact, for the last two weeks I can go to the site with Mozilla but
not necessarily with Netscape 4.73.  If this helps any, here is what happens
with Netscape 4.73:

1. When I load the page, very often one of the frames on the left hand side
(they are really thin frames) won't load, and I got a popup box saying:

  The document contained no data.
  Try again later, or contact the server's administrator.

Also, sometimes I see the following JavaScript Error:

  JavaScript Error: https://tdaccess4m.tdbank.ca/login2.asp, line 23:

  top.frames[0].setTransactionInProgressEx is not a function.
  JavaScript Error: https://tdaccess4f.tdbank.ca/navbarjs.htm, line 5:

  access disallowed from scripts at https://tdaccess4f.tdbank.ca/navbarjs.htm to
documents at another domain.

If I am persistent enough and keep clicking reloads, eventually everything will
load and I can view the page.  However, it seems that the number of reloads it
takes is completely random.  One thing to notice is that different frames seem
to come from different servers (probably some sort of load balancing scheme),
and maybe this is the source of the problem.  Unfortunately, there is no problem
with neither IE or Netscape on Windows or Mac, so sending anything to the
webmaster simply results in a "we don't support Linux" reply.
Browser, not engine. Reassigning -
Assignee: rogerl → asa
Component: Javascript Engine → Browser-General
QA Contact: pschwartau → doronr
Linux, build ID 2000071211

I'm not seeing the javascript errors.

The Netscape 4.73 brokenness is irrelevant for Mozilla.

Reporter, could you download this build or a later one and see if you're still
getting these javascript errors?
I am still seeing this on 2000071215.
OK, I see this error message in the console too. It doesn't seem to affect the 
layout of the page though.  tested with 071208 mozilla bits on NT. over to DOM
Assignee: asa → jst
Component: Browser-General → DOM Level 0
QA Contact: doronr → desale
Reassigning to mstoltz, the security guy. Mitchell, I had a quick look at this
and here's what I found out. The document at
https://webbroker1.tdwaterhouse.ca/ is a frameset document and all the frames in
the frameset comes from https://tdaccess4o.tdbank.ca/ (i.e. different domains).
Some of the documents in the frames try to access top.frames and this fails due
to the document that tries to access top.frames and the document in "top" are
from different domains. This does however work in 4.x (the security checks, at
least).
Assignee: jst → mstoltz
I can't seem to get to this site at all, I'm getting a "connection was refused"
dialog. Looks like an SSL bug. Seeing "access to property denied" is the
behavior I would expect in this situation. If a frame wants to access its parent
(from a different host), I would call this a WONTFIX case as it's generally a
bad idea to allow this and this site is probably a rare exception. If the issue
is one frame accessing another frame which comes from the same host, we could
see about allowing this, though it would add complexity (allow access to
top.frames[1] if the current document and top.frames[1] have the same host). If
there are more sites like this one out there (I could see this situation being
more common with SSL sites) then I may reconsider this bug. Can I get some
input, from the reporter et al, as to how important it is that we support this
site, or whether the problem occurs with other sites?
Status: NEW → ASSIGNED
Target Milestone: --- → M18
It is important for me to have this site supported, since I have no other way to
access my banking online unless I boot to Windows and run IE (which I would
prefer not to do).  But perhaps this is a bit selfish, as I have not been able
to find any other site with the same problem.

Just to give a bit more info, here is what I think happens:

When I log onto the main site webbroker1.tdbank.ca, it probably does some sort
of load balancing and decide to serve all the frames from one particular server.

I suppose when Mozilla comes out (which can be a while) and it is decided that
this behavior is not supported, the bank will have no choice but to fix it.  But
until then, whenever I have reported about something not working on Netscape for
Unix, they always replied "use IE or Netscape on Windows or Mac". :(
WONTFIX unless I find out this breaks some popular sites. Anyone know of any 
top100 sites which depend on this behavior?

Changing description.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Summary: Javascript "Access to property denied" exception → Scripts denied access to content from different origin, breaks brokerage site
Should this be marked "evangwanted"?  I really want to see this fixed one way or
another, and my voice has not been loud enough to influence either Mozilla or
the bank.

Btw, instead of checking that frames come from the same hosts, does it make more
sense to check that frames have the same certificate?  Also, my impression from
Mitchell's comments is that current things won't work even if all the frames
come from the same host.  This can be a much more common problem...but I am just
guessing.
Do the frames in question in fact have the same certificate? Right now, JS 
security doesn't look for any ID information from SSL channels (such as the 
certificate name). This might be a nice feature, but we won't have the resources 
to implement it anytime soon. Things should work if all frames come from the same 
host. If this is not the case, please let me know.

Did 4.x share principals for SSL-delivered content?  I seem to recall that being
the case, but I'm not 100% certain.


I'm not sure, but someone (Norris, i think, or someone on the Cartman team) told
me that many ssl sites don't want this. They would rather we not equate "content
served from my SSL server" with "content signed by me on a per-file basis."

So given the current behavior of IE and Netscape 4.x, are they doing anything
wrong?
*** Bug 56458 has been marked as a duplicate of this bug. ***
WONTFIX
Status: RESOLVED → VERIFIED
*** Bug 67880 has been marked as a duplicate of this bug. ***
I am curious as to why Netscape 6.01 (Linux) does not show the same behaviour.
Using Netscape 6.01 I can successfully login to my TD WebBroker account
at the above URL. 

I had been under the impression that Netscape 6 was just a repackaged Mozilla;
but it appears that they do fix (perceived) problems as well.

At any rate, I would like to point out that by not allowing access to the 
above URL, Mozilla makes itself unsuitable for use by a significant number
of Canadians. The Toronto Dominion Bank's brokerage arm is a *major* brokerage
firm in Canada; perhaps the largest. Thus, an inability to access the TD web
site via Mozilla is a very, very real handicap.

For this reason, I would ask that you seriously reconsider the "wontfix" status
of this issue.


I'll look into why 6.01 is not affected, that's weird, I would think it should
be. TD Waterhouse is calling scripts in a frame from a page in a different
domain; this is bad practice. To allow them to do this in Netscape 6 would
reduce our security considerably. Encourage the brokerage firm to put the
various servers they use in the same domain (like tdwaterhouse.ca) and then call
document.domain="tdwaterhouse.ca" in their scripts to allow them access to each
other.

marking "evangwanted," maybe our evangelists can give TD Waterhouse a call?
Whiteboard: evangwanted
I'll try asking them again...I have tried many times in the past and everyone of
my comments were responded with one of the followings:

  1. We only support IE 5 and NS 4.x
  2. We only support Windows and Mac versions

Maybe if all of us do that then they will pay some attention.

Can some kind soul explain to me explicitly why what TD Waterhouse is doing is
considered to be bad practice? If I can go to TDW and tell them that what they
are doing leaves either them or their clients in an unsecure state I *may* be
able to get their attention. Walking through a scenario that illustrates this
insecurity would really be useful. 

For my own curiousity, is TD W breaking any standards or specifications by
doing what it is doing; or just engaging in a bad practice. If it is the 
latter, should it be the browser's job to protect the web site against its
own risky behaviour? To put it another way, does Mozilla fail to adhere to
any standards or specifications by not accepting TD W's page? Or is this just
one big gray, free-for-all area (seems kinda unlikely)? It would seem to me
that either Mozilla is in violation of a spec/standard or TD W is - no? 
Otherwise, we would be talking about an under-specified situation which 
is not what one could call conducive to interoperability. 

And, finally, given that IE, Netscape 4.7, and Opera all support TD W's page
it seems somewhat strange that the people involved in these projects do
not have a strong grasp of security. Is it really this really the case?




Here is a scenario:

1)  I have a webpage at domain A
2)  I have a frame in my page that loads a page from domain B.  This can be
    easily made the size of the whole content area if need be.  Thus I can
    pretend to be domain B to the casual user.

Now say site B is a banking site or a brokerage (eg TD Waterhouse's site).  If
cross-domain scripting is allowed, I can watch the <input type=password> on
their site and when it is blurred (indicating that the user has entered a
password) I can grab the value and submit it to a form I control.

So TD Waterhouse is not doing anything insecure themselves.  But allowing the
sort of thing they are doing would leave them open to this kind of attack.

We are not protecting the website here; we're protecting our users.  And that is
our job.

As for standards, this behavior _is_ undefined, as far as I can tell from
reading the DOM specs.  They talk about what one can do within a document, but
not much about what can be done across documents... 
Bug 52920 appears to be the same problem: a frame trying to access a sibling 
frame in the same domain where the frameset is in another domain.  Fwiw, I 
agree with the wontfix status of both bugs.
Boris's explanation is correct - it's not that TD Waterhouse's configuration is
insecure, but our browser would be less secure if we permitted this behavior.
Security policy is not part of the DOM standard, so this is in fact "one big
gray, free-for-all area." Each browser (actually, each user) determines the
security policy they want, and Mozilla's is slightly more restrictive than NS4.x
or IE (though not by much; IE blocks cross-host access to almost all DOM
properties and script-defined globals, as we do).

There's a tradeoff between security and functionality, and we're a little more
to the security side at the cost of compatibility with a few sites (only two
that I've seen so far). My apologies to the TD Waterhouse customres involved. I
will post a change to your preferences file that will make Mozilla work with TD
Waterhouse at the cost of some security, if you'd like.
Yes, please post the preferences file change! That definitely works for me.

BTW, wouldn't a reasonable trade-off have a pop-up alert warning the user
about potential security risks, and allowing them to proceed (at own risk)
or cancel (or press the "details" button)? I realize that this is more work
for you guys, but since this is an unspecified area, and since 
interoperability should be everyone's goal (well maybe not our friends
in Redmond :-), this would seem to be a reasonable compromise. The golden
rule of protocol implementation is to be conservative in what you produce and
liberal in what you accept. Obviously, when security is an issue, this 
"golden rule" can't be followed blindly, but a balanced approach would seem
to produce the best of both worlds.

At any rate, the preferences file change is more than good enough for me.



read my lips - no new dialogs. Every time a security vs. functionality debate
comes up, someone suggests a warning dialog. I really don't want to add any more
of these. The average user simply clicks OK no matter what the dialog says. They
are an annoyance and they reflect badly on the browser, not on the website.

Let me figure out exactly which DOM property TD Waterhouse is barfing on, and
I'll post a prefs fix.
Currently Mozilla simply ignores attempts by users to log in to their account.
The appearance is that Mozilla is broken with respect to the correct 
processing of the page in question. In my opinion, which obviously differs
from that of most here, it reflects *much* more poorly on the browser to 
give the appearance of being broken as opposed to popping up a dialog and 
thus letting the user know that the browser has come across a security issue.

When Joe Blow attempts to log into his account and can't he is going to say
to himself, "hmmm, Mozilla's got a bug here - guess I'll go back to IE".
When his friend asks him about Mozilla, he'll say "it's quite nice in
many ways, but buggy in others". Joe Blow will not file a bug report, he will
not attempt to get to the bottom of the problem, he will simply go back to
using IE (or Opera, or Netscape 4.7x), because as far as he is concerned,
Mozilla is buggy.

I'm afraid I just don't see how giving the appearance of being buggy
reflects better on Mozilla than giving the hapless user *some* indication
of what is going on.

As for the users clicking OK no matter what - so what? The browser would have
done its job (and better than IE, Opera, etc); it detected a potential
security problem, it alerted the user to it and offered to go into details,
and left it up to the user to decide whether to go on or not. Isn't empowerment
of the user supposed to be one of salient features of the open source 
movement, as opposed to the paternalistic attitude taken by Microsoft? Who
wants to buy a car with the hood welded shut? :-)

At the risk of sounding like a broken record, I will reiterate my main point:
IMO, apparent buggy processing of a page reflects far worse on Mozilla than 
giving the user some (any) indication of why the page is not being processed.

> As for the users clicking OK no matter what - so what? The browser would have
> done its job

no no no! That's not real security, that's just ass-covering. Real security must
be acceptable to users and not so annoying as to be self-defeating. We _do_
empower the user, by providing sophisticated security policies fully
configurable by the user. (There's no UI for configuring them yet, but that's
coming soon. In the meantime, you can edit your prefs file.) In any case, only
advanced users will ever do this.

Bottom line, I know the TD Waterhouse site appears broken, and I apologize for
that, but I have only heard of two websites that do this (the other is the
Belgian Yellow Pages) and that seems a small price to pay for a significantly
more secure browser. I promise I'll post instructions on how to make TD
Waterhouse work.

"empowerment" in this case should come as easy pre-configuring of security
policies, not asking the user every time a problematic site is encountered.
Actually, I agree. As long as the user has a mechanism (and I'm not 
hung up on the exact nature of that mechanism) to configure his
security policies, then that is indeed empowerment.

And, I agree that a pop-up *every* time the hapless user accesses
a particular web site is annoying. A one-time pop-up similar to
the cookie pop-up that allows you to always accept cookies 
(lower security) for a given domain (site) is far better.

But, like I said above, I'm not hung up on the exact nature of the
mechanism. Pre-configuring of security policies works for me.

Looking forward to the prefs file change.

PS, although not at all obvious from this thread, I do think Mozilla
is turning into one excellent browser. 


5 weeks ago a promise was made to post the prefs fix to allow the
the TD Waterhouse site to work. Now, either I am looking in the wrong
place for this post, or it was never made. If the former, could Mr Stoltz
kindly tell me where I should look; and if the latter, could Mr Stoltz 
confirm that it is still his intention to follow through on his promise.

Thank you.

*** Bug 87147 has been marked as a duplicate of this bug. ***
See also bug 52920 and bug 80559.
*** Bug 59523 has been marked as a duplicate of this bug. ***
This bug had the JS info:

http://bugzilla.mozilla.org/show_bug.cgi?id=59523
Being able to change this behavior using a hidden pref depends on bug 91215,
"Need a way to allow/deny access to Class[any number]", because
window.frames==window.
The prefs fix was posted for bug #59523. It's for an other site, but it also did
work for "my" site (#82344), so I guess it should also do for "yours". Only I
had to add the lines to preferences.js, not prefs.js, as prefs.js is overwritten
every time the browser quits.
TD Waterhouse has given their online brokerage site a long-needed overhaul, and
this problem has disappeared in the new version (https://webbroker.tdwaterhouse.ca/)
Works for me! 

(I like where it says "Best viewed with 800x600 screen resolution." :-)
You need to log in before you can comment on or make changes to this bug.