Protect users from session hijacking
Session hijacking is a collective term that describes methods that let one client impersonate another, giving the hijacking client the same access rights as the target client. Sidejacking, a common session hijacking method, 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.
Sidejacking
Many websites today use SSL to protect login pages but use the standard, unencrypted HTTP protocol after it authenticates the client. 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 hijacker can read the unencrypted 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 defense 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 defense against session hijacking.
Use HTTPS
HTTPS is a combination of the standard HTTP protocol and the cryptographic security of the SSL protocol. It contains mechanisms for secure server identification and encryption of client-server communication. By correctly using HTTPS on your website, you completely protect your users from sidejacking.
Obtain and deploy an SSL certificate
First, obtain an SSL certificate from a Certificate Authority (CA). A CA is a third party that the client trusts to verify that the site using the certificate is indeed the certificate's owner. There are many CAs to choose from. After you obtain a certificate, configure IIS so that your site uses it.
Ensure an encrypted connection for session cookies
To protect against session hijacking, encrypt communication by sending the session cookie 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:
📘 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. Thus, 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.
<forms ... requireSSL="true" ... />📘 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.
Handle mixed content warnings
When you first switch to the HTTPS protocol, you may get a mixed content warning on several pages:
This warning occurs because your site includes external resources through 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 members mostly create the content.
To get rid of the warnings, you may have to overhaul your application's code. 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 fetched from sites over which you have no control, this problem may be hard to solve.
Disable Edit or 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) applications that are publicly accessible but where the edit or 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 public websites. By denying hijackers access to the powerful edit and admin interfaces, you reduce the potential damage they can cause.