12

cookies usually contain a sessionId to keep track of a logged user.

What would prevent a malicious user to forge millions of requests with random sessionIds and send them to a server, hoping to luckily end up with an existing session Id, and therefore stealing a random session ?

The only thing that comes to mind is the fact that the number of possibilities is quite large. However it is not infinite - I would imagine that a malicious botnet owner could easily make millions of tries in a short time.

How can I, as an application developer, prevent this ?

Thanks !

niilzon
  • 1,587
  • 2
  • 10
  • 17

3 Answers3

14

Session Hijacking through sessionId brute-forcing possible?

Probably not.

owasp says that a session identifier should be at least 128 bit long to prevent session bruteforcing. They give these example calculations:

With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes.

Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

Even if we assume than an attacker can perform 10 million attempts per second, it would still take them 3 month to get a valid id in the last example given.

The session id of PHP for example seems to be 160 bits per default (I think, the documentation isn't so good), you can also set it yourself.

How can I, as an application developer, prevent this ?

Apart from using a strong enough ID, you could also bind a session to an IP, or link it to a TLS session, that way, even if an attacker does obtain the session (via bruteforcing or in a different way), they cannot use it. And you could also block IPs that are using too many attempts with invalid session IDs.

tim
  • 29,018
  • 7
  • 95
  • 119
  • 4
    This is also why you shouldn't allow extremely long sessions, but force a session to end or obtain a new session ID periodically. – COL Wotohice Feb 12 '15 at 14:51
  • 3
    Wouldn't binding a session to an IP be a bad idea? What if the user is on a mobile phone and using data. – haze Feb 12 '15 at 18:33
  • I second that - Binding a session to an IP address will break the application for many people. AOL have a history of using multiple IP-addresses. – Dog eat cat world Feb 13 '15 at 07:32
  • 1
    Just a question on entropy in Session IDs - Why assume 64 bits of entropy for a 128 bit session identifier? – SilverlightFox Feb 13 '15 at 10:31
  • 1
    @SilverlightFox see this [question](https://security.stackexchange.com/questions/59381/how-many-bits-of-entropy-does-an-identifier-contain). – tim Feb 13 '15 at 10:44
2

The answer by tim about entropy is perfect on the topic of brute forcing the sessionId.

But note, there are easier ways to steal the session. For example, if you issue the session over HTTPS (authentication) but then bounce back to HTTP, now your session is exposed in clear text. Anything that goes over HTTP can be assumed is screamed out loud and open for everyone who is listening on the line.

A targeted attack may trick a user to click on a HTTP URL to the target website and the attacker eavesdrops until the user clicks on the URL and send the session over HTTP. that's why you should set Secure flag for your session to make sure it is not sent unless over HTTPS.

You can bind the session to IP, but note that many users may share the same IP if they are behind a NAT. So it is not really a great security solution.

Even if you have your entire session over SSL, still vulnerabilities in the browser may allow stealing the session; Cross Site scripting can steal the session. To be secure, you should fix all these issues, but at the end of the day, assume session might get stolen, and think now what?

One advanced solution for Session hijacking is synchronization token; in this way, every time the client browser makes a HTTP request to the server, the server sends back a new random complex enough token to the client as a hidden form field value, and the client must submit this value in the next request as a hidden form value. If the client submits the right session (e.g., stolen from the cookie), but does not have the most recent synch token, then there is something wrong. This solution also prevent cross-site request forgery. If you are over SSL, this solution cannot be broken by man in the middle either.

Goli E
  • 895
  • 1
  • 11
  • 20
  • Yes, the random token used as an anti-forgery protection is a good example. The point to note is that you don't just rely on the session cookie. You can use other information available in the headers and form fields as well as doing things like limiting the lifetime of the session cookie. – Tim X Feb 13 '15 at 08:07
1

No, if the session id is long enough and has enough entropy.
If that still concerns you then you can cryptographically sign cookies using a secret key.
But signing cookies won't have much effect:
As if the signature is 128 bits long and the cookie is also 128 bits long then
the cookie can be thought of a 256 bit long cookie.

AVX-42
  • 121
  • 4