Tag Archives: secure flag

Session Cookie HttpOnly Flag Java

What is it and why should I care?
Session cookies (or, to Java folks, the cookie containing the JSESSIONID) are the cookies used to perform session management for Web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier − along with any session-scoped data related to that session id − is maintained server-side. Because cookies are transmitted on every request, they are the most common mechanism used for session management in Web applications.

The HttpOnly flag is an additional flag that is used to prevent an XSS (Cross-Site Scripting) exploit from gaining access to the session cookie. Because one of the most common results of an XSS attack is access to the session cookie, and to subsequently hijack the victim’s session, the HttpOnly flag is a useful prevention mechanism.

What should I do about it?
The resolution here is quite simple. You must add the HttpOnly flag to your session cookie (and preferably to all cookies).

Here’s an example of how a session cookie might look without the HttpOnly flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;

And now, with the HttpOnly flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly;

Finally, here is an example of using both the secure and HttpOnly flags:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly; secure;

Not much to it. You can obviously do this manually, but if you’re working in a Servlet 3.0 or newer environment, a simple configuration setting in the web.xml will take care of this for you. You should add this snippet to your web.xml:

<session-config>

<cookie-config>

<http-only>true</http-only>

</cookie-config>

</session-config>

And, if you also use the secure flag, it will look like this:

<session-config>

<cookie-config>

<http-only>true</http-only>

<secure>true</secure>

</cookie-config>

</session-config>

As you can see, resolving this issue is quite simple. So it should be on everyone’s TODO list!

References
­­­­­­­­­_____________________________
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/
http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html
https://www.owasp.org/index.php/HttpOnly

Session Cookie Secure Flag Java

What is it and why should I care?
Session cookies (or, to Java folks, the cookie containing the JSESSIONID) are the cookies used to perform session management for Web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session-scoped data related to that session id. Because cookies are transmitted on every request, they are the most common mechanism used for session management in Web applications.

The secure flag is an additional flag that you can set on a cookie to instruct the browser to send this cookie ONLY when on encrypted HTTPS transmissions (i.e. NEVER send the cookie on unencrypted HTTP transmissions). This ensures that your session cookie is not visible to an attacker in, for instance, a man-in-the-middle (MITM) attack. While a secure flag is not the complete solution to secure session management, it is an important step in providing the security required.

What should I do about it?
The resolution here is quite simple. You must add the secure flag to your session cookie (and preferably to all cookies, because any requests to your site should be HTTPS, if possible).

Here’s an example of how a session cookie might look without the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;

And now, how the same session cookie would look with the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; secure;

Not much to it. Obviously, you can do this manually, but if you’re working in a Java Servlet 3.0 or newer environment, a simple configuration setting in the web.xml will take care of this for you. You should add the snippet below to your web.xml.

<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>

As you can see, resolving this issue is quite simple. It should be on everyone’s //TODO list.

References
———–
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/

http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html

https://www.owasp.org/index.php/SecureFlag