312-50 Question 255
Select 3▪ Session Hijacking CountermeasuresA financial services company discovers that an attacker on the same public Wi-Fi network as remote employees was able to replay a stolen web session cookie and access an internal HR portal without knowing the user's password. The portal already uses HTTPS for login, but security testing shows that once authenticated, the same session ID remains valid for hours and is accepted from any client IP and browser. As a countermeasure plan, which THREE actions would most effectively reduce the risk of session hijacking while preserving normal browser-based access?
- A
Regenerate the session ID immediately after successful authentication and again after privilege changes, while expiring old tokens server-side
- B
Mark session cookies with Secure and HttpOnly flags and enforce HTTPS across the entire authenticated session
- C
Bind each session strictly to the source IP address so any IP change immediately invalidates the session
- D
Implement short idle and absolute session timeouts, and require reauthentication for sensitive actions
- E
Store the user's password in an encrypted cookie so the server can verify the session has not been modified
Show answer and explanation
Correct answers: A, B, D
Explanation
The best answer is to strengthen server-side session management and cookie protection rather than rely on fragile client attributes. In this scenario, the main weaknesses are long-lived reusable session IDs and insufficient protection of authenticated sessions. Effective countermeasures include regenerating session IDs after login or privilege changes, invalidating previous tokens, protecting cookies with Secure and HttpOnly attributes, enforcing HTTPS everywhere in the authenticated workflow, and limiting session lifetime with idle and absolute timeouts. Reauthentication for sensitive functions further reduces impact if a token is stolen. These practices align with OWASP guidance on Session Management and Authentication, which emphasizes unpredictable session identifiers, transport protection, cookie security attributes, session expiration, and renewal after authentication events. Strict source-IP binding is often operationally brittle and can harm usability without reliably stopping attackers in modern network environments.
- A. Correct.
Correct. Regenerating the session identifier after authentication and privilege elevation is a standard defense against session fixation and reduces the usefulness of pre-obtained identifiers. Invalidating the old token server-side prevents parallel reuse. This is a practical and widely recommended session management control for web applications.
- B. Correct.
Correct. The Secure flag helps ensure cookies are only sent over HTTPS, reducing exposure on unencrypted channels. HttpOnly helps mitigate client-side script access to session cookies, lowering the impact of some XSS-related theft. Enforcing HTTPS for the entire authenticated session is important because protecting only the login page still leaves the session vulnerable if cookies are later transmitted insecurely.
- C. Incorrect.
Incorrect. Although IP binding can sometimes detect anomalous reuse, strict binding to source IP is often unreliable in real environments because of mobile users, NAT, VPN changes, carrier-grade NAT, and proxy infrastructure. It can cause legitimate session breakage and is not one of the most effective primary countermeasures for general browser-based access. A risk-based device/session context check may be used, but strict IP lock is not the best answer here.
- D. Correct.
Correct. Short idle timeouts and absolute session lifetimes reduce the window in which a stolen session can be abused. Reauthentication for sensitive actions adds another layer if a session token is stolen. This is a practical countermeasure commonly recommended for high-value applications such as HR and financial systems.
- E. Incorrect.
Incorrect. Passwords should not be stored in client-side cookies, even if encrypted. This creates unnecessary credential exposure risk and does not solve session hijacking. Session integrity should be enforced with secure, random session tokens managed server-side, not by placing reusable credentials in the browser.