Session Hijacking through sessionId brute-forcing possible?

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.

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.