Session Security in ColdFusion - Sub-series Intro - Security Series #6

What is session Management?

This may be review for many, but understanding what session management is, and what it is for, can help us understand how, and why, to keep sessions secure.

We web developers work in a unique environment compared to other types of programmers. We work in a stateless environment. The World Wide Web is a stateless. What does this mean? What is a stateless environment?

With a stateless server, each request to the server is treated separately from any other request. This means that if your user requests pageA.cfm and then immediately requests pageB.cfm the web server does not in anyway relate those pages to each other. They know nothing of each other. They cannot share variables, they cannot call each others functions, etc. Once the new page is requested, the old is discarded like old coleslaw.

This is where session management come in. Session Management is a way to create statefulness in a stateless environment. By assigning each client a session token , which is then passed from request to request, a session and the information contained within its scope are persisted and can be shared between requests.

Obviously, there is more to a session than this. But these are the basics. To learn more about Sessions check out the wikipedia article

So what is a session token?

A session token is a unique string of characters (usually alpha numeric) that is used to identify a client(Web browser) to the server. The web server can then match that client with the appropriate session on the server so that information can be shared between requests.

A session token in a default installation of ColdFusion will usually look something like: MYAPP_2_10666880

It is a concatenation of the Application name, the CFID and the CFTOKEN. We will talk more about session tokens and which session token types are best in another post.

So how are sessions persisted?

For a session to persist from request to request the session token needs to be provided for each request. This can be done in one of 3 ways.

  • The first option is to pass the session token on the URL string. Like so: http://www.12robots.com/mypage.cfm?CFID=2&CFTOKEN=10666880

  • The second method is to make the site navigation form-based and include the token in hidden input fields:


    <input type="hidden" name="cfid" value="#session.cfid#">
    <input type="hidden" name="cftoken" value="#session.cftoken#">

    Obviously, this would not be the best solution either, since it would be very easy for your users to deviate from the navigation.

  • The third, and best option, is to use a session token cookie. We will get into cookie security in another post (there is a lot more to it then you would think). But in essence a properly secured session token cookie will submit itself with each request to the server on pages appropriate only to the session to which it belongs. A session token cookie does not require you to remember to add the url token to every link within your page, and it does not require you to make every link within your page into a form. The one downside to it (and I don't personally consider it a downside), is that your users will need to accept cookies from your application.

Why persist a session?

This is an easy one. The primary reason to persist a session is so that your page requests can communicate with each other.

Let's say that your website in a simple online store. And your users each have shopping carts to store the items they wish to purchase. Well, unless you are planning to write cookies for their cart, and everything that they place inside of it, you will need some way for one page (like a product page with an "Add to Cart" button) to communicate with other pages on the site (like the checkout page). Without session management, your checkout page would have no idea what was in your users cart. But with session management, you can link the users session with their browser from page request to page request, so when they add a product on one page, it gets added to the same cart that any other product page on the site would add to. And when your user goes to complete their purchase on the checkout page, it will find the same cart.

So where is all of this session information stored?

Session information, like the shopping cart in our previous example and our session tokens, are stored in the SESSION scope. The session scope is automatically made available to our ColdFusion applications if session management is enabled on the server and in our application.cfc.


<cfcomponent output="false" displayname="Application">
<cfset this.name="myApp" />
<cfset this.sessionmanagement = true />
<cfset this.setclientcookie = true />
<cfset this.sessiontimeout = CreateTimeSpan(0,0,20,0) />
    
</cfcomponent>

The session scope can be accessed from almost anywhere in your application and can be read from, and written to, like any other scope. To create a shopping cart struct inside of your session scope, it would look something like:


<cfset session.cart = StructNew() />

Each client gets its own session, and therefor each client would have its own shopping cart. You could easily create a shopping cart for every new session that is created by adding that code to your onSessionStart() method in your Application.cfc.

To read from your session scope, you would use:

<cfset mySessionId = session.sessionid />


The session scope can hold both simple and complex values, including objects.

<cfset session.cart = CreateObject('component', 'model.cart.cart').init() />

So why do we need to worry about the security of our sessions?

Now that is a good question. Why all of this concern over session management. It seems like a very convenient thing, but a security risk?

In a situation where your users must authenticate with the application (which uses session management), after the initial authentication, session management takes over and persists that authentication from request to request. If the session token can be guessed by a malicious users, or if the token itself is compromised by unsuspecting users, cross-site scripting attacks, social engineering, physical access to the machine, or any other method, then whoever gains access to a valid session token can impersonate the user to whom that token belongs.

This could result in anything from vandalism to the site all the way to identity theft.

A stalker code use a cross-site scripting attack to gain the session token of an unsuspecting victim, and if the information was stored in that person's profile, the stalker could get his/her address and go to their home.

This may seem like sensationalism, I assure you, it is not. Proper session management is VERY serious stuff. And if your users are going to trust you with their data, it is your responsibility to protect that data.

Some of the topics I will be covering over the next few weeks in this series on session securty are:

  • Session token types, which to use
  • Session Hi-Jacking
  • Session fixation attacks
  • Session token compromise through Cross-Site Scripting(XSS)
  • Session token guessing
  • Session token best practices
  • More as I think of it

Comments
Mark's Gravatar How about session replication and vertical and horizontal clustering?
# Posted By Mark | 6/9/08 1:59 AM
Gary F's Gravatar Looks like this will be a good series of blogs, thanks Jason. I'm interested in session replication too, but without using ColdFusion's built-in session replication which I'm told has issues. :-) e.g. how to continue with an existing session (perhaps storing the struct in a central db) if a user is bounced to a different server in the cluster. Kind of like legitimate session hijacking. ;-)
# Posted By Gary F | 6/9/08 3:25 AM
Jason Dean's Gravatar @Gary and Mark - Great Suggestions! Thanks. I will have to research both of those topics, as I do not have a clustered environment in which to work. Do you, or does anyone, have any insight into specific security concern for those topics?

I may have to set up a small Virtual machine cluster with the developer edition and see what I can do with that. I've heard that CF8 has some new features for persisting sessions across servers.
# Posted By Jason Dean | 6/9/08 7:13 AM
Lu Sancea's Gravatar You could stop a good amount of XSS with the scriptProtect attribute in cfapplication and using HTMLEditFormat(). This sounds like a good series man, it should teach people new to web programming folks and jog the memory of the experienced folks. Keep up the good work.
# Posted By Lu Sancea | 6/9/08 7:14 AM
Jason Dean's Gravatar @Lu, thanks for the comments

You're right. Most XSS can be stopped with Script Protect and HTMLEditFormat(). But my goal with this security series is to go beyond telling people things like "Use cfqueryparam to stop SQL injection" . While it may be true, it does not really help the developer understand WHY they should do that and HOW it does what it does.

The idea behind teaching the Hows and Whys is that if people understand why they need to do something to protect their application and how to implement it, it can help them in recognizing new security issues and tackle them before they become best practices.
# Posted By Jason Dean | 6/9/08 9:50 AM
Brian's Gravatar I'm looking forward to more about this as well, if for no other reason then to try to figure out why some of our customers can maintain session state across nodes in a cluster and why some (sigh) can't.

I might add that I have NO idea how the cluster is configured, but it feels wrong to me because I don't believe that it's an "approved" way. But I could be wrong (snark)
# Posted By Brian | 6/9/08 10:15 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner