146458 - (unicast1) Liveconnect calls fail if applet's codebase is in different domain

Status: RESOLVED FIXED

(Core Graveyard :: Java: Live Connect, defect, P1)

Description

[Andrew Milkowski]

From Bugzilla Helper:
User-Agent: Netscape 7.0 Preview Release 1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 
Netscape/7.0b1 
BuildID:    

Main html page includes <script 
src="http://localhost.unicast.br.com/html/wrapper.js"></script>

wrapper.js includes applet codebase via these lines:

document.write('<applet code="TestApplet" 
codebase="http://localhost.unicast.br.com/classes/" name="TestApplet" width=0 
height=0>');
document.write('</applet>');

a sample LiveConnect call document.TestApplet.onload(); (in the wrapper.js) 
cause Netscape7 browser to issue the following exception:

sun.plugin.liveconnect.OriginNotAllowedException: JavaScript is not from the 
same origin as the Java code, caller=http://127.0.0.1, 
callee=http://localhost.unicast.br.com/classes/
	at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller
(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)




Reproducible: Always
Steps to Reproduce:
1. Setup two domains on the server (in my example I modified my host file to 
have local domains 127.0.0.1 and localhost.unicast.br.com 

2. using Netscape7 enter url: http://127.0.0.1/html/netscape7.html

3. in java console note the security exceptions issued

Actual Results:  exception was issued:

sun.plugin.liveconnect.OriginNotAllowedException: JavaScript is not from the 
same origin as the Java code, caller=http://127.0.0.1, 
callee=http://localhost.unicast.br.com/classes/
	at sun.plugin.liveconnect.SecureInvocation.checkLiveConnectCaller
(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation.access$000(Unknown Source)
	at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)


Expected Results:  since the applet codebase comes from the same domain as the 
javascript
there is no reason for the "Origin not allowed exception"

Comment 1

[Andrew Milkowski]

Attachment: page with <script src="http://localhost.unicast.br.com/html/wrapper.js"></script>

netscape7.html should be open with http://127.0.0.1/html/netscape7.html

Comment 2

[Andrew Milkowski]

Attachment: contains applet codebase and javascript-Liveconnect call

Comment 3

[Andrew Milkowski]

Attachment: source code for the testapplet

Comment 4

[Andrew Milkowski]

Attachment: Win XP, host file C:\WINDOWS\system32\drivers\etc used to test two domains

Comment 5

[Mischa Beitz]

*** This bug has been confirmed by popular vote. ***

Comment 6

[Matthias Versen [:Matti]]

no blocker

Comment 7

[Andrew Milkowski]

Running submitted testcase with:

Mozilla 1.0 Release Candidate 3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc3) Gecko/20020523

still produced sun.plugin.liveconnect.OriginNotAllowedException

Comment 8

[Andrew Milkowski]

Running submitted testcase with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530

still produced sun.plugin.liveconnect.OriginNotAllowedException

Comment 9

[Arun Ranganathan]

Andrew,

Wait a second: 127.0.0.1 and localhost.unicast.br.com are not the same thing. 
Why not change one of the URLs to be exactly the same all the time?  Why is this
a blocker?  Perhaps I'm misunderstanding things -- can you explain why they
ought to be treated as the same domain, and moreover, *why* you can't hardcode a
consistent domain instead of using two different nomenclatures of referring to
what you think is one domain?

Comment 10

[Andrew Milkowski]

Arun,

  Hi.  Keep in mind that we're a 3rd party product. So, what we're simulating 
here is a real world deployment scenario for us.
1. localhost.unicast.com.br is a simulated codebase for our javascript file and 
applet jar file.  In the real world this would be adcontroller.unicast.com.

2.  127.0.0.1 is a simulation of a site using our technology.  This could just 
as easily have been www.aol.com.

  The problem is that our javascript and applet which have the same codebase 
are getting a security exception with netscape 6.  This doesn't happen with 
earlier versions of netscape or IE.

  This is a blocker for us because we need our javascript and applet to talk to 
each other which is critical for our technology.  We suspect that Mozilla is 
treating our javascript as coming from the web-site's codebase, when in reality 
it is coming from our codebase.  I just happens to be inserted into the 
website's content as a 3rd party script.

Best,
Andrew

Comment 11

[Andrew Milkowski]

Running submitted test case with:

Mozilla 1.1a
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611

still produced sun.plugin.liveconnect.OriginNotAllowedException

Comment 12

[Arun Ranganathan]

Received a special drop of 1.4.0_01.  I'll try and run tests with it.

Comment 13

[Arun Ranganathan]

This shouldn't be in Security | General, but rather, in the overloaded OJI bin
:-(  I'd like to get Sun to comment on it first.  It may well be a Mozilla issue
eventually, but currently I can think of it belonging in the OJI layer.

Comment 14

[Arun Ranganathan]

This belongs to the OJI layer.  Andrew, you've uploaded your source code for the
test applet (presumably a *.java file) as application/octet-stream.  Can you
upload it using text/plain?

Comment 15

[Andrew Milkowski]

Attachment: TestApplet.java (plain text (text/plain)

Comment 16

[Arun Ranganathan]

In today's teleconference with Sun, it was suggested that the 'MAYSCRIPT'
attribute was missing from your markup (Applet tag).  Can you put that in and
see if this problem reoccurs?  Sun will look at this problem also.

Comment 17

[Andrew Milkowski]

Attachment: new wrapper that is compatible w/ all browser syntax

some compatibility javascript changes so the code runs (for comparisons, ie
IE6, Netscape 4.7 and of course mozilla)

Comment 18

[Andrew Milkowski]

Attachment: TestApplet.java (THE RIGHT JAVA SRC CODE , MY APPOLOGY)

the previously attached src code (87984) was for a completely different defect!

(I have several of them pending, all confirmed) my greatest appology

This TestApplet DOES NOT make any Applet-Javascript calls, therefore DOES NOT
NEED to be MAYSCRIPTED!, even after adding MAYSCRIPT in the Applet tag, 
the security exception does not go away under mozilla, all other browser 
run the sample code just fine, including Netscape 4.7!

Comment 19

[ericwl]

please add os/2 to OS list

Comment 20

[Joe Chou]

I tried the test case, with and without MAYSCRIPT, also had problem, in my case,
crashed. Need to dig in more.

Comment 21

[Andrew Milkowski]

Running submitted test case with: (latest mozilla latest SUN JVM)

Mozilla 1.1a 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611

Java(TM) Plug-in: Version 1.4.1
Using JRE version 1.4.1-beta Java HotSpot(TM) Client VM

still produced sun.plugin.liveconnect.OriginNotAllowedException

Comment 22

[/\/\arcio Galli]

I created the live sample based in the samples from Leon. I confirmed that this
is working with Netscape 4.x and does not work with Netscape 6.2.3 (win98) and
Netscape 7PR1(win98). 

Here is the file that represents the third-party site: 
-----------------------------------------------------
http://www.dhtmlplanet.com/testcases/applet/thirdparty.html

This HTML file includes (via <script src..>) the wrapper: 
--------------------------------------------------------
http://www.geckonnection.com/testcases/applet/wrapper.js

The wrapper js file is sucessfully doing document.write to the thirdparty
document writting the applet tag which origin is the same of the js file: 
http://www.geckonnection.com/testcases/applet/ 

Comment 23

[/\/\arcio Galli]

Reassigning to security general. Michell, this is a blocker to Unicast (Rich
Media Effort). I added comment #22 so we can retest quickly. I also found the
bug 94474 that is sort of related. 

In the samples of comment #22, the first page (dhtmlplanet) is loading the
script from the location (geckonnection). The applet also comes from
(geckonnection) however we have the security exception. 

Comment 24

[Andrew Milkowski]

using url http://www.dhtmlplanet.com/testcases/applet/thirdparty.html
with following OS/browser/JVM configuration throws Security Exception
:

Windows XP

Java(TM) Plug-in: Version 1.4.1
Using JRE version 1.4.1-beta Java HotSpot(TM) Client VM

Netscape 6.2.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 

Regression Testing back to Netscape Communicator 4.79 succeeds (no Security 
Exception)

Comment 25

[/\/\arcio Galli]

Well, it's working in 4.x so we added the 4xp. 

Comment 26

[/\/\arcio Galli]

-> to Mitch.

Comment 27

[Xiaobin Lu]

The problem is obvious from java console print out. Java side figure out the URL
of the applet (callee) correctly, however, since the url of caller is not the
same as the callee and based on same origin rule, the call can not be made. Java
side get the caller's URL from the param passed from liveconnect. So the browser
side need to figure out the right url of the script and pass it to java side.

Comment 28

[Harald Weinreich]

Yes, but the problem is:
* No other browser I know shows this behaviour
* This security feature cannot be deactivated. (?)
Therefore a lot of Applets using LiveConnect don't work with Mozilla.

Comment 29

[David C Peterson]

<<however, since the url of caller is not the same as the callee and based on 
same origin rule, the call can not be made. >>

They ARE the same in reality.  That's the point.  If Netscape 6 is somehow 
confusing that fact, then that is what needs to be fixed.

Comment 30

[bchai]

Load the applet at say:
www.abc.com/index.html

Have a link to a page:
www.abc.com:80/applet.html

Click on the link, then make a call to the applet.

Result: Same error will occur.

Comment 31

[Rob Jaworski]

over to beard.

Comment 32

[saari (gone)]

beard runs from java, ->bnesse

Comment 33

[Jaime Rodriguez, Jr.]

This is a potential blocker for a major embedding customer.

Comment 34

[Brian Nesse (gone)]

As per discussion with beard. The code at issue here resides in the OJI module.
->OJI.

Comment 35

[Patrick C. Beard]

To follow up on comment 27, yes, there is a mismatch between the origin of the
Java code "http://www.geckonnection.com/testcases/applet/" and the origin of the
document "http://www.dhtmlplanet.com/testcases/applet/thirdparty.html". The
document thirdparty.html includes includes wrapper.js, which document.writes the
<APPLET> element. In order to make this work, we need to change the apparent
origin of the thirdparty.html so that a simple minded same origin test will
succeed. The problem is how to do this, because in a sense, we need to determine
"who's" asking, and return the URL of the codebase of the caller to
nsCSecurityContext::GetOrigin().

Comment 36

[Patrick C. Beard]

Here's a thought about how we can fix this. Every applet runs in its own class
loader, which is presumably a subclass of java.net.URLClassLoader. This class
has the method

protected void addURL(URL url);

which allows multiple URLs to be searched when looking for classes and
resources. Couldn't the OJI module add the URL of the including document to this
class loader's array of URLs? If so, then the plugin's security check for same
origin could be modified to use this array of URLs (if it doesn't already).

Comment 37

[Arun Ranganathan]

Is there something we can do that doesn't require a modification on the plugin
side?  Bugscape (internal) bug 19520 has this to say:

Assume that the Applet (and its source JAR file) and the script that
LiveConnects with the Applet reside on Domain A, and that Domain B is a domain
that merely links to the Applet and the JavaScript.

*On a per LiveConnect call basis* allow the JVM to think that the script lives
on Domain A.  Inclusion of the script via script src=" . " still means that the
script is now a citizen of Domain B, but for the purpose of making this "time
tested" LiveConnect call mechanism work, allow each individual LiveConnect call
to be a citizen of Domain A.

By "time tested" I really mean since the NN4.x days.  Note that IE also aloows
this kind of thing.

This is probably what Sun recommends.  Is this a feasibility?

Comment 38

[Rob Jaworski]

Based on discussions we had, we're focusing ideas with solutions targeted for
the mozilla code, without changes in java.
I'll let beard elaborate, will need input from jst, and reassign to mstoltz for
now per discussions.

Comment 39

[Jaime Rodriguez, Jr.]

Moving up to P1 per EDT triage. This effects topsites in Brazil and Germany.

Comment 40

[Susie Wyshak]

Please reassign this if need be so it can get fixed as it could block certain betas.

Comment 41

[Patty Mac]

change qa contact to Chris Petersen.

Comment 42

[Mitchell Stoltz (not reading bugmail)]

Clearing milestone for now.

Comment 43

[Samir Gehani]

adt: need info.  Need to know if this is a priority for Buffy.

Comment 44

[Andrew Milkowski]

Exception:

"sun.plugin.liveconnect.OriginNotAllowedException: JavaScript is not from the 
same origin as the Java code.."

is now also reproducable on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 
Netscape/7.1 (ax)

JDK: JRE version 1.4.2 Java HotSpot(TM)

Comment 45

[Brendan Eich [:brendan]]

Chris, can you weigh in on this?  Cc'ing Kyle too for his thoughts.

/be

Comment 46

[Kyle Yuan]

Tested with the following simple page, I found IE does not compare the caller & 
callee's origins at all.

<html>
<body>
<applet code="TestApplet" codebase="http://putt.prc/test" name="TestApplet" 
width=0 height=0>
</applet>
<input type=submit value="click to invoke java" 
onclick="document.TestApplet.onload()">
</body>
</html>

Comment 47

[Kyle Yuan]

http://books.mozdev.org/html/mozilla-chp-12-sect-7.html

Turning UniversalBrowserRead on might work around this issue, but I'm not sure.

Comment 48

[Xiaobin Lu]

Please refer to http://java.sun.com/j2se/1.3/docs/guide/plugin/security.html for 
liveconnect security. The two conditions are:
* The origin (URL) of the page is the same as the origin of the applet; 
* JavaScript is signed and UniversalBrowserRead permission is enabled for 
JavaScript. 

Comment 49

[Xiaobin Lu]

Please refer to http://java.sun.com/j2se/1.3/docs/guide/plugin/security.html for 
liveconnect security. The two conditions are:
* The origin (URL) of the page is the same as the origin of the applet; 
* JavaScript is signed and UniversalBrowserRead permission is enabled for 
JavaScript. 

Comment 50

[David C Peterson]

(In reply to comment #49)
> Please refer to http://java.sun.com/j2se/1.3/docs/guide/plugin/security.html 
for 
> liveconnect security. The two conditions are:
> * The origin (URL) of the page is the same as the origin of the applet; 
> * JavaScript is signed and UniversalBrowserRead permission is enabled for 
> JavaScript. 


This document is out of date or just plain incorrect.  Read the comment above 
the lines that you cut out where it says:
"Since an applet is allowed to connect to any host, it might then send such 
information out over the network in an irresponsible manner. A security policy 
has been implemented to prevent such actions from occurring."

Applets can only phone home. They cannot connect to any host.  Sun needs to 
clean up their documentation. There isn't any security hole here.  If there 
was, it would have been exploited years ago because the legacy jvms from MS 
and Netscape along with the browsers have all allowed this behavior from day 
1.  Complex problems can seldom be solved with a single technology.  In 
Unicast's case, we provide our customers with a java & javascript solution to 
get the job done.  I cannot understand how anybody could rationally say that 
us providing a jar & javascript solution somehow relagates the 2 files to 
different domains.  They're our files.  They're on our servers.

Engineers should only be closing real security holes and not closing off lines 
of business that companies have been built upon.  Many company businesses 
depends upon this behavior, not just our's.  Having some random engineer 
somewhere dreaming up security holes based upon false assumptions is just 
plain wrong.  Applets are not allowed to contact other websites than their own 
home domain.  Why on earth is Sun trying to force Javascript to be signed in 
this instance? Firstly as I said, I think this documentation is wrong and that 
it's not implemented this way and secondly, there isn't a security hole here.

This bug is now celebrating it's 2 year anniversary.  Can't we just fix it and 
stop discussing non-existant security holes please?

Comment 51

[David C Peterson]

(In reply to comment #50)
> (In reply to comment #49)
> > Please refer to 
http://java.sun.com/j2se/1.3/docs/guide/plugin/security.html 
> for 
> > liveconnect security. The two conditions are:
> > * The origin (URL) of the page is the same as the origin of the applet; 
> > * JavaScript is signed and UniversalBrowserRead permission is enabled for 
> > JavaScript. 

Sorry, I misread the above posting a bit.  Those conditions are 'or'ed.  If 
either condition is met then liveconnect should be allowed.  So this 
liveconnect call should be allowed even by Sun's standards. :)

Comment 52

[Kyle Yuan]

(In reply to comment #50)
> Applets can only phone home. They cannot connect to any host. 
No, signed applets can phone *everywhere*.
 
> They're our files.  They're on our servers.
If they are on your servers, why do they come from the different domain? Mozilla
can deal with with home.a.com and mail.a.com, but you can't expect mozilla will
think home.a.com & home.b.com are from one organization.
 

Comment 53

[David C Peterson]

I think you've misread the defect.  They do NOT come from a different 
domains.  They come from exactly the SAME domain.  We just license the 2 
pieces of our technology to websites around the world.  They deploy it on 
their pages.  Somehow you're assuming that the mere fact that we license it to 
them makes it their technology.  It isn't.  They're merely including our 
technology on their html pages.  The src of the javascript and the codebase of 
the jar are both pointing to our domains.  

The wrapper.js file comes from a <script src=http://home.a.com></script>.  The 
jar file has codebase=http://home.a.com.  They're on our servers. They are 
both our files.  They are the same domain.  
Now we license this technology to sites which of course are not a.com.  The 
site puts a 'tag' on their page which includes the script src shown above.  
The wrapper.js file then dynamically writes in the the <applet> tag which 
again is pointing (i.e. codebase) to home.a.com (i.e. our server!).  However, 
we've licensed our technolgy to a website called home.b.com.  That doesn't 
mean that the script is 'owned' by b.com.  It's still coming from a.com.  
b.com pays us a fee for using our technology.  These files are on our servers, 
not on their servers.  Their servers merely contain a 'reference' to our 
files!  There is a difference!  They're just pulling the javascript file from 
our server.  The javascript then pulls the jar file (i.e. by writing the 
applet tag into their page)once again from our server (i.e. codebase is the 
same domain as the script src). Why is Sun not allowing 2 files from our 
server to talk to each other????? The mere fact that we licensed the 2 files 
to a website doesn't mean that it is their technology.  It is ours.  Let our 
files talk to each other.  Why is this so hard to understand?
The .jar file and the .js file both come from our servers.  They are both just 
referenced from another site's html.  Is this clear now?  If it's not, please, 
let's talk on the phone or something.  This is a crucial distinction.  Email 
me with your contact information and we can talk directly.

Comment 54

[David C Peterson]

Hey listen, I don't think the problem is with Sun. It appears (at least to me) 
to be a netscape issue.  We don't experience this issue with any browser other 
than netscape 6/7/mozilla.  This appears to be (from an outsider's standpoint) 
a problem with netscape getting too carried away with security.  I guess I'm 
getting frustrated that this problem is still unresolved after 2 years now.  
thanks everyone!  I hope we're getting closer to finally resolving this. :)

Comment 55

[Kyle Yuan]

Okay, please calm down. I'm sorry that I've misread this bug. By reading the
comment 0 more carefully, I understand what it complains is that a webpage from
b.com refer to a js file from a.com like: <script src="http://a.com/foo.js">.
But the origin of foo.js is b.com instead of a.com which is expected by
everybody. (Maybe we should make the summary more clear.)

Obviously, how to determine the js's origin is nothing related to Java. Please
don't blame Sun at this point.

Comment 56

[Scott Morris]

(In reply to comment #54)
> Hey listen, I don't think the problem is with Sun. It appears (at least to me) 
> to be a netscape issue.  We don't experience this issue with any browser other 
> than netscape 6/7/mozilla.  This appears to be (from an outsider's standpoint) 
> a problem with netscape getting too carried away with security.  I guess I'm 
> getting frustrated that this problem is still unresolved after 2 years now.  
> thanks everyone!  I hope we're getting closer to finally resolving this. :)
> 
> 
I have to agree that it is definitely a browser issue and not the plugin, but it
goes beyond home.a.com vs. home.b.com. In our situation, if the host name s are
different but on the same domain (such as caller=home.a.com and
callee=home20.a.com), the error persists.

Comment 57

[clemens utschig]

(In reply to comment #56)
I have to agree that it is definitely a browser issue and not the plugin, but it
goes beyond home.a.com vs. home.b.com. In our situation, if the host name s are
different but on the same domain (such as caller=home.a.com and
callee=home20.a.com), the error persists.

-> something to add on scott's commnent here .. the problem is reproducable, 
even on the same computer (same host, same domain), but when using different 
ports.

Comment 58

[timeless]

re comment 22 and all following comments which are confused:

in web browsers scripts are tied to the html document that owns them. otherwise
i could import a script from http://payroll.internal/basic.js and call a
function on it to change your mailing address to mine.

the protection is not between js files, it's between frames/windows. a window
from www.a.com generally can't access a window from www.b.com, even if www.a.com
stole code from www.b.com.

Comment 59

[Roger Feese]

(In reply to comment #58)
> in web browsers scripts are tied to the html document that owns them. 

I hate to say it but he's absolutely correct. Elements on the HTML
page are able to call JavaScript functions from the included .js
file no matter where it comes from. It stands to reason that 
JavaScript to Java communications would be restricted in this 
situation. The fact that this currently works in other browsers
just means that those other browsers have flawed security models
and it is something that they will probably eventually "fix".
There are probably going to be a lot of web "applications" that
break when this happens.

Comment 60

[Brendan Eich [:brendan]]

I agree with the last two comments, but then I had a lot to do with the security
model for JS, include <script src=...>.

But this bug is 4xp -- what specifically doesn't work in Mozilla, that did work
in Netscape 4.x?  It should never have been the case in 4.x that nesting <script
src=bar.com/baz.js> in foo.com/blargh.html gives foo.com the ability to run code
as if it were bar.com.

/be

Comment 61

[David C Peterson]

I disagree.  This is not a flawed security model.  This is just the way that 
the Internet works.  People share innovations that other people develop.  In 
order to develop powerful products over trivial 'spinning globes', companies 
have to combine the power of Java, JavaScript, Active-X, DHTML, etc.
The fact that my company has licensed our technology to a website to deploy on 
their websites means that a) there is mutual trust between the parties and 
very likely contractual relationships ensuring protections where needed  and 
b) that if I think that there is a risk that the website that I've license the 
technology to could potentially do harm to my technology, it is my 
responsibility to build in protection into my code.
There is NOT any possibility of doing harm to the user. Only possibility of a 
rogue website doing harm to my technology by calling my javascript functions 
in inappropriate ways that my company would not want them to do.  We have 
built in protections for that and we of course have restrictions that rogue 
websites cannot just paste an <script src> of our technology on our website 
and have them use it (i.e. steal our technology).
There is no user level security danger here.  Only possible danger is between 
the website and the technology vendor.  I don't think that it is the 
responsibility of the web browser to restrict commercialization opportunities 
on the Internet over faulty thoughts on security protections.
Hope that clears it up.

Comment 62

[Alex Lambert]

(In reply to comment #61)

Hi folks,

My site is also experiencing problems due to this issue. I'd like to explain
what precisely we're doing so there's a clear idea of what should and should not
break.

I run a free Internet chat service. To add our chat room applet to a page, users
insert something like the following into their page:

<script src="http://ourserver/jsgen.cgi"></script>
<script>
// set various options here
go(options_array);
</script>

The script then uses document.write to insert the applet onto the page. This
works very well.

The problem is that our applet has a few public JS methods. Mozilla will not
allow the user's page to work with the applet via JavaScript (e.g. telling it to
detatch from the page, etc). This works without any problems on IE.


Thanks for your time, all. I hope this provides a scenario where the page has a
legitimate need to work with the applet.

Comment 63

[Brett Law]

Why is the security model between included javascript files and included 
applets different? With javascript files, they essentially become part of the 
page. By this, I mean the page can call any methods and/or use any data on the 
included javascript file regardless of origin.

With an applet, why would the same not apply? If I decide as the web page 
creator to include an applet on my page, why can I not "talk" to that applet? 
It's not like I can force my applet onto your page. And just because my applet 
is on the page doesn't mean it can talk to your server. 

The applet can only talk back to the server it came from... that makes total 
sense. But for the web page to not be able to talk to an applet it has 
included doesn't. Apparently browser makers prior to NS/Mozilla 6.x,7.x 
understood this. Applets become much less useful if all they can do is be 
viewed and not interacted with by the web page. This issue is preventing our 
software from being used by several clients on the latest versions of Netscape 
and Mozilla, and we thus have to live with NS 4.x for that much longer. If we 
can finally put this bug to rest, maybe NS 4.x can be put to rest as well. (I 
can't imagine anyone would object to that.)

Comment 64

[Roger Feese]

(In reply to comment #63)
> Why is the security model between included javascript files and included 
> applets different? With javascript files, they essentially become part of the 
> page. By this, I mean the page can call any methods and/or use any data on the 
> included javascript file regardless of origin.

I actually question why this is even allowed. However, there are limits
to what JavaScript can do so it isn't as much of a problem.

> With an applet, why would the same not apply? If I decide as the web page 
> creator to include an applet on my page, why can I not "talk" to that applet? 
> It's not like I can force my applet onto your page. And just because my applet 
> is on the page doesn't mean it can talk to your server. 

If you are creating the web page, why can the applet not exist on your
web server as well. I realize this breaks the way your system works. My
point is that the way we are building these systems is flawed and I
don't think it even follows what Sun recommends.

> The applet can only talk back to the server it came from... that makes total 
> sense. But for the web page to not be able to talk to an applet it has 
> included doesn't. Apparently browser makers prior to NS/Mozilla 6.x,7.x 
> understood this. Applets become much less useful if all they can do is be 
> viewed and not interacted with by the web page. This issue is preventing our 
[...]

What if someone unethical makes a page that includes your applet and
causes it to do evil things. What recourse would you have? What if this
is crafted into the next email trojan that goes around? What if your 
applet handled monetary transactions? To me, this is similar to a lot
of the other web browser security problems we've seen lately...It's
just waiting to be exploited somehow if it hasn't been already.

I don't think this argument should even be happening. Someone should be
able to point to an authoritative source and describe the proper behavior.
Just because things used to work a certain way does not mean it was
correct. Can someone get Sun's official position on this? This is something
that the entire community of Web developers needs to have addressed.

Comment 65

[Brendan Eich [:brendan]]

>> page. By this, I mean the page can call any methods and/or use any data on
>> the included javascript file regardless of origin.
>
> I actually question why this is even allowed.

What's the point of questioning it?  It has been supported since Netscape 3.0. 
It's also useful for sharing common scripts; there is no point in allowing
foo.com to include script from bar.org if it can't use it (i.e., call its
functions, get and set its variables).

Finer grained control may be wanted, and was provided in the past via export and
import (not standardized via ECMA, now removed from SpiderMonkey).  But saying
you want finer control is not the same as questioning why it's allowed to use
another domain's scripts.

Are you concerned about "stealing"?  If bar.org puts useful script in a .js file
served with the right MIME type to the world, why shouldn't foo.com use it, if
it is deemed safe and useful?  Of course, usually the sharing is more intimate
in the DNS: scripts.yahoo.com and my.yahoo.com, e.g. (made-up example based on
real ones).

> However, there are limits
> to what JavaScript can do so it isn't as much of a problem.

What would the problem be if JS could do more?  Are you concerned that foo.com
is using bar.org's scripts without studying them for Trojans, etc.?  _Caveat
emptor_ applies to any public content on the web.  In practice, people use
scripts in .js files of their own, or bought from a DHTML library vendor, or
used freely from an open source project (e.g., jslib.mozdev.org) whose
reputation is good.

In any of these cases, where the shared scripts are deployed relative to
including pages is independent in general from who wrote or purveyed them, and
independent from the domains of the including pages.

> If you are creating the web page, why can the applet not exist on your
> web server as well. 

Why *must* the applet be copied to the same server as the page (which seems to
be what you propose -- not *may* but must)?  What are you trying to achieve by
that, other than forcing people to make lots of gratuitous copies, creating more
maintenance work and hazards, and taking up more disk space?

Sun may be the authority on Java, but web page object or applet embedding and
the security models used by browsers are the provenance of the w3c.

Alas, I do not believe that the w3c has ever specified the _de facto_ standard
here.  But there *are* _de facto_ standards, and every browser vendor has to
implement them.  Don't be so quick to dismiss "what was done in the past";
compatibility with what actually worked, and what is still deployed, matters to
a lot of businesses who have sunk costs here.

This bug is not the place to debate "what if" and "might have been", or "I would
have done it differently."  This bug is a 4xp compatibility bug (also an IE and
no doubt a Safari bug once its LiveConnect support ships bug).  We should fix it
without lots of digressive comments.

/be

Comment 66

[Roger Feese]

(In reply to comment #65)
> What would the problem be if JS could do more?  Are you concerned that foo.com
> is using bar.org's scripts without studying them for Trojans, etc.?  _Caveat
> emptor_ applies to any public content on the web.  In practice, people use
> scripts in .js files of their own, or bought from a DHTML library vendor, or
> used freely from an open source project (e.g., jslib.mozdev.org) whose
> reputation is good.

I'm talking about protecting the people browsing web sites, not the
developers. How does "Caveat emptor" apply to me when I am clicking
on a link to a site I have never seen before? There have been many
problems with "cross-site scripting" lately. "Pop-up blocking" in
Mozilla is a response to one unanticipated missuse of JavaScript.
I have to assume there may be somebody reading this that has built 
their business based on JavaScript pop-ups advertising...

> Sun may be the authority on Java, but web page object or applet embedding and
> the security models used by browsers are the provenance of the w3c.
> 
> Alas, I do not believe that the w3c has ever specified the _de facto_ standard
> here.  But there *are* _de facto_ standards, and every browser vendor has to
> implement them.  Don't be so quick to dismiss "what was done in the past";
> compatibility with what actually worked, and what is still deployed, matters
> to a lot of businesses who have sunk costs here.

I only suggest that we try to do it the "right" way. If there is nothing
authoritative that describes the proper functionality, then who is to say
that it cannot be written now? In any case I think that the answer should
come from someone like the W3C.

Comment 67

[Brendan Eich [:brendan]]

Roger, take it to a newsgroup, you are spamming this bug.  Cross-site scripting
holes in other browsers, and pop-up window abuse, have *nothing* to do with this
bug (and seeking an authority to worship at the expense of _de facto_ standards
actually implemented by most browsers is a fallacy).  You're abusing your
bugzilla privileges; please stop.

/be

Comment 68

[Brendan Eich [:brendan]]

As far as I can tell from searching my memory and reading MozillaClassic code
via http://lxr.mozilla.org/classic/, the 4.x codebase would not associate
transcluded scripts with their source domain when computing principals -- they
are run as if they came from their including script's domain.

E.g., http://a.com/ uses a <script src="b.com/c.js"> tag -- the script in c.js
runs as if it came from a.com.

That says that in 4.x, there was no check done by the Java plugin; or that such
a check used some other means, such as that proposed by beard in comment 36, to
allow the access.  Can someone from Sun say which it was?  It would help to know
what the motivation was for changing things from the way they worked in 4.x.

/be

Comment 69

[Nigel McFarlane]

For the non-cross-frame case at issue:
http://developer.netscape.com/docs/manuals/communicator/jssec/index.html

may be relevant for 4.x. My brain understood this once. Isn't 4.x signed script
security a matter of JAR files holding permissions? No jar file, no codebase
permission. For permission, do this:

<script id="foo" archive="http://any.com/perms.jar" src="in_the_archive/foo.js" />

Don't compare src= URLs, compare archive= permissions. The URL of the script is
irrelevant, only permissions matter. id= is/was required to name the signed code
so that it could be tracked for codebase-principle checks. Therefore, in 4.x,
with no id, no permission is granted, even if a JAR file is supplied correctly
with archive=. With all those things missing, permission denied is/was certainly
the case.

When permission was GRANTED, further nastiness assured that NAMED COLLECTIONS of
scripts on a given page had shared access to each other. Such collections were
mutually exclusive.

- N. (sole living possessor of "Instant JavaScript" ;-).

Comment 70

[Kyle Yuan]

re comment 68,

The origin-check was introduced by bug 45692. A new method - GetOrigin was added
in nsCSecurityContext, see
http://lxr.mozilla.org/seamonkey/source/modules/oji/src/nsCSecurityContext.cpp#116
Java plugin is relying on this method to compare the origins.

now the problem becomes: what is an applet's origin?

Use the same example Brendan just gave, http://a.com uses 
<applet codebase="http://b.com" code="test">. I personally agree to use
http://a.com as the origin of the applet instead of http://b.com which is
currently used in java plugin. 

I'm wondering what is the standards of the js/applet origin's definition?

Comment 71

[Brett Law]

In my opinion, the applet's origin must be taken in context. When talking back 
to the origin that it came from (i.e. what servers it can open a connection 
to), it is being done correctly now. If the codebase of the applet is b.com, 
then that is its origin. That is the only SERVER it should be allowed to talk 
to. Any SERVER other than the one that served it could be a security concern. 

Where there is an issue is on the CLIENT side. If I as a web page creator 
include an applet on my page, I should be able to talk to it on the CLIENT no 
matter what the origin. Just as a javascript include can come from any origin 
and still be usable, an applet should be as well. If I can't talk to the 
applet on the client side, then what is the point of even including it? We are 
then limiting the usefulness of applets to only things that can be fully self 
contained in the applet (spinning globes, etc). 

I guess its a matter of how you see applets. If you see them as nothing more 
than fancy images and eye candy, then not being allowed to talk to them is 
fine. If you see them as business objects that can provide services across 
vendors (or even services within a single vendor in a highly scalable 
environment where load balancing and sound application design cause different 
services to come from different physical machines), then this bug is a glaring 
issue that prevents integration with third parties and/or creation of highly 
scalable systems.

If the decision is that the former should hold, then that makes Mozilla and 
NS6/7 only useful to the eye candy folks, and not useful in a business 
environment. Unfortunately, that would leave businesses with the far more 
buggy NS4.x as the only viable alternative to Internet Explorer.

Comment 72

[Erin]

This bug prevents us from certifying one of our products at Oracle on Netscape
7/Mozilla/Firefox. If new security restrictions are added, there should be a way
to disable them so that Netscape is backward compatible.  We would like to move
users from Netscape 4.x but cannot because of this issue.  If you would like
more details, please feel free to contact me.  

I would also like an update on when this bug will be resolved. Thank you.

Comment 73

[Brendan Eich [:brendan]]

Re: comment 69 -- this 4xp bug has nothing to do with signed scripts.

Re: comment 70 -- so Jeff Dyer implemented "LiveConnect security" in a way
that's incompatible with 4.x.  That seems like a bug.  My name was invoked in
that bug (bug 45692 comment 12, "In response to brendan's comments"), but I
don't see my comments.  Anyway, that was a long time ago -- it's hard to justify
the way the code works, and doesn't work, based on that bug.

We should fix this 4xp bug.  I'll propose a patch today.

Re: comment 72 -- please cc: yourself on bugs for which you wish to receive mail
notifications.  You can adjust your preferences in bugzilla to limit how much
mail you receive.  I've cc'd you on this bug.

/be

Comment 74

[Brendan Eich [:brendan]]

If our security model protects applets in pages (whether included directly, or
indirectly via <script src=>/document.write) loaded from foo.com from being
accessed by script from evil.org, then I do not see why we need any check of the
kind Jeff Dyer added to LiveConnect several years ago.  That check is redundant
in the case of a malicious script, and its only other effect is to cause this bug.

I think we should turn off the same-origin test that is throwing the exception
reported here.

Proof: if we need that check, then an applet is being accessed in violation of
the same-origin checks done to protect all content in windows loaded from
foo.com from access by scripts from evil.org.  If we have a hole there, it's so
wide that lots of things (form data, link state) are compromised.  We test and
fix security bugs, and no such bug is known.

/be

Comment 75

[Kyle Yuan]

> We should fix this 4xp bug.  I'll propose a patch today.

Brendan, currently, we check the same origin both in mozilla and in java-plugin
code. callee has the responsibility to check it. So we must fix it in both side. 

I'm discussing this issue with JPI team. Hope we can find out an acceptable
solution soon.(In reply to comment #73)

Comment 76

[Brendan Eich [:brendan]]

> Brendan, currently, we check the same origin both in mozilla and in java-plugin
> code. callee has the responsibility to check it. So we must fix it in both side.

Why must the callee check?  Distrust of the DOM security code in the caller? 
That may be valid as a defense in depth step ("belt and braces/suspenders"), but
the callee must then arrange for backward compatibility, i.e., this bug should
be fixed by having the DOM code (somehow) inform the LiveConnect code that the
applet is being used as an extension to foo.com script, not called directly as
if it came from its home on applet.net.

/be

Comment 77

[Kyle Yuan]

Changing summary and category. Hopefully we can make some progress in 1.7 final.

Comment 78

[Brendan Eich [:brendan]]

1.7b freezes Tuesday at midnight PST, but any fix here that we want for 1.7final
should be in hand soon, so marking blocking1.7b+.  Kyle, please update this bug
with status as soon as you can.  Thanks,

/be

Comment 79

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch

Let's try this.

Comment 80

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 143675 [details] [diff] [review]
Patch

Thoughts?

Comment 81

[Johnny Stenback (:jst)]

Comment on attachment 143675 [details] [diff] [review]
Patch

- In AutoPushJSContext::AutoPushJSContext():

-    if (aSecuritySupports)
-	 mPushResult = CreatePrincipal(aSecuritySupports, secMan,
getter_AddRefs(principal));

Those two references to aSecuritySupports were the only ones, the argument
could now be removed completely from AutoPushJSContext's ctor. Though we might
want to do that after 1.7b.

- In get_JSPrincipals_from_java_caller_impl():

+    nsCOMPtr<nsIScriptSecurityManager>
secMan(do_GetService(NS_SCRIPTSECURITYMANAGER_CONTRACTID, &rv));

Seems like it might be worth caching the security manager in this module now...

That's what I got so far, need more time to think about the rest...

Comment 82

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch v2

Fixed whitespace issues, did some really minor cleanup, and added a comment to
nsCSecurityContext::Implies() which should better explain what is going on.

Johnny, yeah I agree with you but let's wait to do those until alpha -- the
security manager could be cached for lots more places than where you noted and
it would make sense to just batch them up into one patch rather do it halfway
here; touching more codepaths than we need to in order to fix this bug.

Comment 83

[Brendan Eich [:brendan]]

Comment on attachment 143684 [details] [diff] [review]
Patch v2

sr=me, contingent on jst's review of course.

Thanks for doing this.

/be

Comment 84

[Johnny Stenback (:jst)]

Comment on attachment 143684 [details] [diff] [review]
Patch v2

Yeah, we can do the cleanup later.

r=jst

Comment 85

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 143684 [details] [diff] [review]
Patch v2

Requesting approval: this improves our support for Java applets, by cleaning
out some old and crusted code, and it would be great to get some testing
coverage in beta.

Comment 86

[Christopher Aillon (sabbatical, not receiving bugmail)]

Fix checked in 03/13/2004 12:52.

Comment 87

[Brendan Eich [:brendan]]

Need a followup bug for the long-term fix?

/be

Comment 88

[Christopher Aillon (sabbatical, not receiving bugmail)]

Filed bug 237385 for that.

Comment 89

[Kyle Yuan]

*** Bug 94474 has been marked as a duplicate of this bug. ***

Comment 90

[Olivier Cahagne]

*** Bug 238015 has been marked as a duplicate of this bug. ***

Comment 91

[John Busfield]

I just downloaded Mozilla 1.7b to check this bug fix. The 
OriginNotAllowedException no longer occurs. However there is now a new security 
exception for applets that open sockets back to the server from which they 
came. 
java.security.AccessControlException: access denied (java.net.SocketPermission 
live01.mediaplatform.com resolve)

The setup under which this occurs is:
1. The html page comes from a.com. 
2. The page embeds an applet from b.com. 
3. The applet tries to open a socket back to b.com, to the exact server that 
served the applet. 
4. The above security exception occurs.

Here is a test link that shows the error 
http://musedev.ivtweb.com/Test/appletfail.htm

Notice that the applet's codebase is live01.mediaplatform.com and it tries to 
open a socket back to live01.mediaplatform.com. This should be an allowed 
behavior of an applet regardless of the url of the page in which the applet 
exists. This page works correctly in both IE and Netscape 4.x.

Comment 92

[Kyle Yuan]

Could you modify the applet's codebase from http://live01.mediaplatform.com/v203
to http://live01.mediaplatform.com and try again?

Comment 93

[John Busfield]

(In reply to comment #92)
> Could you modify the applet's codebase from 
http://live01.mediaplatform.com/v203
> to http://live01.mediaplatform.com and try again?

That same page's applet now has a codebase of http://live01.mediaplatform.com. 
It is still failing. I also tested putting the html page on a server in the 
same domain (although not on the same server). The error still occurred.

Comment 94

[Brendan Eich [:brendan]]

comment 91 through comment 93 belong in a different bug, please.

/be

Comment 95

[Daniel Veditz [:dveditz]]

Why a different bug? The new symptoms are the flip side of this same problem,
our internal requirement that the page and applet be in the same domain. Now
a.com can talk to the b.com applet but it still can't *use* it (assume
non-trivial applet, otherwise it could just be copied to a.com) since the applet
no longer knows its true home.

Unless maybe they should go into the "remove hack" bug 237385 mentioned in
comment 88

Comment 96

[Kyle Yuan]

re comment 95, I'm pretty sure this is a applet or java plugin bug, rather than
a mozilla bug. And bug 237385 can't help on this too.

re comment 93, could you use appletviewer to access the same page? If it is
still failing, the problem should not belong to neither mozilla nor java plugin.
If you send the simplified applet source code or post it in n.p.m.java, I can
help you to find out where the problem is.

Comment 97

[Erin]

I downloaded 1.7b and I am also getting this new Security exception. 

  java.security.AccessControlException: access denied 
(java.net.SocketPermission ilearningstage.oracle.com resolve)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1042)
at sun.plugin.net.protocol.http.HttpURLConnection.checkPermission
(HttpURLConnection.java:193)
at sun.plugin.net.protocol.http.HttpURLConnection.connect
(HttpURLConnection.java:144)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
(HttpURLConnection.java:516)

Comment 98

[John Busfield]

(In reply to comment #96)
The applet is not the problem. This applet is confirmed to work in both IE and 
Netscape 4.7 and is currently used in our production environment.

I believe that this issue belongs under the same bug and not as a new bug 
because I believe the code that was modified to fix the 
OriginNotAllowedException created this bug. The reason I say this is that in 
previous Mozilla versions we had a workaround where, by setting DNS entries in 
our HOSTS files, we could trick the applet into working. This workaround was 
not a solution for our customers because we could not ask our customers to 
modify their HOSTS files, but it did clarify the problem for us internally. 
Also, in the previous Mozilla versions, when the HOSTS file was modified we 
were able to make the connection back to the server that served the applet.  In 
the 1.7b release however, this connection is no longer possible. So unless 
there was some other security code that was modified for this release, it seems 
that the most likely conclusion would be that the change made to fix this bug 
has caused new problems.

Comment 99

[Kyle Yuan]

This bug has already been closed. Please file another bug for this regression,
and a *simple* testcase is highly appreciated.

Comment 100

[Stig Nygaard]

I had hoped this would fix my problems with logging on to the Netbank of Danske
Bank (www.danskebank.dk / netbank.danskebank.dk), but with Mozilla 1.7b I get
simelar errors to those described in comment #91 and comment #97.

JavaScript Console:
-------------------
Error: uncaught exception: java.security.PrivilegedActionException:
java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException

Java Console:
-------------
java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)

	at sun.plugin.liveconnect.SecureInvocation.access$300(Unknown Source)

	at sun.plugin.liveconnect.SecureInvocation$CallMethodThread.run(Unknown Source)

Caused by: java.lang.reflect.InvocationTargetException

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

	at java.lang.reflect.Method.invoke(Unknown Source)

	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)

	... 6 more

Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission com.ms.sysdir read)

	at java.security.AccessControlContext.checkPermission(Unknown Source)

	at java.security.AccessController.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)

	at java.lang.System.getProperty(Unknown Source)

	at Utils.queryDefaultDrive(Utils.java:193)

	at CKeyPath.<init>(CKeyPath.java:26)

	at CDanskeSikkerCtrl.Init(CDanskeSikkerCtrl.java:347)

	at DanskeSikker.Init(DanskeSikker.java:296)

	... 11 more


I'm no Java expert and definetely no LiveConnect expert, but hope this
information is a little help anyway.

If this is problem is another bug now, which bug should I vote for?

Danske Bank is one of scandinavia largest banking concerns, including (among
others) BG Bank which use same netbank system.

Comment 101

[Erin]

I created a new bug for the new issue.  I included the related comments from 
this bug.  Please see bug 240323.

Comment 102

[iha]

I work for a software company and this bug is limiting browser support issues
for our financial quote application (popup w/ applets).  Until this bug is fixed
we can not say our app supports Netscape/Mozilla browsing.

This is not a plugin problem.  Our app runs fine on IE under Sun's VM.  Things
go awry when we try to launch the app in Netscape 7.x and Mozilla.  

Our situation: our html pages reset their document.domain values in order to
talk with pages on a different server but with the same domain (pages from
a.b.com and c.b.com reset to b.com).  Unfortunately, the resetting prevents the
pages from talking with our applets, even though our applets originate from the
same server! (Callee (b.com reset from a.b.com) + caller (a.b.com, applet) =
exception.)      

To fix this bug, it seems the browser should compare domain origins not on
easily changeable values (like document.domain) but from immutable facts like if
the JS and JAR files come from the same server (a.b.com and a.b.com), they
should be able to talk, even if document.domain is truncated to its suffix.

Hope this helps and good luck.

Ian

Comment 103

[Jack Lu]

The fix of the bug allows the applet to call javascript with different domain
name by undo the same origin check in the browser side. So the fix should works
find with the problem mentioned in the above comment #102. 

Javascript calls Java with different origin will have problem since Java Plug-in
still verify whether they came from the same origin or not. Due to this,
Javascript could be signed with UniversalBrowserRead permission to avoid the
same origin check in plug-in side. 

The reason Sun's JVM works with IE is both browser side and Plug-in side does
not do same origin check since there is some technical difficulty to do this (as
I heard from IE plug-in guy).

Comment 104

[MEDIASHAREiQ.com]

I.E , Mozilla, Firefox

Thanks
MEDIASHAREiQ Team
https://www.mediashareiq.com/