Forum Discussion
Kevin_Stewart
Employee
EmployeeSession tables
I have a question for the DevCentral pundits, and the community at large. This isn’t so much a right or wrong question as it is just experience and best practice. So let me set up the scenario:
I have a site behind the BigIP for which I need to store some information in an in-memory session table (SSL, UIE, Hash, whatever). The information is sensitive, likely in the order of authentication data and/or certificate information and should be kept in a session table vice something that the client passes back and forth. Said session table stores that information and indexes it by some *unique* value that either the client possesses or is unique to the connection. The question then lies in what that unique value might be, what people have used successfully, and what is considered best practice. Before you answer though, consider the following thoughts.
Cookie: storing the unique ID in a cookie, like an ASPSESSIONID, PHPSESSIONID, JSESSIONID, CFTOKEN, etc. is fine, but like any cookie-based solution, it is vulnerable to client-side vulnerabilities, namely XSS. Current statistics show that over 60% of web attacks are based on XSS vulnerabilities. Some industry experts also say that almost every web application out there is susceptible to this vector in one way or another. If there’s any chance that a rogue agent can steal that unique ID from a user’s cookies, then cookies are possibly not the best way to go for this kind of data.
SSL Session ID: this has always been a favorite of mine and one that I’ve used extensively in production environments with no issues. Interestingly though, there is a statement in one of the DevCentral iRule Wiki pages (http://devcentral.f5.com/wiki/default.aspx/iRules/SSL__sessionid.html) that says: “Because ID’s are not globally unique, the session id needs to be combined with something else”. Not globally unique? I’d first like someone to qualify that statement. Second, I can concede that there might not be any mechanism to prevent duplicate entries, but 64 (randomly?) generated digits, in the span of all of the BigIP’s concurrent SSL connections, should reasonably produce unique values. It’s probably also important to understand how that number is generated. Also consider that modern browsers will change that SSL session ID frequently. I don’t profess to know how the BigIP tracks the changed values across connections, but to say that it does. In any case, the statement has me wondering now if this is the best approach.
Client/Browser-based persistence attributes: there a few other options, Client IP, User-Agent, etc. that have some merit, but clearly finding some attribute, or some series of attributes that are absolutely unique to the client and persistent to the session is not an easy task.
So what do you think? What do you use in this situation? What has worked best for you? Let me know.
Thanks.
Kevin
hoolioCirrostratus
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