HttpOnly and secure properties of Session cookie

HttpOnly and secure properties of Session cookie
One, attribute Description: 1 Secure property
When set to true, the cookie that is created is transmitted to the server in a secure manner, that is, it can only be passed to the server by the browser on the HTTPS connection for session verification, and if the HTTP connection does not pass that information, it will not be stolen to the specific content of the cookie.
2 HttpOnly Properties
If the "HttpOnly" attribute is set in the cookie, the cookie information cannot be read by the program (JS script, applet, etc.), which can effectively prevent the XSS attack.

For the above two properties, first, the secure property is to prevent the information from being listened to during the transmission of the information leak, the purpose of the HttpOnly property is to prevent the program from getting the cookie after the attack.
Second, glassfish2.x supports servlet2.5, and servlet2.5 does not support the "HttpOnly" attribute of the session cookie. However, using the filter to do some processing can simply implement the HttpOnly property. GlashFish3.0 (Support servlet3.0) opens the HttpOnly property of the session cookie by default.
That is, two attributes, does not solve the cookie in the local information leakage problem (Firefox plugin Firebug can directly see the information about the cookie).

Second, examples
Project Architecture Environment: Jsp+servlet+applet

1 adding HttpOnly and secure properties
According to the previous instructions, the GLASSFISH2 does not support the HttpOnly attribute of the session cookie, and the secure attribute also needs to be set by itself, so the final treatment is to add a filter to the project, the entry page for the request ( Or a request to jump to the first customer-visible page, usually landing page, reset the client session properties.
(Response.setheader ("Set-cookie", "jsessionid=" + SessionID + "; Path=/ccrl;secure; HttpOnly "); As can be seen, the premise of this sentence is that only the session cookie can be used this only cookie, cannot use other cookies to interact between the browser and the server, otherwise it will clear other cookie information, if you must support other cookies, Can work in the header)

2 modifying incompatible code in a program (ccrl113)
(1) Phenomenon: After the session cookie is set to the HttpOnly attribute, because the program can no longer take the contents of the client session cookie, causing the applet to send URLConnection request to the server, Unable to read from the browser to SessionID, causing some urlconnection that depend on the contents of the session not to return the correct results.
WORKAROUND: The SessionID information is first passed into the applet when the applet is started, and then the session cookie information is reset when the URLConnection sends the request. Urlcon.setrequestproperty ("Cookie", "jsessionid=" + SSID + "; Path=/ccrl113;secure; HttpOnly ");

(2) Phenomenon: When dynamic analysis starts, there is a use in the JSP page
URLConnection accesses the servlet, but in the case of HTTPS, the JSP is not allowed to use URLConnection to access the servlet (inferred from the phenomenon).
Workaround: Extract content refactoring from the servlet into a tool class or entity class for use by JSP pages. Because both the JSP page and the servlet are server-side, it is entirely possible to avoid JSP pages accessing the servlet through URLConnection.

HttpOnly and secure properties of Session cookie