Secure WebLogic Cookie

https://docs.oracle.com/cd/E23943_01/web.1111/e13711/thin_client.htm#SCPRG139

http://weblogic-wonders.com/weblogic/2010/07/09/securing-cookies-on-weblogic-server/

A common Web security problem is session stealing. This happens when an attacker manages to get a copy of your session cookie, generally while the cookie is being transmitted over the network. This can only happen when the data is being sent in clear-text; that is, the cookie is not encrypted.
WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:

<WebServer Name="myserver" AuthCookieEnabled="true"/>

Setting AuthCookieEnabled to true, which is the default setting, causes the WebLogic Server instance to send a new secure cookie, _WL_AUTHCOOKIE_JSESSIONID, to the browser when authenticating via an HTTPS connection. Once the secure cookie is set, the session is allowed to access other security-constrained HTTPS resources only if the cookie is sent from the browser.
Thus, WebLogic Server uses two cookies: the JSESSIONID cookie and the _WL_AUTHCOOKIE_JSESSIONID cookie. By default, the JSESSIONID cookie is never secure, but the _WL_AUTHCOOKIE_JSESSIONID cookie is always secure. A secure cookie is only sent when an encrypted communication channel is in use. Assuming a standard HTTPS login (HTTPS is an encrypted HTTP connection), your browser gets both cookies.
For subsequent HTTP access, you are considered authenticated if you have a valid JSESSIONID cookie, but for HTTPS access, you must have both cookies to be considered authenticated. If you only have the JSESSIONID cookie, you must re-authenticate.
With this feature enabled, once you have logged in over HTTPS, the secure cookie is only sent encrypted over the network and therefore can never be stolen in transit. The JSESSIONID cookie is still subject to in-transit hijacking. Therefore, a Web site designer can ensure that session stealing is not a problem by making all sensitive data require HTTPS. While the HTTP session cookie is still vulnerable to being stolen and used, all sensitive operations require the _WL_AUTHCOOKIE_JSESSIONID, which cannot be stolen, so those operations are protected.
You can also specify a cookie name for JSESSIONID or _WL_AUTHCOOKIE_JSESSIONID using the CookieName parameter defined in the weblogic.xml deployment descriptor's <session-descriptor> element, as follows:

<session-descriptor>

    <cookie-name>FOOAPPID</cookie-name>

</session-descriptor>

In this case, Weblogic Server will not use JSESSIONID and _WL_AUTHCOOKIE_JSESSIONID, but FOOAPPID and _WL_AUTHCOOKIE_FOOAPPID to serve the same purpose, as shown in Table 3-1.