Session tables

Hi Kevin,

 

 

I think most applications make the assumption that HTTP cookies are a valid way to store session information. Ideally the application raises the bar for attackers by implementing proper validation and sanitixation of any user input which is sent back to clients. It's also a good practice to use a layered approach in securing web apps by implementing a web app firewall. These steps mitigate the risk of XSS exploits against the app.

 

 

Most banking applications do accept a session cookie as the single identifier of an existing session. Most apps do not tie the session to an IP address as client IP addresses are apt to change over the course of a legitimate session. Tying the session cookie to a user-agent string might be a reasonable strategy--though not guaranteed.

 

 

One banking customer we work with utilizes a hidden parameter within the app to track whether a one time token has already been used for any form submission. The concept is loosely described here:

 

 

 

Java Tip 136: Protect Web application control flow

 

http://www.javaworld.com/javaworld/javatips/jw-javatip136.html

 

 

The basic idea is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. In other words, the one-time privilege to submit data is given to one specific instance of a view.

 

 

 

 

You could potentially expand this concept to a security device to prevent replay attacks. Even if someone is able to intercept the entire valid request, they would still have to rewrite it inline in order to use the valid session token. They could not simply replay the valid request using the original token.

 

 

I'm definitely interested in other people's thoughts on this as well.

 

 

Aaron