Closed Bug 94474 Opened 23 years ago Closed 20 years ago

Relaxing of origin policy disables LiveConnect to Applet - document.domain issue

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED DUPLICATE of bug 146458
Milestone:
Future

People

(Reporter: petr.zdrahal, Assigned: yuanyi21)

References

(
URL
)

Details

(Keywords: ecommerce)

Attachments

(3 files)

Main HTML page with JavaScript
1.31 KB, text/html
Details
Applet (Java Source)
312 bytes, text/plain
Details
Applet (Code)
367 bytes, application/octet-stream
Details 
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 ";
  }
}
==================================================================

    
    

    
  

      
      
      
      

        Attached file
          
        Applet (Java Source)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Applet (Code)
        — 
      

    


  

    
    

    
  
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





    
    

    
  
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

    
    

    
  
I'll take it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0

    
    

    
  
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.
URL: https://netbank.bgbank.dk/html/index....
Keywords: 4xp, 
          
            ecommerce

    
    

    
  
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

    
    

    
  
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

    
  
Blocks: 76573

    
  
Blocks: 124594

    
    

    
  
Added to the mozilla financial shames page,
http://blue-labs.org/financial-shames.php

    
    

    
  
Futuring.
Target Milestone: mozilla1.0.1 → Future

    
  
QA Contact: ckritzer → bsharma

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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 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

    
    

    
  
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

    
    

    
  
taking...
Assignee: caillon → kyle.yuan

    
    

    
  
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)?

    
    

    
  
Yes, fix 146458 also fix this problem.

*** This bug has been marked as a duplicate of 146458 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: