This scenario demonstrates a classic case of Session Fixation, a session hijacking technique explicitly covered under the CEH v13 Web Application Hacking module. Session fixation occurs when an attacker sets or predicts a valid session identifier and forces a victim to authenticate using that same session ID.
In the given question, two critical vulnerabilities are highlighted:
* The session ID is embedded in the URL
* The application does not regenerate the session ID after login
According to CEH v13, secure applications must regenerate session identifiers after successful authentication to prevent fixation attacks. If this does not occur, an attacker can craft a URL containing a known session ID and trick the victim into clicking it. Once the victim logs in, the attacker reuses the same session ID to gain unauthorized access.
CEH documentation states that session fixation is particularly effective when:
* Session IDs are passed via URL parameters
* Sessions persist across authentication
* Secure cookie attributes are not enforced
Other options are incorrect because:
* XSS-based cookie theft requires client-side script injection.
* DNS cache poisoning is unrelated to session management.
* CSRF exploits user trust but does not directly hijack sessions.
Thus, Session Fixation by pre-setting the token in a URL is the most effective attack in this case.