312-50 Question 246
Single answer▪ Application-Level Session HijackingDuring an authorized web application assessment, you observe that the target application sets a session cookie named SESSIONID after login. The cookie is not marked HttpOnly, but it is marked Secure. The application reflects unsanitized input in a page viewed by authenticated users. To demonstrate application-level session hijacking with the least reliance on network-layer attacks, which action would most directly allow you to capture a victim user's active session token and reuse it in your browser?
- A
Inject a stored or reflected JavaScript payload that reads document.cookie and sends the SESSIONID value to a server you control, then import that cookie into your browser for the target site
- B
Perform ARP spoofing on the local subnet to downgrade HTTPS traffic and capture the SESSIONID value in transit
- C
Run a SYN flood against the application server so the victim is forced to reconnect and obtain a new session that you can predict
- D
Exploit DNS cache poisoning so the victim resolves the target site to your host and automatically reveals the server-side session store
Show answer and explanation
Correct answer: A
Explanation
The best answer is the XSS-based cookie theft approach because the scenario explicitly describes two key conditions for application-level session hijacking: an authenticated page reflects unsanitized input, and the session cookie lacks the HttpOnly attribute. According to common web security guidance, including OWASP recommendations, HttpOnly helps mitigate client-side script access to session cookies, while the Secure attribute only ensures cookies are sent over HTTPS. In real assessments, testers commonly demonstrate session hijacking by exploiting XSS to exfiltrate a session token, then replaying it in a browser or intercepting proxy. This scenario highlights the difference between application-layer flaws and network-layer interception techniques, which are less direct and often blocked by TLS when properly configured.
- A. Correct.
Correct. This is a classic application-level session hijacking path using cross-site scripting (XSS). Because the cookie is not marked HttpOnly, JavaScript running in the victim's browser can access document.cookie and exfiltrate the SESSIONID. The Secure flag only restricts transmission of the cookie to HTTPS connections; it does not prevent client-side scripts from reading it. Once captured, the tester can load the cookie into their own browser or proxy tool and attempt session replay, assuming no additional binding controls are in place.
- B. Incorrect.
Incorrect. ARP spoofing is a network-layer man-in-the-middle technique, not the most direct application-level method described in the scenario. In addition, properly implemented HTTPS prevents straightforward reading of cookie contents in transit. Downgrading HTTPS is generally not feasible unless the application is misconfigured and vulnerable to specific downgrade or mixed-content issues, which are not stated here.
- C. Incorrect.
Incorrect. A SYN flood is a denial-of-service attack and does not provide a practical method for capturing or predicting an authenticated user's session token. Modern session identifiers should be cryptographically strong and unpredictable, so forcing reconnections would not help an attacker obtain a valid token.
- D. Incorrect.
Incorrect. DNS cache poisoning may redirect a user to an attacker-controlled system, but it does not 'automatically reveal' a server-side session store. Session stores typically remain on the legitimate server. Without additional phishing, TLS certificate compromise, or application weaknesses, this does not directly yield the active SESSIONID for reuse.