Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

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

ID: 655867 • Letter: C

Question

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 !

Explanation / Answer

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.