One of the more favorite attacks with Cross Site-Scripting (XSS) is to hijack another user's session. This attack is known as session hijacking (shocking!). When it boils down to it, session hijacking is no different than you using a public computer and forgetting to sign-out and another person sending email using your account. In our college computer labs it was a fun way to mess with other people.
So you can impersonate another user. Big deal? Yes, that is a big deal. Here is some fun an attacker can have when they are impersonating another user.
- Send an email to the victim's boss telling the boss to piss off
- Attempt to logon to a bank's website. The bank sends a reset password link via email. The attacker is logged into the victim's email account. The attacker can probably log into the victim's bank account.
- Buy stuff from an online site
- Acquire information about the victim's life so they can pretend to be them in real life.
There are number of ways to prevent a user's session from being hijacked.
- Keep the session timeout low, say 10 or 20 minutes. This is fine for banks, a pain in the ass for other sites.
- Require two-factor authentication. This is becoming more common with social media, banking, and email accounts.
- Encode/Decode all text coming to/from back-end services to ensure XSS is not allowed into your system.
Those are all great solutions, and depending on your needs should be implemented. But those take time and money to implement.
For ASP.NET web sites this feature is enabled by default. It was added as part of the .NET 2.0 release, or as I like to call it, the release that gave .NET generics and made it awesome.
Side Note: a lot of security features have been part of .NET a long time. In this case it has been part of .NET since 2005 (damn!). It really pays to read up on how the .NET framework can help us help ourselves.
If you want to make it specific it is easy to do.
<system.web> <httpCookies httpOnlyCookies="true" requireSSL="true" /> </system.web>
What this does:
RequireSSL – It will only allow cookies sent from the server to be sent via https. RequireSSL is a bit of a misnomer. It is more like RequireSSL or TLS, whichever is enabled on your webserver. Let's say the majority of your traffic is done via https. If you are somehow forced over to the http side the cookies will not come along. Anyone packet sniffing the network could read the cookie via http but not https.
I recommend setting this at the web.config file unless it is absolutely necessary. Requiring all the programmers on your team to remember to set these values each time they need to create a cookie is just asking for trouble. We're human, you'll forget, they'll forget, everyone will forget until a bug comes up.