312-50 Question 244
Single answer▪ Session Hijacking ConceptsDuring an authorized internal assessment, you discover that a legacy web application still allows authenticated access over unencrypted HTTP after login. While testing from the same switched office network segment as a target user, you capture traffic and notice the application sends a session cookie in cleartext on subsequent requests. You want to demonstrate a session hijacking risk with the least intrusive method and without needing the user's password. What is the most appropriate next step?
- A
Replay the captured session cookie in your own browser to impersonate the authenticated user session
- B
Use ARP spoofing to force a TCP reset, then predict the next TCP sequence number to take over the connection
- C
Crack the user's NTLM hash from captured traffic and log in as the user
- D
Exploit SQL injection in the login form to extract valid credentials and create a new session
Show answer and explanation
Correct answer: A
Explanation
This scenario tests recognition of the distinction between application-layer session hijacking and lower-level connection hijacking. When a web application transmits a session cookie over unencrypted HTTP, anyone able to observe the traffic can often reuse that cookie to assume the authenticated session. In practice, this is commonly called cookie hijacking or sidejacking. The most direct and least intrusive proof is to replay the captured cookie in a controlled manner and verify whether the server accepts it. Best practices from OWASP Session Management guidance and related web security standards emphasize protecting session identifiers in transit with TLS, marking cookies with the Secure attribute so they are not sent over HTTP, using HttpOnly to reduce client-side script access, and regenerating session IDs after authentication. This question focuses on applying the simplest effective technique based on the evidence gathered, rather than choosing a more complex or unrelated attack path.
- A. Correct.
Correct. If the application transmits the session identifier over HTTP in cleartext, capturing and replaying that cookie in another browser or proxy is a classic cookie-based session hijacking technique. It is the least intrusive option here because it demonstrates account impersonation without attacking the user's credentials or altering the application's authentication logic. In modern web applications, possession of a valid session token often equals authenticated access until the token expires or is invalidated.
- B. Incorrect.
Incorrect. TCP session hijacking through sequence number prediction is an older, lower-level technique and is not the most appropriate next step in this scenario. You already have the application-layer session token needed to impersonate the user. ARP spoofing and TCP takeover add unnecessary complexity and network impact, making this less suitable for a controlled demonstration when a simpler web-session hijack is available.
- C. Incorrect.
Incorrect. Cracking an NTLM hash is unrelated to the immediate risk described. The issue is not password recovery but session management weakness caused by transmitting the session cookie in cleartext. Even if credential material were somehow available, attempting to crack hashes would be more intrusive and slower than simply validating whether the exposed session token can be reused.
- D. Incorrect.
Incorrect. SQL injection targets input validation and backend query handling, not session hijacking. While SQL injection can sometimes lead to account compromise, it is a different class of vulnerability. The scenario already provides evidence of a session management flaw that allows impersonation without needing to attack the login form or obtain credentials.