312-50 Question 247
Single answer▪ Application-Level Session HijackingDuring an authorized web application assessment, you discover that an internal HR portal uses a session cookie named HRSESSID after login. The application is served over HTTP on the corporate LAN, and no HSTS policy is in place. While positioned on the same switched network segment as a test user, you capture the user's authenticated HTTP request and observe the HRSESSID value in cleartext. You are asked to demonstrate application-level session hijacking with the least additional interaction with the victim and without knowing the victim's password. Which action would most directly validate this weakness?
- A
Replay the captured HRSESSID cookie in your own browser for requests to the HR portal and attempt to access the victim's authenticated session
- B
Perform a TCP SYN flood against the HR portal so the victim reconnects and a new session token is generated
- C
Use SQL injection to extract the user table and recover the victim's password hash before logging in as the user
- D
Run a DNS zone transfer against the corporate DNS server to identify additional subdomains that may share authentication
- E
Capture the three-way TCP handshake and reuse the victim's source port and sequence numbers to take over the web session
Show answer and explanation
Correct answer: A
Explanation
The key indicator in this scenario is that the authenticated session cookie is exposed in cleartext because the application uses HTTP instead of HTTPS. In web applications, the session identifier is often the bearer token for authentication state: anyone who obtains it may be able to act as the authenticated user until the session expires or is invalidated. Therefore, the most direct proof of application-level session hijacking is to import or replay the captured cookie in a separate browser or proxy and verify whether the server accepts it.
This aligns with widely accepted web security guidance. OWASP's Session Management Cheat Sheet emphasizes that session IDs must be protected in transit with TLS and handled as sensitive authentication credentials. OWASP Transport Layer Security guidance also recommends enforcing HTTPS and HSTS to prevent interception and downgrade opportunities. If cookies are used for authenticated sessions, secure deployment typically includes HTTPS everywhere, the Secure attribute to prevent cookie transmission over HTTP, the HttpOnly attribute to reduce client-side script access, session rotation after authentication, and server-side invalidation controls.
The distractors are plausible because they involve adjacent attack categories familiar to CEH candidates, such as DoS, SQL injection, DNS reconnaissance, and TCP-level hijacking. However, the scenario asks for the most direct validation of application-level session hijacking with minimal victim interaction. That makes session cookie replay the correct answer.
- A. Correct.
Correct. Application-level session hijacking in a web context commonly involves capturing and reusing a valid session token, such as a cookie, to impersonate an authenticated user. Because the portal transmits the session cookie over HTTP in cleartext, replaying the HRSESSID value in your own requests is the most direct way to validate the finding with minimal interaction and without the victim's credentials. This demonstrates session hijacking at the application layer rather than attacking authentication itself.
- B. Incorrect.
Incorrect. A SYN flood is a denial-of-service technique, not a targeted method for validating application-layer session hijacking. It would increase impact unnecessarily, does not directly help you reuse the victim's authenticated session, and would be inappropriate when the goal is to demonstrate a specific session management weakness with minimal disruption.
- C. Incorrect.
Incorrect. SQL injection could potentially lead to account compromise, but it is a different vulnerability class entirely. The scenario already provides a captured valid session identifier, so extracting password hashes would be unnecessary and would not specifically demonstrate application-level session hijacking. This option reflects the misconception that any path to impersonation is equivalent to session hijacking.
- D. Incorrect.
Incorrect. DNS zone transfer may reveal information about internal naming and infrastructure, but it does not directly allow takeover of an existing authenticated web session. This is a reconnaissance technique, not a session hijacking validation step.
- E. Incorrect.
Incorrect. Reusing TCP sequence numbers and source ports relates to network-level or TCP session hijacking concepts, not application-level web session hijacking. In modern switched networks and TCP implementations, this is also far less practical than simply replaying an exposed HTTP session cookie. The scenario explicitly centers on an application session token, so the most relevant technique is cookie replay.