Protecting users from session hijacking

Table of contents

• Introduction
• Session Hijacking
• Sidejacking
• Network Security
• Using HTTPS
• Obtaining and Deploying an SSL Certificate
• Making Sure that the Session Cookie Is Sent Over an Encrypted Connection
• Dealing with Mixed Content Warnings
• Disabling Edit/Admin on a Public Website

Introduction

This document discusses the threat of session hijacking when using the ASP.NET forms authentication scheme and the steps you can take to protect your website users from it.

Session hijacking

Session hijacking is a collective term used to describe methods that allow one client to impersonate another, thereby giving the hijacking client the same access rights as the target client. A common session hijacking method is called Sidejacking which targets session cookies used by the ASP.NET forms authentication scheme.

Sidejacking

Many websites today use SSL to protect login pages, but use the standard, unencrypted HTTP protocol once the client has been authenticated. Provided that the hijacker has access to the same network as the authenticated client, and know or can guess the name used for the session cookie, he can read the unecrypted HTTP traffic passing between the client and server and steal the session cookie. By using a copy of the session cookie the hijacker can impersonate the authenticated client. 

Network security

The first, and often only, line of defence against this type of attack is network security. All non-encrypted HTTP communication is susceptible to session hijacking, by only allowing trusted people to access that communication we drastically reduce the threat. The most vulnerable points are public networks to which anyone can connect and capture your communication, the most common cases are public or unprotected private WLAN access points. As a client, restrictive use of unprotected networks is usually sufficient defence against session hijacking.

Using HTTPS

HTTPS is a combination of the standard HTTP protocol and the cryptographic security of the SSL protocol. The HTTPS protocol contains mechanisms for secure identification of the server and encryption of the client-server communication. By correctly using HTTPS on your website you completely protect your users from sidejacking.

Obtaining and deploying an SSL certificate

First of all you need to obtain an SSL certificate from a Certificate Authority (CA). A CA is third party that the client trusts to verify that the site using the certificate is indeed the owner of the certificate. There are many CAs to choose from. Once you have obtained a certificate you need to configure IIS so that your site uses the certificate.

Ensuring encrypted connection for session cookies

In order to fully safeguard against session hijacking you need to make sure that all communication where the session cookie is sent is encrypted. You have two options to achieve this: 

Option 1: Force SSL at all times

Enabled via a simple checkbox setting in IIS called "Require SSL" under "SSL Settings". After enabling this function your site will respond to non-encrypted requests with a 403.4 error:

The downside of this approach is that all external links pointing to your site using the non-encrypted HTTP protocol will return the 403.4 error. The upside is that cookies that have been stored at the client ("Remember me") will not be vulnerable as they will now be sent via an encrypted connection. 

Option 2: Only send session cookies over SSL

By setting requireSSL="true" on the forms-element in web.config you specify that the session cookie should only be sent when using the HTTPS protocol. This approach enables you to use SSL only on parts of your site (edit/admin for example) and allow non-encrypted communication when browsing the public parts of your site.

The downside of this approach is that your users will be logged out when they switch from the HTTPS protocol to the HTTP protocol since the session cookie will be withheld by the client. If you are careful to only use relative links on your site, protocol-switching should be predictable, but more probably than not your site has a few absolute URLs pointing to itself. The upside of this approach is that external links to your site will still be valid.

Dealing with mixed content warnings

When first switching to the HTTPS protocol you will most likely get this warning on several pages:

This occurs because your site includes external resources via HTTP URLs. Maybe it is a web form that fetches the JQuery library hosted by Google or a forum posting that shows images hosted on the poster's homepage. The magnitude of this issue can vary from small/none, on a site where 100% of the content is created by editors, to large, on a site where the content is mostly created by members.

To get rid of these warnings you will probably have to overhaul the code of your application. Sometimes you can solve this issue by making a few absolute URLs relative or squeezing in an 's' at the end of "http" in a few places. But if you have a large amount of content that is fetched from sites over which you have no control this problem will be hard to solve elegantly. 

Disabling Edit/Admin on a public website

You can deny session hijackers access to edit and admin mode by having (at least) two applications. One application is only accessible from the internal company network, this is where editors can add content, and one (or more) that is publically accessible but where the edit/admin interface has been disabled. All applications need to have access to a common database.

To disable the edit and admin interface from an installation you change the security settings in web.config for the location blocks that refer to those folders (remove all allow rules under the <authorization>-elements).