Session handling gone wild

Posted: 11.7.2011 in Security
Tags: ,

At web application (security) testing I like to investigate how sessions and cookies are handled. I’ve noticed that there are some common error patterns which are havocking the security of the session. Here’s brief list of the most common issues I’ve noticed. There is more issues than these five, but these are the most common once I’ve seen.

Randomness and length of session id are very important. If the randomness is poor or length is too short, the attacker can guess the session id which is already in use. I usually check this just in case. Luckily most of the frameworks are generating the session id internally, and developer cannot weaken that too much. But I’ve seen some coders creating own session handling, where length is too short. In that case different users are getting same session id and sessions gets hijacked.

When the authentication state of user changes, it is very important to change also the session id. Usually when user enters to pages without authentication, session id is generated. Even after logging in the same session id stays. This behavior is not very good. If the application were developed correctly, the first session id is given when user enters to web pages. When user logs in the session id is invalidated and removed from the user. During log in process the user receives new session id which differs from original one.When user logs out, the old session id is invalidated and new is created.

Too often I’ve seen that single cookie is used to authenticate user. That single cookie contains some kind of reference to user id and password, and it never changes. At application there can be session id which is secured, it changes as it should, it’s random enough and so on. But there is also cookie like XYZ_USERDETAILS which is some random looking string. When user logs out, session id is invalidated, XYZ_USERDETAILS is removed. But when used logs in again, the XYZ_USERDETAIL becomes same as it were after previous log in. Session id differs. If that kind of vulnerability exists, then if attacker can get the XYZ_USERDETAIL somehow, he can access with that information any time to target’s information. There shouldn’t be any static information which identifies the user.

Web application should always make sure that it is accepting only such session ids which are generated by it. I’ve seen many PHP applications which are accepting any session id which browser sends as long as syntax is correct. Instead of generating new session id it accepts whatever the browser is telling about its session and uses that to store session information. In those cases if attacker can get Javascript access (thru XSS) or local access, the attacker can set permanent session id for the browser which never changes. (Now I’m expecting that session id is not changed when user’s privileges change and web application never intentionally sets session id to empty.) So if browser tells that its session id is “aaaaaaaaaaa”, the web application must check from internal systems, that “aaaaaaaaaaa” is generated by it and is valid session id. If it is not, then system should change it to valid one.

Session ids (and all other cookies) must be protected as well as possible. There are two flags for that. If web application is using only https-protocol, then session id must be protected with secure-flag. Browser won’t send cookies with that setting over http-connection. If Javascript is not supposed to read it, then httponly-flag should be enabled.  From cookie security point of view the same domain should not be for http- and https-protocols. Mixing confuses the end user and prevents good cookie security. See e.g. Facebook from confusing system. If you don’t look carefully, you might end up to http-protocol even if you expect it to have https-protocol.

As the testers we should be familiar with basics of security and investigate what the application does below the user interface.

Advertisements
Comments
  1. Excellent, I really enjoyed this post, very informative for those like me who are interested in learning more about web security.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s