Example of a session fixation
Let's have a simple .aspx page which saves a value to a session and also shows it:
In code behind, we handle the OnClick() event of the button:
On page load, we display the value via the literal:
How is the attack executed:
- The attacker forges a link to this page with a session ID and sends the link to the user.
- The user, unaware of the forgery, clicks the link.
- The user sees the page normally and does not register anything unusual.
- When the user saves some private data now, the attacker will be able to see them.
What can session fixation attack do
The main goal of the attacker is to read and manipulate with session data or an identity forgery. In both cases, it depends on the particular application how dangerous this can be. If the application stores sensitive data to sessions (for example, user passwords in plain text) and allows to show these data or allows to change them, the damage can be severe.
Finding session fixation vulnerabilities
In Kentico CMS, session fixation is possible, depending on application settings. You have 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 with them (read/change) and think about the risks – what damage can the attacker do by manipulating with 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 logs on. You can achieve this by changing the session ID to an empty string and letting ASP.NET generate a new one. However, by this action, you lose the session data.
In Kentico CMS, you can utilize the CMSRenewSessionAuthChange key (insert it into the appSettings section of your web.config file), which enforces a change of a session ID on logon or logout. If you enable this setting, users will not be able to preserve their session data after logging in or out.
There is also the "Impersonation" functionality which allows a global administrator to log on as another user. By implementing this functionality, we have basically secured Kentico CMS against session fixation because it tests if the authenticated user (taken from HttpContext – authentication cookie) is the same as the user in the session. If not, the user info in the session is changed to the right one. But it is still possible for an attacker to manipulate with other data. All you need to take care of is not to save sensitive and critical information in sessions.