15 Jan 2013 Simple Session-Sharing in Tomcat Cluster Using the Session-in-Cookie Pattern Part 2: Security
In my previous post I presented the basics of sharing sessions in a cluster by storing session data in a client-side cookie. In part 2, I’ll talk about the security aspects of this client-side cookie store, i.e. how to protect it from security threats.
To prevent attacks specific to client-side sessions, I’ll add encryption, signing, and session timeout to the code. In addition, I’ll talk about solutions to protect against security threats common to any web application, such as Session Hijacking, Session Replay, and Cross-Site Scripting. The result will be an implementation of the Session-In-Cookie pattern that allows simple and secure session-sharing in a cluster.
Disclaimer: any hand-rolled security solution always bears risks. As stated on the Open Web Application Security Project (OWASP) website, “Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws (…)“. I am not a security expert, and the following solution may have flaws, so proceed with caution. If you use this solution in a production environment be sure to have a security check conducted by an independent party.
Encryption
The code presented in part 1 accomplished our main objective – sharing session data by storing it in a cookie – but did not provide any security against malicious hackers trying to exploit data. Even though object serialisation does not lead to a human-readable form – the session attributes or their values cannot be inspected by viewing the cookie – the cookie could easily be converted into an object model to be read and tampered with.
If a hacker has obtained a valid session he can therefore manipulate the session data, e.g. by copying the cookie from the browser’s cookie manager, changing it, and pasting the changed cookie back into the cookie manager. To prevent this manipulation encryption can be used to make the contents of the session unreadable.
Adding encryption to our solution means encrypting the serialised session before storing the data in the cookie.
private void storeSessionInCookie(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) { (...) CookieSession cookieSession = new CookieSession(); cookieSession.setAttributes(attributes); try { String serialisedCookieSession = toString((Serializable) cookieSession); Cookie newSessionCookie = new Cookie("session", encrypt(serialisedCookieSession)); newSessionCookie.setPath("/"); httpServletResponse.addCookie(newSessionCookie); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } }
The encryption is done using a standard AES encryption.
private static String SECRET = "MySuperSecretKey"; // secret key length must be 16 (...) public String encrypt(String string) { byte[] ciphertext = null; try { SecretKey key = new SecretKeySpec(SECRET.getBytes(), "AES"); Cipher aes = Cipher.getInstance("AES/ECB/PKCS5Padding"); aes.init(Cipher.ENCRYPT_MODE, key); ciphertext = aes.doFinal(string.getBytes()); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } return new String(ciphertext); }
To restore the session from the cookie, the serialised session string has to be decrypted first before it can be de-serialised to our CookieSession object.
private void getSessionFromCookie(HttpServletRequest httpServletRequest) throws IOException { (...) if (null != sessionCookie) { String encryptedSession = sessionCookie.getValue(); try { String serialisedSession = decrypt(encryptedSession); CookieSession cookieSession = (CookieSession) fromString(serialisedSession); Map<String, Object> attributes = cookieSession.getAttributes(); for (Map.Entry<String, Object> attribute : attributes.entrySet()) { session.setAttribute(attribute.getKey(), attribute.getValue()); } } catch (Exception e) { LOGGER.error(e.getMessage(), e); } } }
The decryption just reverses the previously used encryption method.
public String decrypt(String encryptedString) { String cleartext=null; try { SecretKey key = new SecretKeySpec(SECRET.getBytes(), "AES"); Cipher aes = Cipher.getInstance("AES/ECB/PKCS5Padding"); aes.init(Cipher.DECRYPT_MODE, key); cleartext = new String(aes.doFinal(encryptedString.getBytes())); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } return cleartext; }
With this modified session filter the cookie sent to the browser is not readable anymore. Even if the method of serialisation and encryption is known, an attacker cannot read the data unless the private key is compromised.
Signing
Even though once the session is encrypted the session cannot be deciphered, it can still be tampered with. A hacker could change the encrypted cookie string, and even though he cannot know what kind of effect this would have to the session data, it could still be a valid session cookie. This means tampering is possible.
To prevent session tampering a signature hash of the serialised cookieSession object can be added before encryption. This hash gets encrypted together with the session object to form a single cookie string. If a hacker changes that cookie string he either changes the content, the signature hash, or both and this would reveal that the cookie has been tampered with.
The signature is added once the cookieSession has been serialised. The serialised cookieSession string plus the signature are then encrypted together.
private void storeSessionInCookie(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) { (...) CookieSession cookieSession = new CookieSession(); cookieSession.setAttributes(attributes); try { String serialisedCookieSession = toString((Serializable) cookieSession); String signature = calculateSignature(serialisedCookieSession); Cookie newSessionCookie = new Cookie("session", encrypt(serialisedCookieSession+signature)); newSessionCookie.setPath("/"); httpServletResponse.addCookie(newSessionCookie); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } }
The signature is a standard SHA-1 hash padded to 40 characters to have a uniform signature length.
private String calculateSignature(String serialisedSession) { String hash = null; MessageDigest cript; try { cript = MessageDigest.getInstance("SHA-1"); cript.reset(); cript.update(serialisedSession.getBytes("utf8")); hash = new BigInteger(1, cript.digest()).toString(16); // Pad to 40 chars hash = String.format("%1$40s", hash); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } return hash; }
When restoring the session, the signature is checked after the session cookie is decrypted. The signature is always the same length, so the last 40 characters of the decrypted string is our signature hash.
private void getSessionFromCookie(HttpServletRequest httpServletRequest) throws IOException { (...) String encryptedSessionPlusSignature = sessionCookie.getValue(); try { String serialisedSessionPlusSignature = decrypt(encryptedSessionPlusSignature); String signature = serialisedSessionPlusSignature.substring(serialisedSessionPlusSignature.length() - 40); String serialisedSession = serialisedSessionPlusSignature.substring(0, serialisedSessionPlusSignature.length() - 40); // check signature if (!signature.equals(calculateSignature(serialisedSession))) { LOGGER.error("Session has been tampered with"); } CookieSession cookieSession = (CookieSession) fromString(serialisedSession); Map<String, Object> attributes = cookieSession.getAttributes(); for (Map.Entry<String, Object> attribute : attributes.entrySet()) { session.setAttribute(attribute.getKey(), attribute.getValue()); } } catch (Exception e) { LOGGER.error(e.getMessage(), e); } } }
Session Timeout
Sessions usually have a session timeout to expire the session after certain amount of inactivity. For servlets this timeout can be set in the web.xml. One reason for this timeout is to limit the amount of memory needed to store session data: once a session is expired the data can be removed from memory.
There is also a security-relevant reason for such a timeout: to limit the time hackers have to exploit an existing session. An example for this scenario is the use of a public computer. If a legitimate user of your application forgets to log out and leaves the public computer, the next user – possibly a hacker – has a valid session to your application, and can use your application on behalf of the legitimate user. Without a session timeout this scenario could happen any time after your legitimate user has left, which could even be days later if the computer is left running .With session timeout a hacker only has a short period of time where he can do damage.
To incorporate session timeout we add a lastAccessedTime member to the CookieSession class. It represents the time of last activity, and is set every time the cookie is written.
private long lastAccessedTime;
The lastAccessTime is set before the CookieSession object is serialised.
private void storeSessionInCookie(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) { (...) cookieSession.setAttributes(attributes); cookieSession.setLastAccessedTime(new Date().getTime()); try { String serialisedCookieSession = toString((Serializable) cookieSession); String signature = calculateSignature(serialisedCookieSession); Cookie newSessionCookie = new Cookie("session", encrypt(serialisedCookieSession+signature)); newSessionCookie.setPath("/"); httpServletResponse.addCookie(newSessionCookie); } catch (Exception e) { LOGGER.error(e.getMessage(), e); } }
On the return-trip the lastAccessedTime is checked after the cookie is de-serialised again. The session timeout specified in the web.xml (session.getMaxActiveInterval()) is added to lastAccessedTime and compared to the current time. If the current time is greater then the session has expired.
private void getSessionFromCookie(HttpServletRequest httpServletRequest) throws IOException { (...) String serialisedSession = decrypt(encryptedSession); CookieSession cookieSession = (CookieSession) fromString(serialisedSession); // Check Session expiry if (cookieSession.getLastAccessedTime() + (session.getMaxInactiveInterval() * 1000) < new Date() .getTime()) { LOGGER.error("Session expired"); // TODO: Forward to Expiration page return; } (...) }
Other Security Threats
Adding encryption, signing, and session timeout sets a basic level of security aimed at attackers that exploit the fact that the session is stored client-side. In addition, there are security threats any web application has to be protected form. Here are three more common threats and how they apply to cookie-based session storage.
Session Hijacking
Session hijacking is an exploitation by which the attacker sniffs out the session cookie of a legitimate user to get unauthorised access to the application. Session hijacking is always possible if the traffic is not secure, regardless of whether the session data is stored server- or client-side. If the data is stored server-side, the cookie will only contain the session id. If the data is stored client-side, the cookie contains the complete session data. Either way, if an attacker gets a hold of this cookie he can get access to the application.
The best way to prevent session hijacking is to use Transport-Layer Security (TLS). To ensure that the session cookie is only transmitted via https the cookie should be marked as secure:
newSessionCookie.setSecure(true);
Replay Attack
TLS also protects from Replay Attacks, by which traffic between client and server is recorded to replay it later on. TLS adds a one-time key to the conversation to reject if the same traffic is sent multiple times.
There is a variant of the Replay Attack that only is possible if the session is stored client-side. A hacker who has legitimate session into you application can reset a session to its earlier state by just copy-and-pasting and older value into the cookie. This value will be valid, because it is properly encrypted and signed, and if the session hasn’t expired the application will accept this old session without knowing of any tampering.
This cannot easily be prevented with client-side sessions, but will only cause problems if certain information is kept in the session. An example would be if an account balance is kept in the session, and the hacker buys an item on your web site. If the cost of the item is deducted from the account balance in the session, then copy-and-pasting an older value into the cookie will reset this account balance. The rule-of-thumb is that state-changing information should not be stored in the session.
Cross-site Scripting
Cross-Site Scripting (XSS) is an exploitation by which the session cookie is sniffed out using client-side script injected into the application. Again, the solution to prevent these types of attacks are the same as with any web-application. In both cases marking the cookie as http-only will prevent any script from accessing browser cookies.
newSessionCookie.setHttpOnly(true);
Conclusion
In Part 1, I explained how to share session data by storing it in a client-side cookie. In this post I’ve added security measures to this cookie store. Together, we’ve ended up with a session-sharing solution that is simple to implement, transparent to the developer, and reasonably secure. It is therefore a viable alternative to other session-sharing solutions for clustered environments. This solution passed a 3rd-party security check, and was successfully used in a large-scale public-facing web application running on a Tomcat cluster to enable Continuous Delivery without outage to the end-user.
The complete source code including the session timeout, encryption, and signing of the cookie can be found on Github.
sandy
Posted at 03:43h, 24 JanuaryAs stated, it is dangerous to store user data in session
java67
Posted at 19:21h, 13 FebruaryI agree, one should always code Java web app keeping in mind Cross Site Scripting and other issues
Vikram Jit Singh
Posted at 21:09h, 17 FebruaryHi Marc,
I’ve read that ECB is not a good block cipher. It doesn’t lead to pseudo-randomness and there is still a gist of the actual content left: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
And since this is public, I am not sure whether it’s the safest way. Methods like CBC with require to store the RandomIV generated in the cookie too which might lead to the same security level as ECB. Any other strategies in mind?
Regards.
swidom
Posted at 08:00h, 17 SeptemberMarc, I guess I am not the skeptic that the other respondents are and this might be because I am not a security expert. Nevertheless I have been scanning the web for this very kind of thing as I have the same concerns as you had from the start regarding distributed session management and the pitfalls with having a sys admin “run the show” as opposed to the developers.
Thanks for these two blogs – I have downloaded the code and am going to give it a serious inspection. I do have a couple of questions.
1. I am thinking of restricting my users to having to use an HTML5 compliant browser and using localStorage instead of Cookies. Have you thought about that? There is a lot more “room” in localStorage (I think the default is 20Meg).
2. If the IP address of the user is encrypted into the session data, and if that is compared to the Http request IP address, wouldn’t that thwart, to some extent, session hijacking and add an extra level of fraud detection? Again, keep in mind that I am not a security expert.
Thanks again for these blogs and the code sharing.
Nacho G.
Posted at 08:15h, 02 FebruaryThank you for the great tutorial.
We would like to have nodes in a small Tomcat Cluster share authenticated JSESSIONID cookies using a similar session-in-a-cookie solution, but don’t know how to configure Tomcat cluster nodes to recognize other authenticated sessions in order to create a continuous delivery environment as well.
Do you think this requires that all Tomcat cluster nodes are each configured to utilize a common authentication encryption key?
Any direction would be appreciated.