Posts Tagged ‘ session hijacking ’

So, about that session data you sent me…

One of the best things about web applications is…well, a lot of things but most notably scalability, extensibility, and cross platform compatibility (lots of other ‘ly words too).  One of the worst things web applications and web services has going for them would be security.  I am sure that we’re all familiar with things like the OWASP Top 10, and WASC, but many developers responsible for creating the applications we depend on so much are often not familiar with this material.  It’s true that there is an abundance of application security information for developers, but it’s rarely ever implemented or regarded as a core component of the SDLC.  Despite the amount of time that we’ve known about certain vulnerabilities, we continue to see them in both small scale and enterprise applications, and to be honest, I don’t think it’s fair to fault the developers.  As of late, the most common vulnerabilities I have seen in web applications are directly related to poor session security and session management.

By no means is this intended as a thorough guide on securing your application nor is it groundbreaking material, but it may serve as a useful primer for those looking for introductory information on securing session data.

Since Wikipedia, Microsoft, OWASP, and others have already done a fine job with the verbiage, a rehash will suffice:

Think of a session as a semi-permanent interactive information interchange, also known as a dialogue, that transpires between two or more communicating devices.  In the context of web applications, the session most frequently refers to the exchange of data between the end user and the remote application.  Lastly, an application can use the session data to track whether a user has authenticated to the application, what resources they have accessed, and when their session expires in addition to a whole lot of other stuff.

So, now that we’re very well versed in all things session related, how do we protect this sensitive information?  Here’s 4 basic things to get you started:

Mark cookies secure

When a user traverses a website, it is not uncommon for the user to be directed to URLs that use both HTTP and HTTPS.  Due to the fact that these page views may not be encrypted and may transmit sensitive session data, all cookies associated with a given user’s session should be marked as secure.  By marking a cookie as secure, this data will not be transmitted over a plain text channel thus minimizing the chance that they will be intercepted.

Mark cookies as HTTP only

Cross-site scripting attacks aren’t new and since preventing XSS would be an entirely different post, best practice dictates that cookies should be marked HTTPOnly.  When a cookie is marked HTTPOnly, its value cannot be read by a client-side script.  It’s particularly useful when dealing with XSS attacks which are commonly used for session hijacking after transmitting a user’s session data to a remote entity.

For example, if successfully used in an XSS attack, JavaScript’s “document.cookie” can be used to create a log entry in the web logs of a server controlled by an attacker.  This log entry would contain the session data required to mount a session hijacking attack.  Additional things need to be present in the application’s behavior in order to successfully hijack someone’s session but most of the time it works with little fuss.

Encrypt all communications between client and server which transmit session data

Marking cookies as secure should prevent them from being sent unencrypted; however, you really shouldn’t rely on just one mechanism to keep that data safe.  If a user is sent to a secure page, think long and hard before you decide to send them back to HTTP and what you are sending with them over that unencrypted connection.  Many times you will see that a site’s login page redirects to https://blahfoobiz.com/login.asp but once the user has logged in, they get sent to http://blahfoobiz.com/myaccount.asp.  It’s great that the credentials have been sent over HTTPS, but since the redirect to myaccount.asp is over HTTP, not only could sensitive session data be transmitted in an insecure fashion, but the data contained on my account.asp is also vulnerable to interception.

Tie your users to the session
I would say that this is probably the most important of the four points listed.  When a user accesses resources on your application, they provide a tremendous amount of information such as source IP address, browser version, operating system and much more.  Since this information is already being sent to the application, make the application use it.  By incorporating this data, you can create a relatively unique fingerprint of the authenticated user which can in turn be used to provide additional session security.  It’s true that just about everything the client sends to you can be forged and that’s unfortunate; however, depending on the client data you are hashing/mashing, reproducing this data can be very difficult for an attacker.  Once you have this information, you can check it against future requests which are made using an established session and verify that the data provided is in fact coming from the original user.  If the information does not match, the session should be effectively terminated.

Again, all of this is far from comprehensive but it seemed worth mentioning.