Tag Archives: web.xml

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

Error Handling in Java web.xml

What is it and why should I care?

Error or exception handling is an important, but often ignored, part of any application. And although there’s a lot to be said on the topic I’m going to cover only a few of the most critical cases in J2EE Web applications.

Essentially, one of the biggest worries about exception handling is that you don’t actually handle the exception. Instead, your code − or the code of some 3rd party library you’re using − allows an exception to bubble up. Once the exception reaches the boundary of your application and enters the container, the specific container/application server you are using determines what semantics are applied in handling the exception. Often times, by default, a standard error page is applied and the exception stack trace is printed on the screen in all its glory. This is definitely a problem, because it gives attackers a lot of information about the system, and can lead to further attacks.

What should I do about it?
Handling this issue is fairly straightforward. The basic advice is to provide error handlers for at least java.lang.Throwable (catches any Java exceptions or errors), and provide more specific handlers for individual exceptions and http error codes (the most common being 404 and 500).

An example snippet that can be applied to the web.xml is below:

<error-page>
<error-code>404</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/error.jsp</location>
</error-page>

Note: error.jsp page should be generic and provide a canned response message of a type that contains no detail that could help an attacker fingerprint the app in any way.

There’s a lot more to know and do in regard to handling exceptions in your application. However, from a security perspective, catching Throwables and the specified error codes provides much of the protection you need.

References
———–

http://software-security.sans.org/blog/2010/08/11/security-misconfigurations-java-webxml-files

http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/