Hide menu Last updated: Sep 28 2016
Area: Episerver CMS Applies to versions: 10 and higher
Other versions:

Protecting users from 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. Session hijacking is a threat when you use the ASP.NET forms authentication scheme. This topic explains  steps you can take to protect your website users from it.

Sidejacking

Many websites today use SSL to protect login pages, but use the standard, unencrypted HTTP protocol after the client is authenticated. If the hijacker has access to the same network as the authenticated client, and knows (or can guess) the name used for the session cookie, the hikacker 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 impersonates 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. Allowing only trusted people to access that communication drastically reduces 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. After you obtain a certificate, configure IIS so that your site uses the certificate.

Ensuring encrypted connection for session cookies

To protect against session hijacking, encrypt all communication where the session cookie is sent with one of the following options. 

Option 1: Force SSL at all times

In IIS, enable a checkbox setting at SSL Settings > Require SSL so your site responds to non-encrypted requests with a 403.4 error:

403.4 Error

Note: All external links pointing to your site using the non-encrypted HTTP protocol will return the 403.4 error. However, cookies that are stored at the client ("Remember me") are not vulnerable because they are 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, so you can use SSL only on parts of your site (edit/admin for example) and allow non-encrypted communication when you browse the public parts of your site.

requireSSL attribute

Note: Users are logged out when they switch from the HTTPS protocol to the HTTP protocol because the session cookie is withheld by the client. If you are careful to use only relative links on your site, protocol-switching should be predictable, but your site likely has a few absolute URLs pointing to itself. However, external links to your site are valid still.

Dealing with mixed content warnings

When you first switch to the HTTPS protocol you may get this warning on several pages:

Mixed content warning

This warning 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-to-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 the warnings, you may have to overhaul the code of your application. Sometimes you can solve this issue by making a few absolute URLs relative or adding 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 may be hard to solve. 

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 that is only accessible from the internal company network where editors can add content.
  • One (or more) application that is publically accessible but where the edit/admin interface is disabled.

Note: All applications need to have access to a common database.

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

Unless you combine this action with using SSL, you do nothing to prevent session hijacking on the public websites. You simply reduce the potential damage a hijacker can cause by denying them access to the powerful edit and admin interfaces.

Comments