312-50 Question 325
Single answer▪ Attack Session Management MechanismDuring an authorized web application assessment, you exploit a reflected XSS flaw in an internal HR portal. The application uses a session cookie without the HttpOnly attribute, and employees access the portal over HTTPS. Your goal is to demonstrate the impact by taking over a victim's authenticated session without knowing their password. Which action is the MOST appropriate attack session management technique to use in this scenario?
- A
Use the XSS payload to read the victim's session cookie from the browser and send it to a controlled server, then replay that cookie in your browser to hijack the session
- B
Perform an ARP spoofing attack to downgrade the victim's HTTPS connection to HTTP and capture the password in cleartext
- C
Run a brute-force attack against the session ID until a valid authenticated token is found
- D
Force the server to regenerate a new session ID for the victim and use that new token to log in as the user
Show answer and explanation
Correct answer: A
Explanation
The best answer is to steal and replay the victim's session cookie using the reflected XSS vulnerability. In attack session management terms, this is session hijacking through token theft. The key technical clue is that the session cookie does not have the HttpOnly attribute, which means JavaScript running in the page context can access it. If the application also does not bind the session to additional controls, replaying that token from another browser may successfully impersonate the user. By contrast, ARP spoofing does not defeat properly implemented TLS, brute-forcing strong session IDs is not the practical choice here, and session fixation is a different attack pattern used before or during authentication, not after stealing an existing authenticated session. Relevant best practices from OWASP Session Management and Cross-Site Scripting guidance include setting HttpOnly and Secure on session cookies, rotating session IDs appropriately, validating sessions server-side, minimizing XSS exposure with output encoding and CSP, and using strong, unpredictable session identifiers.
- A. Correct.
Correct. This is a classic session hijacking approach using XSS to steal a session token when the cookie is accessible to client-side scripts. Because the cookie lacks the HttpOnly flag, malicious JavaScript can read document.cookie and exfiltrate the active session identifier. Replaying that valid session token in the tester's browser can allow authenticated access as the victim, demonstrating a failure in session management and cookie protection.
- B. Incorrect.
Incorrect. ARP spoofing is a network-layer man-in-the-middle technique, but it would not normally let you downgrade a properly configured HTTPS session and read credentials in cleartext. HTTPS protects the contents of the session with TLS. This option confuses network interception with application-layer session theft via XSS.
- C. Incorrect.
Incorrect. Although weak session IDs can sometimes be predicted or brute-forced in poorly designed applications, this is generally impractical against modern applications with sufficiently random session tokens. More importantly, the scenario already gives a direct and realistic path: XSS plus a non-HttpOnly session cookie. Choosing brute force ignores the most efficient and appropriate technique.
- D. Incorrect.
Incorrect. Session fixation involves forcing a known session ID on a victim before authentication so the attacker can later reuse it. In this scenario, the victim is already authenticated, and the issue is accessible session cookies via XSS. Attackers do not typically 'regenerate a new session ID for the victim' and then automatically gain access that way. This option misstates how fixation works.