18

I am looking at how to secure a web site against getting its session cookie stolen. These are the controls that I know are widely known/used:

  • HTTPS Everywhere
  • Only use a securely created random string for the cookie value
  • Mark the session cookie Secure and HttpOnly
  • Change the session cookie on login

I am debating using a suggestion I found in the Tomcat bug tracker. For each session store the following additional information:

  • SSL Session ID
  • HTTP User Agent
  • Remote IP Address

On each request I would validate that two out of the three stored values match what is captured in the session. That way one of the three could change for various reasons without impacting the user. It would be highly unlikely that a normal user would change more than one per request.

Does this seem like a reasonable additional defense for the session cookie?

chotchki
  • 487
  • 2
  • 5
  • 11
  • 3
    Have a look at [*Preventing session hijacking*](http://stackoverflow.com/a/12234563/53114) (first two paragraphs). – Gumbo May 15 '13 at 18:37
  • @Gumbo, I agree that IP and User Agent alone are not good identifiers of a client machine. SSL Session ID however is a very good identifier but there are times when it changes. So I am asking from a defense in depth point of view if this is a good idea. – chotchki May 15 '13 at 20:20
  • 1
    Checking the ip address will prevent people behind a load balancer from accessing the site. Checking the user-agent provides no added protection as this variable is attacker controlled. The site needs to be free form xss, csrf and click-jacking vulnerabilities. – rook May 15 '13 at 21:51

2 Answers2

16

From the perspective of the site developer, you should use the following:

  • Adopt SSL: use SSL sitewide.
  • Set the secure flag on all cookies. This will ensure that they are only sent over a SSL connection.
  • Turn on HSTS.

This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks.

Search for SSL sitewide on this site to find many references on how to do this.

I wouldn't bother with checking the HTTP User Agent or the remote IP address. They don't add much security and they will break legitimate use in certain scenarios. Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but may be a bit painful to configure and would not be a high priority for me: the other defenses are fine.

Other advice:

If your concern is cookie theft via XSS, the best defense is to use standard methods to avoid XSS bugs in your web application. See OWASP for many excellent resources (you'll want to use context-dependent output escaping).

You mention "session fixation" as a tag, but that's a very different threat. The defense against session fixation is to use a framework that is not vulnerable to session fixation. Most modern web application development frameworks should take care of this for you without requiring any additional work.

Follow secure web application development practices. OWASP has many excellent resources on this.

Read @Rook's advice carefully and follow it:

Checking the ip address will prevent people behind a load balancer from accessing the site. Checking the user-agent provides no added protection as this variable is attacker-controlled. The site needs to be free form xss, csrf and click-jacking vulnerabilities.

schroeder
  • 123,438
  • 55
  • 284
  • 319
D.W.
  • 98,420
  • 30
  • 267
  • 572
0

The implementation 2/3 verification would work fine. I haven't tested this or even know if it's a viable method, but you could also implement a "changing key" of sorts where the session key changes with every request, lowering the attack window.

Nathan C
  • 800
  • 6
  • 9