Thursday, July 26, 2007

Keep your session id secured!

Last week, we received an email from one of the website partner that our website has SessionID vulnerability. They titled the issue as “Web Server Predictable Session ID Vulnerability”

There is company that can run free security scan on a website and give a detailed report.

Back to topic, so what does that mean? There are few reasons why this kind of issue may be reported. One could, the pattern in which the webserver generates SessionID is predictable. It is not randomized enough. Or it could be because the state management technique, say may be query string or cookie that holds the information. Usually the identifiers in some of the application are identity column. For attackers this way they can predict session state and hack in to others session. Or could be the server issues same session id for HTTP and HTTPS portion of the website. It becomes for someone to impersonate SSL session with a webserver using the non-SSL session id and hack in to someone’s session.

Regarding randomizing the session id, it is more like a webserver fix. This was an known issue with some of the old J2ee based Webserver. However, there are easier fix. IIS session ID random enough.

Building session context using memberId is not advisable technique. If we are using query string, it is advisable to use Encrypted key or GUiD kind of approach. If we are building solution based on Cookie, it makes sense to hash and encrypting cookie so they are secured.

I am not sure about the scope of this issue, in the sense, is it an issue with IIS or other web servers too. But in IIS4 and IIS5, this was considered as bug and there were patches to fix them. In IIS6 we have better way of managing this. You can toggle separate session id for the SSL portion of the website. The granularity can be managed at say whole website or for a given virtual directory or given application.

adsutil set w3svc/1/AspKeepSessionIDSecure 1 >>> This will turn on secured session id for SSL