If a web application keeps using the same session ID before and after login, an attacker may get the user to use a session ID the attacker prepared in advance and then, after the user logs in, impersonate the user with that ID. What is the most appropriate countermeasure against this attack?

Answer: B. Issue a new session ID when login succeeds and invalidate the previous ID

This attack is called session fixation. A web application recognizes a logged-in user by a session ID passed in a cookie or similar. If an attacker can get the user to use a session ID the attacker knows before login, and that ID continues to be used after login, the attacker can access the site as the user with the same ID. The countermeasure is to issue a new, unpredictable session ID at the moment login succeeds and invalidate the old one. The ID the attacker knew before login then becomes useless. Attacks that impersonate users by stealing or guessing session IDs in general are called session hijacking, and they are countered by combining measures such as making IDs sufficiently long random values, sending them only over HTTPS (the cookie's Secure attribute), and not putting them in URLs (where they easily leak through the Referer header or history). Sequential IDs are easy to guess and dangerous.

• A. Sequential IDs are easy to guess, increasing the risk of impersonating other users.
• B. Correct. Renewing the ID at login makes the ID the attacker knew in advance unusable.
• C. Session IDs in URLs easily leak through the Referer header, browsing history, shared links and so on.