312-50 Question 256
Select 2▪ Session Hijacking CountermeasuresA company discovers that users of its internal web portal remain logged in even after moving between office Wi-Fi segments. During a security assessment, an ethical hacker demonstrates that if a session cookie is captured on an untrusted network, the cookie can be replayed from another device to access the victim's account without knowing the password. The development team wants practical countermeasures that reduce the risk of session hijacking without breaking normal browser-based access. Which TWO actions would be the most effective?
- A
Set the session cookie with the Secure and HttpOnly attributes, enforce HTTPS across the application, and regenerate the session ID after authentication
- B
Store the user's password in an encrypted cookie so the server can revalidate the user on every request
- C
Configure short session timeouts, invalidate the session on logout, and reject reused or old session IDs after reauthentication
- D
Bind each session permanently to the client's source IP address so roaming users cannot continue their session from another network
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to combine secure cookie handling and transport protections with sound session lifecycle management. In this scenario, the main problem is replay of a captured session token. The most effective practical countermeasures are to protect the token from exposure in transit, reduce client-side access to it, rotate it appropriately, and limit its lifetime and reuse. Specifically, HTTPS plus the Secure flag protects cookies from being sent over unencrypted channels; HttpOnly helps reduce theft through JavaScript; and session ID regeneration after login mitigates fixation. Short timeouts and server-side invalidation reduce the usefulness of stolen tokens. These recommendations align with OWASP Session Management Cheat Sheet and common web security best practices. Permanent IP binding is generally brittle and not a reliable primary control for browser sessions, while storing passwords in cookies is an anti-pattern and materially weakens security.
- A. Correct.
Correct. This is a strong, practical defense-in-depth measure. Enforcing HTTPS helps prevent session cookie exposure in transit, while the Secure attribute ensures the cookie is only sent over HTTPS. HttpOnly reduces the risk of client-side script access to the cookie, helping against theft via XSS. Regenerating the session ID after authentication helps prevent session fixation, which is closely related to session hijacking. These are standard web-session protections recommended in security best practices such as OWASP guidance.
- B. Incorrect.
Incorrect. Storing a password, even encrypted, in a cookie is poor practice and increases risk rather than reducing it. Cookies should not contain reusable credentials. If the cookie is stolen, the attacker may still gain value from it, and password handling becomes more dangerous. Proper session management relies on server-side session validation and secure session tokens, not client-side storage of user passwords.
- C. Correct.
Correct. Short idle and absolute timeouts reduce the window in which a stolen token remains useful. Explicit invalidation on logout ensures the server-side session is terminated rather than relying only on client behavior. Rejecting old or previously issued session identifiers after reauthentication helps prevent fixation and replay of stale tokens. These controls are widely recognized as effective countermeasures for limiting session hijacking impact.
- D. Incorrect.
Incorrect. Binding a session rigidly to a source IP may seem helpful, but in practice it often causes usability and reliability problems because users may roam between networks, use mobile carriers, sit behind NAT, or traverse proxies. It can also create false positives without fully preventing hijacking in environments where attackers share the same upstream network characteristics. It is sometimes used as a supplemental signal, but not as a primary or permanent binding mechanism in normal browser-based applications.