JDK-7095980 : Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-09-28
  • Updated: 2014-06-11
  • Resolved: 2012-08-21
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 7 JDK 8
7u4Fixed 8 b19Fixed
Related Reports
Duplicate :  
JDK-8014034 - Certain Set-Cookie lines in headers appear as null in recent versions of 1.7.0
Relates :  
JDK-7128648 - HttpURLConnection.getHeaderFields should return an unmodifiable Map
Relates :  
JDK-7077220 - Plugin CookieHandler ignores HttpOnly cookies
Relates :  
JDK-8036017 - Set-Cookie response header is read as empty after setting CookieManager
Description
Once CR 7077220 is fixed the Plugin CookieHandler may be able to retrieve HttpOnly cookies from the browsers cookie store. This CR is concerned with ensuring HttpOnly cookies are not accessible to application code ( trusted or untrusted ). 

HttpOnly cookies should only be accessible to the HTTP client implementation, so that they can be used in HTTP requests, and NOT anywhere else.
Comments
EVALUATION The changes use the internal/private java.net.HttpCookie parsing implementation to filter out HttpOnly cookies from the Set-Cookie and Set-Cookie2 headers returned in the HTTP protocol handler. With this change the HTTP protocol suitably protects HttpOnly cookies. http://cr.openjdk.java.net/~chegar/7095980/webrev.00/webrev/ It reuses the internal java.net.HttpCookie parsing implementation rather than trying to maintain two separate parsing implementations. This is a little ugly since it is private and in the public java.net namespace, but I believe a shared secret is the best approach here. Changeset: 33ac7a057b9c Author: chegar Date: 2011-12-16 16:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33ac7a057b9c 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java + src/share/classes/sun/misc/JavaNetHttpCookieAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpOnly.java
16-12-2011
EVALUATION Since the integration of CR 6980004, any cookies automitically retrieved from the default CookieHandler (for Java Plugin/Applet, the Plugin CookieHandler) will not be exposed to user code (either trusted or untrusted) through the URLConnection.getRequestProperty/getRequestProperties API. This ensures that all cookies, including HttpOnly, are protected. Now what about Set-Cookie headers including HttpOnly, are they accessible through URLConnection.getHeaderField(s)?
29-09-2011