JDK-7102914 : REGRESSION: secure cookies is always dropped if network connection is triggered via liveconnect
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u29,7
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2011-10-19
  • Updated: 2013-09-12
  • Resolved: 2011-10-25
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.
JDK 6 JDK 7 JDK 8
6u30Fixed 7u2 b10Fixed 8Fixed
Related Reports
Duplicate :  
JDK-7150041 - uspto patent filing applet incompatible with java versions 6u29 and 7
Description
J2SE Version (please include all output from java -version flag):
6u29

Does this problem occur on J2SE 1.5.x or 6ux?  Yes / No (pick one)
No, works fine on 6u29 build03
 and all previous releases

Bug Description:

Our application consists of an applet and servlets that 
communicate with each other.

The browser loads the applet, and the applet contacts our servelts directly. 
These communications are now broken in the latest JRE release (1.6.0_29). 
Attached logs for the latest JRE and the prerelease u28
(before version name change) as well.

The only difference between the successful case and the failed case is the 
JRE being used, all other environmental factors are unchanged. That said, 
my test environment does not have a proxy or firewall enabled.

Our servlets require the session ID that was set in a previous communication, 
but it seems the JRE is restricting the cookies that are sent with applet 
initiated HTTPS connections to our servlets. Not sure why the restriction 
is happening, the applet is contacting the same site that it came from, 
so it should be trusted.

This is affecting all our customers that upgrade to JRE 1.6.0_29. 
They are unable to authenticate themselves in their organizations.

We are seeing the following errors, something about a 
SecureCokiePermission permission:


java.security.AccessControlException: access denied (com.sun.deploy.security.SecureCookiePermission origin.https://<someurl>)
another instance of this bug is related to use of MS remote proxy scripting:

https://forums.oracle.com/forums/thread.jspa?forumID=953&threadID=2300815
Comments
WORK AROUND sign the applet code and add doPriviledged block to the entry point of the Javascript->Java call to allow Java code to run with all-permissions when calling from Javascript. For more information on Java security model, sandbox applet and signed applets, and privileged block API. Below are some documentation link that explain these: http://download.oracle.com/javase/tutorial/deployment/applet/security.html http://download.oracle.com/javase/7/docs/technotes/guides/security/doprivileged.html http://www.oracle.com/technetwork/java/seccodeguide-139067.html#6-0 For the relationship between doPrivileged block, JavaScript and signed applet code: Code is granted permissions: a) if all code on the stack is coming from trusted sources (and creation of the thread was initiated from trusted context) (JavaScript is untrusted code; signed Java code is trusted) b) if code is trusted (signed) and explicitly calls doPrivileged to elevate permissions All calls from JavaScript to Java are treated as calls from untrusted code (in the same way if you call signed code from unsigned java code). That's why when calling from JavaScript to signed applet code, if you want the signed applet code to run with all-permissions, you need doPrivileged call in the applet code. This is because JavaScript is in the context of the call.
25-10-2011
EVALUATION The problem is the call is triggered by JavaScript in the web page, calling into Java code in their signed applet JAR. The call will trigger access to secure cookie. With the secure cookie fix in 6u29 - we introduce a check to make sure SecureCookiePermission is satisfied before allowing access to the cookie. In the 6u29 fix, we grant the SecureCookiePermission in our webstart/plugin classloader, and allow Java code to access secure cookie if it's originated from HTTPS and the same origin host. Problem is in this scenario - the call is originated from the JavaScript, not Java code. When we do a SecurityManager.checkPermission on it - it will eventually call into AccessControlContext.checkPermission, which will make sure all the ProtectionDomain in the current context has the permission. In this case, there is JSProtectionDomain in the context, and SecureCookiePermission is not there (JavaScript is not loaded by our classloader). That's why we throw the SecurityException and caused the problem. For us, the right fix is to also grant SecureCookiePermission in the JSProtectionDomain, and allow it to access cookie if JS/applet is originated from the same HTTPS host. For the customer, they can workaround it right now by adding doPrivileged block to the entry point of the js->java call. This will elevate the Java code to be run with all-permissions - since their code is signed and trusted.
21-10-2011