Closed Bug 45099 Opened 24 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. ***
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.