IBM HTTP Server - Securing Cookies

The question of secured cookies has arisen recently, where a security penetration test identified a potential risk of cookies being exposed in the clear.

Specifically, this relates to cookies that pass through the IBM HTTP Server web server.

Whilst one would expect the application tier ( in our case, WebSphere Application Server ) to secure cookies, such as the JSESSIONID cookie: -

<snip>

An even more dangerous yet subtle problem with using the HTTP session for security is that the session cookie (JSESSIONID) is usually created before a user authenticates -- typically when they first access the site. At this point, the cookie is often sent in the clear over HTTP. Once the user authenticates, most applications will switch to HTTPS for all future traffic (protecting cookies and content) -- but the JSESSIONID cookie could already have been stolen because an attacker could have captured the cookie when it was initially sent over HTTP. In addition to the obvious point of not using the HTTP session for security, the risk of stealing an HTTP session can be reduced by enabling session security and restricting the LTPA cookie to HTTPS, as discussed earlier.

In addition, cookies created by your applications should be Secure (restricted to HTTPS), and all cookies should be marked HTTPOnly, with a possible exception (which needs to documented, and signed off in a design review) where an application explicitly requires it to function because of client side JavaScript needing access to the cookie.

</snip>

Source: Advanced security hardening in WebSphere Application Server V7, V8 and V8.5, Part 2: Advanced security considerations

However, as a potential mitigation, it's also possible to instruct the web tier to secure cookies, just in case the application developer ( or WAS administrator ) neglects to so do.

This was my source: -

Secure cookie with HttpOnly and Secure flag in Apache

I'm using IBM HTTP Server 8.5.5.10, which is based upon Apache 2.2

/opt/IBM/HTTPServer/bin/apachectl -V

<snip>

Server version: IBM_HTTP_Server/8.5.5.10 (Unix)
Apache version: 2.2.8 (with additional fixes)
</snip>

By inspecting the HTTP headers in the response from IHS to my browser ( Firefox using the builtin Web Developer tools ), I was able to see that the HttpOnly and Secure flags were NOT set by default: -

HTTP/1.1 304 Not Modified
Date: Tue, 20 Sep 2016 07:47:34 GMT
Connection: Keep-Alive
Keep-Alive: timeout=10, max=97
Etag: "df-5360a4cf12c00"

It was necessary to enable the mod_headers directive in the IHS httpd.conf and then enforce secure cookies: -

LoadModule headers_module modules/mod_headers.so
Header set Set-Cookie HttpOnly;Secure

Once I restarted IHS, and rechecked the response, I could see the additional Set-Cookie header: -

HTTP/1.1 304 Not Modified
Date: Tue, 20 Sep 2016 07:41:30 GMT
Connection: Keep-Alive
Keep-Alive: timeout=10, max=99
Etag: "4a0-5360a4cf12c00"
Set-Cookie: HttpOnly;Secure

The job, as they say, is a good 'un