Closed
Bug 163410
Opened 22 years ago
Closed 15 years ago
JavaScript error: "Security Error: Content at http://{xxx} may not load data from {yyy}."
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: sascha, Assigned: dveditz)
References
()
Details
(Keywords: regression)
Mozilla 1.1b exhibits this behaviour that Javascript restricts the access from a page located on "funweb.at" to another document located at "funweb.at:9000". This worked with Mozilla 1.1a and all earlier versions. The full error message on the Javascript console: Error: uncaught exception: Security Error: Content at http://funweb.at/.. may not load data from http://funweb.at:9000/.. When I select copy, the string "PAagpI32" is copied. The scenario consists of a input form and a Javascript "framework" which are handled/generated by two distinct web servers on the same machine.
Comment 1•22 years ago
|
||
Reassigning to Security:General; cc'ing dveditz -
Assignee: rogerl → mstoltz
Component: JavaScript Engine → Security: General
QA Contact: pschwartau → bsharma
Comment 2•22 years ago
|
||
I very much believe this to be the intended behavior. This is also the actual and implemented behavior of Internet Explorer since at least 4.0: "About Cross-Frame Scripting and Security" http://msdn.microsoft.com/workshop/author/om/xframe_scripting_security.asp Scripting between pages is explicitly forbidden when these pages are not on the same protocol, domain and port.
Reporter | ||
Comment 3•22 years ago
|
||
The text at the referenced URL does not even mention the word "port". Further evidence is the fact that MSIE executes the Javascript as expected without any errors. The documents are all loaded from the same domain (*.funweb.at). According to the URL you quoted, "The range of permissible access for a page can be expanded when a script assigns the document.domain property to a suffix of the site name space [..]" Well, we do that and it has stopped to work in Mozilla 1.1. It works in Mozilla 1.0 and earlier, as well as MSIE/NS 4+. if (navigator.appCodeName == 'Mozilla' && parseFloat(navigator.appVersion) >= 5.0) document.domain = 'funweb.at';
Assignee | ||
Comment 4•22 years ago
|
||
Because of the ability to abuse document.domain to spider inside someone's firewall (bug 154930) document.domain was changed to require *both* pages involved to set the domain explicitly or you do not get the expanded access. Microsoft has said that they also will be taking this approach when they release SP1 for IE 6.0, and the page Thor referenced implies that. In many cases document.domain had to be set on both pages anyway (pages from A.site.com and B.site.com), but for pages which otherwise inherit the correct document.domain value you'll have to explicitly set it, as a kind of signal "I'm willing to share my data with my subdomain".
Reporter | ||
Comment 5•22 years ago
|
||
The site is working correctly with Mozilla 1.2a, so I assume that the bug has been fixed since 1.1a. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Marking verified as per above developer comments.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 7•21 years ago
|
||
This bug has resurfaced in Mozilla 1.2.1. This might be related to the (unusual?) code flow. The JS console displays: Error: uncaught exception: Permission denied to call method HTMLDocument.writeln All involved documents contain these lines: if (navigator.appCodeName == 'Mozilla' && parseFloat(navigator.appVersion) >= 5.0) document.domain = 'domain.at'; 1. domain.at:5000 invokes a function in the top frameset, loaded from domain.at:80. This works. 2. The called function (domain.at:80) starts a timer top.setTimeout("go_real()", 200); This works too. 3. The function go_real (from domain.at:80) tries to modify the contents of a frame. This raises the above exception. window.display.document.open(); window.display.document.writeln(buf); <-- exception here The frame window.display was loaded from domain.at:80.
Status: VERIFIED → UNCONFIRMED
Resolution: FIXED → ---
Reporter | ||
Comment 8•21 years ago
|
||
As an addendum, Mozilla 1.3a exposes the same behaviour.
Comment 9•21 years ago
|
||
(In the following case, only the domain changes, protocol and port are unchanged.) ** Expected behaviour [Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] [Also: "Netscape® Communicator 4.8" (en, 20020722)] G1. <http://www.fininfo.fr/> (redirects to <http://www.fininfo.fr/fininfo/GetIndex.event>) G2. Click on OPCVM in the left menu (= <javascript:Open_WindowOpcvm('GetOpcvm.event')>) G2a. A new window opens (empty for now) G2b. Prompts for outdated (2003.02.26) certificate: Click "OK" G2c. Prompts for secure/insecure mix: accept it (redirects to <http://www.europerformance.fr/europerformance/opcvmMgmt/CoteQuotidienne.po?origine=fininfo>) G3. In upper left (of the new window), search for "afer" G4. A new window opens: <http://www.europerformance.fr/europerformance/opcvmMgmt/ChoixOpcvm.po> ** Broken behaviour [Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4b) Gecko/20030507] B2a-B2b. The new windows briefly opens, and closes immediately. JS Error: [ Security Error: Content at http://www.fininfo.fr/fininfo/GetIndex.event may not load data from about:blank. ] B3. In upper left (of the initial window), search for "afer" B4. A list of 3 items is displayed on the right: click any of the links. B4a. get JS Error: [ Security Error: Content at http://www.fininfo.fr/fininfo/GetRedirect.event?id=FR0000299364%2CXX%2C25&url_origine=GetRecherche.event%3Fcode_libelle%3Dafer may not load data from about:blank. ] B4b. Repeat step B4 First, you get G2a and G2b, then B4a instead G2c. NB: In fact, repeating B4, either lead to B4a or B4b "at random". ***** I already add "4xp" keyword, and change OS from 'Linux' to 'All'; and only wait a little before adding 'Regression' keyword, upping Severity to 'Major', and confirming ('New') bug. From the comments so far: *up to v1.1a/Linux: Works *v1.1b/Linux: Broken *v1.2a: Works *v1.2.1: Broken *v1.3a: Broken *v1.3/W95: Works *v1.4b/W95: Broken The Works <-> Broken changes by themselves are very odd ! Then we'll have to settle for which behaviour we should actually have... I can already say that if "Broken" is the intended behaviour, the JS Error is not enough for a end user, we need a popup to tell what is going on (with may be a checkbox to accept the security risk). Or, at the very least, to add a sentence to the JS Error like "Contact the Webmaster to have him redesign its site(s) behaviour according to xxx policy". I'll test later (= tomorrow for me) with IEv6sp1/W2K.!.
Keywords: 4xp
OS: Linux → All
Comment 10•21 years ago
|
||
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507] Addition to comment 9: Confirming testcase on W2K. Case B4b may be a timing consequence on my slow W95 computer: I don't see it with my fast W2K. --> MsIE v6.0sp1 (on W2K): follow the Expected behaviour (= G case) !! <-- Severity: Normal -> Major Summary: (text update) Keywords: adding Regression Flags: blocking1.4? Status: Unconfirmed -> New
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.4?
Keywords: regression
Summary: Security Error: Content at domain.dom may not load data from domain.dom:9000 → JavaScript error: "Security Error: Content at http://{xxx} may not load data from {yyy}."
Comment 11•21 years ago
|
||
not seeing this problem in high-profile sites or reported frequently. not going to block 1.4 for this.
Flags: blocking1.4? → blocking1.4-
Comment 12•21 years ago
|
||
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3.1) Gecko/20030425] v1.3.1 works fine, as v1.3 does. (with v1.3 profile, at least)
Comment 13•21 years ago
|
||
Is there a setting that can be modified to allow pages from http://blah1 (xml pages) to have access to pages from http://blah2 (xsl stylesheets) (like the one in IE)? This a critical issue for us!
Comment 14•21 years ago
|
||
Re: comment #13: can you give real examples of the two domain names? Would it help if they both ended in .com, and a script in each page were to set document.domain = "com"? /be
Comment 15•21 years ago
|
||
This happens with match.com's javascrip messenger window. Briefly opens a blank placeholder popup window then dissapears. Javaconsole shows this error: Security Error: Content at http://www.match.com/myinfo/mymatchmsg.asp?SID=38A82BB4-76D9-4099-BEA7-3E7FF27277F6&TrackingID=0&Theme=8 may not load data from about:blank.
Comment 16•21 years ago
|
||
Re: comment 14 For an example of xml rendering where xml & xsl files are from different domains, see http://apps.adcom.uci.edu/expresso/econtent/Content.do?resource=342 (both are .uci.edu domains)
Updated•21 years ago
|
Comment 17•21 years ago
|
||
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624] (v1.4rc3) Bug still there. (case B2a-B2b)
Comment 18•21 years ago
|
||
Addition to comment 17: In v1.4rc3 at least, it seems that while I get the errors, the pages are not actually blocked ! (This is another testcase, even if it may not last too long: since the europerformance site seems broken since a few days.) 1. <https://www.videoposte.com/statique/index.html> (with cookies-JS prefs on) 2. click on the 'ISIN' link (in bottom left frame) 3. the page does load in a new window, after getting the error: { Security Error: Content at https://www.videoposte.com/statique/identif.html may not load data from http://www.lapostefinance.fr/fr/popups/epargne_et_placements/isin.html. } That's surprising ... but, at least, it should allow me to actually stop using v1.3.1 (besides bug regression tests) :-)
Comment 19•21 years ago
|
||
Addition to comment 18, and update of comment 9: I confirm that v1.4rc3/v1.4 do load the pages, even if they still generate the JS messages. (This behaviour changed _after_ v1.4b...) New URLs (a '3' has been added) and messages are: 2c) <http://www.europerformance.fr/europerformance3/opcvmMgmt/CoteQuotidienne.po?origine=fininfo> [ Security Error: Content at http://www.fininfo.fr/fininfo/GetIndex.event may not load data from about:blank. Security Error: Content at http://www.fininfo.fr/fininfo/GetIndex.event may not load data from http://www.europerformance.fr/europerformance3/opcvmMgmt/CoteQuotidienne.po?origine=fininfo. ] 4) <http://www.europerformance.fr/europerformance3/opcvmMgmt/ChoixOpcvm.po> [ Security Error: Content at http://www.europerformance.fr/europerformance3/opcvmMgmt/MenuListe.po may not load data from about:blank. ]
Comment 20•21 years ago
|
||
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030925] (v1.5rc2) (W98SE) Bug still there (as in comment 19): confirming on W98SE. { Security Error: Content at http://www.europerformance.fr/europerformance3/opcvmMgmt/Detail.po?code_interne=8025|702439 may not load data from about:blank. }
Comment 21•21 years ago
|
||
Recent reports here involving window.open (comment 15 onward) seem likely to be dups of bug 220421. /be
Comment 22•21 years ago
|
||
Re comment 21: Agreed: reproduced with both cases in bug 220421 comment 2 testcase. Adding (at least untill I can check v1.5_final): *(Depends on): bug 220421
Depends on: 220421
Comment 23•21 years ago
|
||
Try today's trunk build, the patch landed there first. /be
Assignee | ||
Updated•17 years ago
|
Assignee: security-bugs → dveditz
QA Contact: bsharma → toolkit
Comment 24•17 years ago
|
||
I have the same problem with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7 And Firefox 3 can't import a external xml file in xsl stylesheet via document() function. Code: <xsl:variable name="i18n" select="document('http://myServer/myFile.xml')" /> In the error console I have this message: Security Error: Content at about:blank may not load data from http://myServer/myFile.xml. It works well for Firefox version >=1.5 Why is it a security problem for Firefox 3? Thanks for your answer.
Assignee | ||
Comment 25•15 years ago
|
||
I think this got fixed. Comment 24 is a different problem because some of the handling for about:blank pages was changed. If that's still a problem it needs to go into a new bug.
Status: NEW → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•