views:

71

answers:

2

I have an J2EE compliant web application. I use a session based token to append a secondary id to all incoming link generated by my application. To prevent my application against CSRF attack, I validate the secondary id before I allow the user session to work off the subsequent page.

Recently, while working with session replication mechanism implementation, I observed that on session failover, the generated secodary id is lost and the user get re directed to the login page/default page.

Any suggestions on how I can ensure that the my generated secondary token id is not lost from the replicated session?

A: 

The object representing the token should implement java.io.Serializable to survive whenever the session is to be stored/read/transferred as binary stream (over network, on the disk file system, etc) as would occur in session replication and failover mechanisms.

This is usually already explicitly mentioned in the documentation of the mechanism in question. I'd suggest to read it once again to be sure that you covered everything to get the replication/failover flawlessly to work.

Here's an extract of the Tomcat 6.0 documentation regarding the subject, from the chapter Cluster Basics:

To run session replication in your Tomcat 6.0 container, the following steps should be completed:

  • All your session attributes must implement java.io.Serializable
  • ...
BalusC
A: 

A simple secondary token will only provide limited protection against CSRF attacks. For our own framework (pulse) we decided to sign each URL by generating a custom hash code on the URI which is then salted with session stored secret (a Long which serializable out of the box) before being digested with SHA-256. This way the secret is not exposed when it's added to the URI. The whole process is easily controlled by an Annotation (@RequireToken)

Thomas Weber