Closed
Bug 94474
Opened 23 years ago
Closed 21 years ago
Relaxing of origin policy disables LiveConnect to Applet - document.domain issue
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
DUPLICATE
of bug 146458
Future
People
(Reporter: petr.zdrahal, Assigned: yuanyi21)
References
()
Details
(Keywords: ecommerce)
Attachments
(3 files)
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
BuildID: 2001062815 (Mozilla 0.9.2) and 2001080110 (Mozilla 0.9.3)
A main HTML page contains an applet, loaded from the identical location
(i.e. "server1.wdf.sap-ag.de"). The applet's mehtods are normally accessible
via LiveConnect from JavaScript to Java.
If the main page relaxes own origin by setting of document.domain property to
suffix the current location (i.e. "wdf.sap-ag.de"), the LiveConnect will
disable the access to Applet.
===
Note: In the Mozilla 0.8 (Build ID: 2001021508), Netscape 4.7, NN6.01 it still
works.
Reproducible: Always
Steps to Reproduce:
1. Copy the HTML page and applet into the same directory on your webserver.
2. Open the bugfind.html in your browser typing the full URL
(i.e.: "http://yourserver.mozilla.org/bugfind.html"). Don't use the short
server names ("http://yourserver/bugfind.html").
3. Display the document.domain using the button "Show domain". Depending on
entered url you should see something like ("yourserver.mozilla.org")
4. Check if the LiveConnect is possible. Press the button "Display AppletInfo",
the geAppletInfo() method from the Applet will be called and the result will be
displayed in the popup.
5. Press the button "Relax domain", the document domain will be set to suffix
behind the first dot in the document domain ("mozilla.org")
6. Check LiveConnect again, now the exception occurs
Actual Results:
===================================
Exception on JavaConsole displayed:
sun.plugin.liveconnect.OriginNotAllowedException: JavaScript is not from the
same origin as the Java code,
caller=http://mozilla.org,
callee=http://yourserver.mozilla.org/weblab/
at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown
Source)
at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
Expected Results:
===================================
Applet method call is possible and response is displayed.(as in the step 4.)
===========================================================
bugfind.html (main page)
============================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Script-Type" content="text/javascript">
<title>EchoApplet test</title>
</head>
<body>
<applet CODEBASE="."
CODE="EchoApplet"
ID= "EchoApplet"
NAME="EchoApplet"
WIDTH="20"
HEIGHT="20"
MAYSCRIPT>
</applet>
<h2>LiveConnect Check (JavaScript to Java)</H2>
<SCRIPT>
function relaxDomain(){
var lnDotPos = document.domain.indexOf( "." );
if (lnDotPos >= 0) document.domain = document.domain.substr( lnDotPos +
1 );
return document.domain;
}
document.writeln("navigator.userAgent = " + navigator.userAgent + "<BR>")
document.write("<HR>");
document.writeln("document.domain = " + document.domain + "<BR>");
document.writeln("applets.length = " + document.applets.length + "<BR>");
document.write("<HR>");
</SCRIPT>
<FORM>
<INPUT type="BUTTON" onclick="alert('Current:'+ document.domain)" value="
Show domain">
<INPUT type="BUTTON" onclick="alert('Changed to: ' +relaxDomain());" value="
Relax domain">
<INPUT type="BUTTON" onclick="alert(document.applets
['EchoApplet'].getAppletInfo())" value=" Display AppletInfo">
</FORM>
</body>
</html>
===========================================================
===========================================================
EchoApplet.java
===========================================================
import java.applet.*;
public class EchoApplet extends Applet {
/**Construct the applet*/
public EchoApplet() {
}
/**Initialize the applet*/
public void init() {
}
/**Get Applet information*/
public String getAppletInfo() {
return "Applet Info coming from EchoApplet ";
}
}
==================================================================
|
Reporter | |
Comment 1•23 years ago
|
||
|
|
Reporter | |
Comment 2•23 years ago
|
||
|
|
Reporter | |
Comment 3•23 years ago
|
||
|
|
Reporter | |
Comment 4•23 years ago
|
||
Wrong user agent has been entered in the original description. This behavior
can be reproduced in the following Mozilla versions (also in the brand new
Netscape 6.1):
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2)
Gecko/20010628
BuildID: 2001062815 (Mozilla 0.9.2)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3)
Gecko/20010801
BuildID: 2001080110 (Mozilla 0.9.3)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2)
Gecko/20010726 Netscape6/6.1
|
||
Comment 5•23 years ago
|
||
Reassigning to Security:General for further triage. If this is not the
right module, then it should go to the OJI component, not LiveConnect -
Assignee: rogerl → mstoltz
Status: UNCONFIRMED → NEW
Component: Live Connect → Security: General
Ever confirmed: true
QA Contact: pschwartau → ckritzer
|
||
Comment 7•23 years ago
|
||
Added an url + 2 keywords.
at ulr i get this i java console. (just like the description for this bug)
(url works fine in NN)
sun.plugin.liveconnect.OriginNotAllowedException: JavaScript is not from the
same origin as the Java code, caller=https://bgbank.dk,
callee=https://netbank.bgbank.dk/bgnetbank/java/danskesikker.jar
at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller(Unknown Source)
at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
I'm forced to use IE (i don't like NN4 that much, moz is better and 3 browsers
seem too much for one system).
I don't like being forced over to IE, and neither do you. So what'll you do ?
(rhyme). Mozilla 1.0 seems far away to mee. Mayby it's too foggy here :)
Is this a security feature that shold not be altered, or is moz too strict here?
I don't think that banks will change their e-banking / internet-banking /
homebanking, (whatever your name for it is) to suit moz/N6.x users.
|
||
Comment 8•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Netscape 6.2.1 freezes when 'JSObject.call' issued.
I think the freeze happens because the Java Console is looping in the
Exception.printStackTrace call
|
|
||
Comment 10•23 years ago
|
||
Adding the mozilla 1.0 keyword since that fixing this bug IMO, is the last thing
preventing me from only using one browser (converting).
Is there not an easy way of getting the NN 4.7 behavior, or setting the origin
policy less strick? (questions please answered this time!!)
I'm not sure about this, but fixing this bug might open up for using e-banking
in mozilla/netscape on mac/linux platforms... (getting people to upgrade from
4.7 :-) ) In Denmark NN 6 is not a supported platform for e-banking, while 4.7 is.
This is one of the bugs that definetly should make it into the rumored mozilla
1.0/Netscape 6.5 releases.
Keywords: mozilla1.0
|
||
Comment 11•22 years ago
|
||
Added to the mozilla financial shames page,
http://blue-labs.org/financial-shames.php
|
||
Updated•22 years ago
|
QA Contact: ckritzer → bsharma
|
||
Comment 13•22 years ago
|
||
It seems this is still an issue with a trunk build on both win, mac os, linux, ..
As BG Bank (and their partner company Danske Bank) have their mind set on using
an old implementation based on LiveConnect to Applet, the meaning of this bug is
worth mentioning:
Everyone in Denmark with a bank account with BG Bank can not use Mozilla (et
al) to log into their netbanking solutions.
Or Danske Bank for that matter - which is the largest Danish bank today, I think
it should be noted - they are both based on the same code, even if they are two
different banks (same IT group+systems I think I read).
I am blaiming noone, but this bug makes it a problem for a lot of Danish
netbanking internet users to use Mozilla, in both the Netbank systems and
Mozillas current implementation. Tell me what we need to get further.
This seems similar to my bug about XMLHttpRequest not working if document.domain
is set.
I think there are enough users affected by this so that we need to reconsider...
Summary: Relaxing of origin policy disables LiveConnect to Applet → Relaxing of origin policy disables LiveConnect to Applet - document.domain issue
|
||
Comment 15•21 years ago
|
||
caillon, can you take a swing at this, or suggest a fix here that someone else
could try? Cc'ing jst too.
/be
Assignee: security-bugs → caillon
Status: ASSIGNED → NEW
|
||
Comment 16•21 years ago
|
||
So, AIUI, document.domain will only work if BOTH things set their domain to be
identical. That doesn't appear to be the case here, so I think this bug is
actually invalid.
|
||
Comment 17•21 years ago
|
||
(In reply to comment #16)
> So, AIUI, document.domain will only work if BOTH things set their domain to be
> identical. That doesn't appear to be the case here, so I think this bug is
> actually invalid.
The bug is about cases where the (main) domains are equal, but the subdomains
differ. Like www.danskebank.dk and netbank.danskebank.dk.
It would be nice with a clear statement whether this sould be allowed or not. I
agree it is bad coding, but it's not likely that two subdomains are unrelated.
So I don't see the security risk, but what is the "official" mozilla.org opinion
on that subject?
Subdomains are often conrolled by totally different entities. Take several ISPs
and webhosting companies that give you a subdomain under their domain. For
example, Comcast personal webpages have URLs like this:
http://<username>.home.comcast.net
|
|
||
Comment 19•21 years ago
|
||
Comment 18 is right. From Nav 2.0.x when we shipped the first same-origin trust
model, we've never equated a domain and its subdomain.
/be
|
Assignee | |
Comment 20•21 years ago
|
||
In cuurent Java plugin implementation (at least Sun JRE) does not support the
relaxing of document.domain at all.
I think once bug 146458 gets fixed, this problem will be gone. Because at that
time liveconnect will (just) use the DOM same-origin checking mechanism.
Depends on: unicast1
|
|
||
Comment 22•21 years ago
|
||
Rather than dependent, isn't this actually a duplicate of bug 146458 (or vice
versa -- though bug 146458 has more detail and probably should remain open out
of the two)?
|
|
Assignee | |
Comment 23•21 years ago
|
||
Yes, fix 146458 also fix this problem.
*** This bug has been marked as a duplicate of 146458 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
|
||
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•