What is the best way to secure a shopping cart within a JAVA/Tomcat website?

Question

I am looking for the best-practice solution regarding how to secure a "shopping-cart" part of an otherwise (relatively) unsecure website.

The existing setup in the site uses an unsecure-cookie, and only secures (via SSL) the transaction of credentials. The rest of the site is accessed via HTTP and thus, data is transmitted unsecurely. This is not a problem for us, though.

However, now we are adding a "shopping-cart-esque" element to the site, and we wish to secure the checkout process. My idea so far was:

1. To rely on a secure cookie (that would hold a long random "Base64-encoded" string as a value) with a 15 minute expiration.
2. The same value (and a creation timestamp) would be saved in the SESSION (on the server-side of course!). Note: I'm talking about the regular, unsecure session.
3. The cookie would only be sent to the user if he authenticated himself. If he is already signed in - he would thus have to "re-authenticate" (unless he has a still-valid 15 minute secure cookie) and give us his password once more.
4. Basically, I guess this is not too dissimilar from a regular 15 minute long secure "tomcat session". Both the credentials AND the data in this session is transmitted via HTTPS/SSL.

Notes and thoughts:

• To validate a secure-cookie, the timestamp and the token-key would both be stored on the regular (unsecure) session object on the server. BUT - Since the secure-token is only transmitted via SSL, there is (in theory) no way for a man-in-the-middle to intercept it. Therefore, even if the attacker manages to steal a regular session ID and forge a user's identity - he would still need to know the specific secure-token associated with this user's (regular) session in order to gain access to his credit card details.
• The 15 minute cookie-lifetime would be enforced both in the client-side and on the server side (by keeping the creation-timestamp).
• The cookie itself (and the secure token) do not hold any confidential (encrypted or otherwise) information. The key is just a long random string.
• To generate the token I thought of using java's SecureRandom, and to Base64-encode the random bytes generated by it, so that it would only contain alpha-numeric, 'slash' and 'plus' characters. I thought of using 512 random bytes, but if it could be done with less I would be happy to hear :)

Is this considered a good solution? Is there a better practice that can be applied in this case? Is there anything that can be done to increase security even further without "over-doing" it?

Thanks in advance! Tom

Answer 1

I would recommend implementing J2EE security. You should have no problem using Struts.

See Oracle Security Guide

Because you are using Cookies you force the client to have Cookies enabled on his/her browser.

You can rather force the user to log in using (J2EE security) when they want to use a basket and then only store the JSESSION (Container default) id on the client browser (user does't need to be authenticated in order to create a session).

If you provide a session timeout of 30min and keep all the client info in the session it is kept at the server and disposed of if the client disappears.

One is able to have Cookies disabled on the browser and still have the server recognize the client. See J2EE Spec