JDK-6676256 : Java Plug-In does not obey crossdomain.xml file directives
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-17
  • Updated: 2011-05-13
  • Resolved: 2008-06-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b22Fixed
###@###.### points out that Java Web Start and the Java Plug-In do not obey the crossdomain.xml directives that have emerged as a new standard for allowing certain web services to be accessed from unsigned code:

"Currently unsigned applications and applets cannot access any resources outside of the domain they were loaded from.  This is great for security but makes certain types of applications difficult or impossible to write, such as mashups with the many cool webservices available from Google, Yahoo, etc.   All of our competitors (Flash, Silverlight, and AJAX) have support for this.  They handle it in one of two ways:

* Hijack the remote code loading mechanism to provide data. AJAX does this with JSON, which is a form of Javascript. This works because javascript can load additional javascript remotely but cannot load XML or other data files. Encoding data as Javascript hashtables works around this security limitation.  This is not feasible for Java since it would require on the fly compilation on the server and some nasty class loader tricks.

* Allow safe access to webservices using the crossdomain.xml files.  This is what Flash and Silverlight do.  In brief, if the client app requests a webservice on another domain the Flash environment will first check for some magic xml files on that domain to see if cross site access to particular resources is allowed.  If the webservice doesn't allow it then the request is denied.  This is what Java should support.

Silverlight 1 did not have support for cross domain scripting, but in Silverlight 2, they have decided to just reuse the crossdomain.xml system from Flash rather than reinventing the wheel. We should do the same since it would allow usnigned Java applications and applets to access existing webservices safely without requiring those webservices to be modified in any way.

General info on cross domain xml files:

Adobe's docs on cross domain xml files.

Microsoft's docs on cross domain xml files
    http://msdn2.microsoft.com/en-us/library/cc197955(VS.95).aspx "
Fixing this will also fix some longstanding problems with the National Weather Service applets:


because these applets attempt to contact http://www.weather.gov/ , which has a crossdomain.xml file.

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6676256.1 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6676256/

EVALUATION Adobe's Flash and now Microsoft's Silverlight use a mechanism called "cross-domain XML" to allow code to access web services. The server provides a file named "/crossdomain.xml" with something like the following contents: <?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy> which advertises to clients that they are allowed to connect to it. Java does not currently pay attention to the presence of these policy files. This prevents unsigned Java code from accessing existing web services that are available to competing technologies. Added support to the security managers used by Java Web Start and the Java Plug-In to handle the most basic form of the above file. Only if the file advertises access from all domains is access granted to it. It was necessary to record all of the IP addresses associated with the server and implicitly grant access to them due to how the permission checks are done at various points in the Java SE networking stack. It turns out that the NOAA weather applets, which have been failing with a SecurityException for some time, suddenly start working with this fix since the alternate host from which they previously incorrectly downloaded images, www.weather.gov, has a root crossdomain.xml file granting access. Note that this change is under review from ###@###.### of the security team, and some changes might be needed in follow-on bugs based on his review comments. However, in general there seems to be no objection to enabling this functionality.