312-50 Question 248
Single answer▪ Application-Level Session HijackingDuring an authorized web application assessment, you discover that an internal HR portal sets a session cookie after login without the HttpOnly attribute. The portal is also vulnerable to stored cross-site scripting (XSS) in an employee profile field. Management asks which attack path would most directly demonstrate application-level session hijacking against another authenticated user without needing to crack credentials or tamper with TCP/IP traffic. Which action should you take?
- A
Inject JavaScript into the vulnerable profile field to read document.cookie and send the victim's session token to a controlled server, then replay that token in your browser
- B
Launch an ARP spoofing attack to become the man-in-the-middle and force the server to renegotiate the victim's TLS session
- C
Perform a SYN flood against the HR portal so active sessions are dropped and users are forced to reauthenticate
- D
Use DNS cache poisoning to redirect the victim to a cloned HR portal and capture their password for later login
Show answer and explanation
Correct answer: A
Explanation
Application-level session hijacking focuses on taking over an authenticated session by obtaining and reusing session state, typically a session ID stored in a cookie or token. In this scenario, the combination of stored XSS and a cookie lacking the HttpOnly attribute creates a direct path: JavaScript executed in the victim's browser can access document.cookie and exfiltrate the session token. Replaying that token can allow the tester to impersonate the authenticated user if additional controls such as token binding, device checks, IP validation, reauthentication, or short session expiry are not in place. This aligns with widely accepted web security guidance from OWASP, especially the Cross Site Scripting Prevention Cheat Sheet and Session Management Cheat Sheet, which recommend setting HttpOnly to help prevent client-side script access to cookies, using Secure for HTTPS-only transport, and implementing robust session management controls. The key distinction is that this is an application-layer takeover of an existing session, unlike credential theft, denial-of-service, or lower-layer traffic manipulation.
- A. Correct.
Correct. This is a classic application-level session hijacking path: exploit stored XSS to execute in the victim's authenticated browser context, read the non-HttpOnly session cookie via document.cookie, exfiltrate it, and replay the stolen session identifier. This directly demonstrates hijacking of the existing authenticated session at the application layer, without needing to know the victim's password or interfere with lower-layer network traffic.
- B. Incorrect.
Incorrect. ARP spoofing is a network-layer man-in-the-middle technique, not the most direct application-level session hijacking method in this scenario. In addition, modern TLS prevents straightforward reading of protected cookie values unless other weaknesses exist. The scenario already provides an easier and more reliable application-layer path through stored XSS and a readable cookie.
- C. Incorrect.
Incorrect. A SYN flood is a denial-of-service attack. It may disrupt availability, but it does not help you take over an existing authenticated application session. This option reflects a misconception that forcing logouts or instability is equivalent to session hijacking.
- D. Incorrect.
Incorrect. DNS cache poisoning followed by a phishing-style credential capture is an account compromise approach, not session hijacking of an already established application session. It also depends on successfully deceiving the user and collecting credentials, which the scenario explicitly says is unnecessary.