Session protection

The Xperience administration interface utilizes sessions. The web runs on HTTP (or HTTPS), which is a stateless protocol, but in many situations we need to keep some state information (i.e. context). This is where sessions come in handy.

When a user opens a browser and navigates to a website, the web server of that website generates a session ID for this user. The session ID is sent with every request and it is a key for any session data (session data = state/context). This data is stored on the server.

The session ID can be passed to the requests in two ways:

  • via a URL parameter
  • using a cookie

It is recommended to use cookies for passing the session ID. You can disable the cookieless sessions by changing the cookieless attribute of the form element on the <system.web> section of the web.config file:

<authentication mode="Forms">
	<forms cookieless="UseCookies" />

The session ends (in a typical case) after the user closes the browser or after the user is inactive for a specified amount of time.

There are basically three types of session attacks:

  • Session stealing
  • Session prediction
  • Session fixation

Session stealing

A session can be stolen by stealing a session ID. When an attacker steals a user's session ID, he can get access to all of the session data. Because all these session IDs can be read by JavaScript, the most popular method for this type of attack is XSS. An attacker can send a crafted link to a victim with a malicious JavaScript. When the victim clicks on the link, the JavaScript runs and sends the cookie value of the current session to the attacker.

Session prediction

Can an attacker simply guess a random session ID? Most implementations of session IDs are long strings and guessing a correct session ID in linear time is impossible. But there are also bad implementations when an attacker can generate session IDs from known values. This technique is called session prediction. For example, a session ID can be a user name encoded in base64. Fortunately, in ASP.NET, the session ID is a 120bit random number represented by a 20-character string. So, it is relatively safe.

Session fixation

In this case, the attacker lets the server generate a session ID. Then the attacker sets a user's session ID to the generated ID. This is quite easy when the session ID is given in a URL parameter. After that, the user and the attacker share the same session. For example, when the user gets authenticated, the attacker is also authenticated as the user.

The goal of all kinds of session attacks is the same – to get the user's session data or achieve identity forgery. This page focuses mainly on session fixation, as XSS is explained on a different page, and we cannot influence how session IDs are generated. But generally, the implications of all three session attacks and the protective measures against them are similar.

On this page

Example of session fixation

Let's have a simple .aspx page which saves a value to a session and also shows it:

<asp:Literal runat="server" ID="ltlSession"></asp:Literal>
<asp:TextBox runat="server" ID="txtValue"></asp:TextBox>
<asp:Button runat="server" ID="btnSend" Text="Save" /> 

In the code behind, we handle the OnClick() event of the button:

Session["MyPrivateData"] = txtValue.Text;

On page load, we display the value via the literal:

ltlSession.Text = "My private Data:" + CMS.Helpers.SessionHelper.GetValue("MyPrivateData") + "<br/>";

How the attack is executed:

  1. The attacker forges a link to this page with a session ID and sends the link to the user.
  2. The user, unaware of the forgery, clicks the link.
  3. The user sees the page normally and does not register anything unusual.
  4. When the user saves some private data now, the attacker will be able to access it.

What can session fixation attacks do

The main goal of the attacker is to read and manipulate session data or forge their identity. In both cases, the risks depend on the implementation of individual applications. If the application stores sensitive data to sessions (for example, user passwords in plain text) and allows this data to be displayed or changed, the damage can be severe.

Finding session fixation vulnerabilities

With the Xperience administration, session fixation is possible, depending on usage of custom code and the application settings. You need to ensure that you do not store any sensitive information in sessions. The best way is to determine which variables are stored in sessions. Then, check how you can manipulate them (read/change) and think about the risks – what damage can the attacker do by manipulating them. You can find these risks just from the user perspective by inspecting application reactions, parameters and so on.

However, we still recommend code inspection. You can simply find all manipulations with session data by searching for SessionHelper and the Session[] array.

Avoiding session fixation

First of all, there is no native support for protecting against session fixation in ASP.NET. The best practice for protecting your application against session fixation is to regenerate the session ID after a user signs in. You can achieve this by changing the session ID to an empty string and letting ASP.NET generate a new one. However, this action causes loss of session data.

You can include the CMSRenewSessionAuthChange key in the appSettings section of your administration project's web.config file, which enforces a change of the session ID when a user signs in or out.

<add key="CMSRenewSessionAuthChange" value="true" />

After enabling the key, users will not be able to preserve their session data after signing in or out of the administration.

It is still possible for attackers to manipulate non-user session data. You need to ensure that you do not save sensitive and critical information in sessions.