JDK-8190689 : Java incorrectly requires "HttpOnly" cookie attribute to be case sensitive
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 8u151,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2017-10-25
  • Updated: 2018-10-16
  • Resolved: 2018-04-17
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 8
8u181Fixed
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]


EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer version 11.0.9600.18617 

A DESCRIPTION OF THE PROBLEM :
I'm resubmitting JDK-8179393 because it was improperly closed despite me responding to the request for more information.  This is now resulting in a major business impact which has raised this issue to a very high priority.

The fix for JDK-7077220 allows Java Applets to read and use HttpOnly cookies when using Internet Explorer 11.

The problem is that it incorrectly forces a case-sensitive match when checking for the "HttpOnly" parameter in the Set-Cookie header. RFC 6265 states that the match should be case-insensitive.

https://tools.ietf.org/html/rfc6265#section-5.2.6

As such Java Applets can see this cookie:

Set-Cookie: test=test; HttpOnly

But cannot set this cookie:

Set-Cookie: test=test; HTTPOnly


This is causes an issue with CA's SiteMinder application which sends HttpOnly cookie's with "HTTPOnly", which works fine in browsers, but cannot be read by Java despite RFC 6265 stating that it should work. 

This problem requires running the applet in Internet Explorer, not the appletviewer as the applet uses IE's cookie management.  Switching to using the Java's cookie managerment is not an option because the login page is displayed outside of the applet.   I realize applets are going to be deprecated, but they are still currently being supported so this should still work.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run Test Java Applet in IE
2. Click Test button 

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected output (in the text box next to the "Test" button):

    put: {Set-Cookie=[FOO=BAR;HTTPOnly, ABC=XYZ]}
    got: {Cookie=[FOO=BAR, ABC=XYZ]} 
ACTUAL -
Actual output:

    put: {Set-Cookie=[FOO=BAR;HTTPOnly, ABC=XYZ]}
    got: {Cookie=[ABC=XYZ]} 

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This is the same code as from JDK-707220 with the only change being that the "HttpOnly" text was changed to "HTTPOnly":



public class CookieTest extends JApplet {

    private JTextArea textArea;

    @Override
    public void init() {
        try {
            SwingUtilities.invokeAndWait(new Runnable() {
                @Override public void run() {
                    setLayout(new BorderLayout());

                    JButton button = new JButton("Test");
                    button.addActionListener(new ActionListener() {
                        @Override public void actionPerformed(ActionEvent e) {
                            test();
                        }
                    });
                    add(button, BorderLayout.NORTH);

                    textArea = new JTextArea();
                    add(textArea, BorderLayout.CENTER);
                }
            });
        } catch (Exception e) {
            System.err.println("createGUI didn't complete successfully");
        }
    }

    private void test() {
        try {
            CookieHandler handler = CookieHandler.getDefault();

            URI uri = new URI("https://www.google.com/accounts/ServiceLogin");
            
            Map<String, List<String>> headers =
                    new HashMap<String, List<String>>();
            headers.put("Set-Cookie", Arrays.asList(
                    "FOO=BAR;HTTPOnly","ABC=XYZ"));
            
            handler.put(uri, headers);
            textArea.append("put: " + headers + "\n");

            headers = handler.get(uri, new HashMap<String, List<String>>());
            textArea.append("got: " + headers + "\n");
        } catch (Exception ex) {
            textArea.setText("Error, consult Java console for more info");
            ex.printStackTrace(System.err);
        }
    }
} 
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
There is no possible work around other than to disable HttpOnly cookies.


Comments
CPU18_07-critical-request - Justification : customer request - Risk Analysis : Low. - Testing (done/to-be-done) : Tested by manually running above app. - Back ports (done/to-be-done) : none - FX Impact : N/A - Fix For Release : 8u181
17-04-2018

Can be easily reproduced with testcase at: http://oklahoma.us.oracle.com/www/tests/10/cookie/cookie.jnlp tests sets Cookie: [FOO=BAR;HTTPOnly, ABC=XYZ, FOO1=BAR1;HttpOnly] and gets Cookie: [ABC=XYZ; FOO1=BAR1] ie: gets the cookie with attribute "HttpOnly" but not the one with attribute "HTTPOnly" after fix it gets both Crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UCPU-544
10-04-2018

The native method Java_com_sun_deploy_net_cookie_IExplorerCookieHandler_setCookieInfo() in jdk.deploy/windows/native/cookie.cpp uses case sensitive wcsstr to search for "HttpOnly", causing this problem
17-11-2017

Reported with 8u151 Windows 7 IE 11.0.9600 Verfied with 8u151, 9, 9.0.1 Windows 10 IE 11.1770.14393 Checked this with the provided test case (see subsequent comment) from the submitter and could confirm the issue as reported. Results: ======== 8u151: FAIL 9: FAIL Steps to reproduce: ========================== LocalCookieTest - Install the LocalCookieTest.war file on an application server like Tomcat running locally and open it by going to http://localhost:8080/LocalCookieTest/ in Internet Explorer and simply pressing the Text button. The application uses the default cookie handler, which for an applet is Internet Explorer's. It sets three cookies for java.com: one normal, one HttpOnly cookie using the attribute flag "HttpOnly" and another HttpOnly cookie using the attribute flag "HTTPOnly". It then tries to read them back, only the first two cookies can be read by the applet. Java will not return the result of the cookie with the "HTTPOnly" attribute. ServerCookieTest - A more complex, but realistic test case is to install ServerCookieTest.war in an application server like Tomcat running locally and open it by going to http://localhost:8080/ServerCookieTest/. This test case is more convoluted as it tests reading random number cookies actually being set by a jsp file on the server. What type of cookie is set is controlled by sending a parameter to the jsp. Of the 6 buttons displayed, the first three use the default Cookie Manager (IE) and the second three create a different Cookie Manager, such that cookies are not shared with Internet Explorer. The 'HttpOnlyCookie' tells the jsp file to set the "HttpOnly" attribute on the cookie. The 'HttpONLYCookie' tells the jsp file to set the "HttpONLY" attribute on the cookie. The other button just sets a regular cookie. For the "Test browser 'HttpOnlyCookie'" case, the value displayed will match what is sent by the server because the Java applet can read it. For the "Test browser 'HTTPOnlyCookie'" case, the read cookie value will never be the value sent by the server. It will be whatever the last read value was from the "Test browser 'HttpOnlyCookie'" button. The reason for this is that the Java applet can read shared HttpOnly IE cookies that have the attribute of "HttpOnly", but not "HTTPOnly". The RFC about HttpOnly cookies says that the HttpOnly attribute is case insensitive, so this behavior is wrong. https://tools.ietf.org/html/rfc6265#section-5.2.6 As for why any of this matters. CA, the company that creates SiteMinder (a single sign-in provider), uses "HTTPOnly", when they send their SMSESSION cookie. Java can't read that and as such, responds back with an old value. This causes SiteMinder to time out the session when it should not.
03-11-2017