Protecting Your Users From Session Hijacking
This technote discusses the threat of session hijacking when using the ASP.NET forms authentication scheme and the steps you can take to protect your 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 ofter 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, Google provides a list of popular CAs here. Once you have obtained a certificate you need to configure IIS so that your site uses the certificate, the procedure is slightly different in IIS 5/6 and IIS 7.
Making Sure That the Session Cookie is Sent Over an Encrypted Connection
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 Secure Channel (SSL)” or “Require SSL” depending on your IIS version, see the previously linked IIS articles for more information. 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. If you’re lucky 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 removed. All applications need to have access to a common database.
To remove the edit and admin interface from an installation you need to remove the VPPs (episerver.config) and location blocks (web.config) that refer to those folders. Trying to access edit / admin will now return a 404 error.
Note that 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.
