Session hijacking
Taking over a session that another party has already authenticated, by capturing or predicting its identifiers, so the attacker is treated as the legitimate user.
Session hijacking lets an attacker skip authentication by taking over a session the real user has already authenticated. At the network level, the classic form targets a TCP connection: the attacker learns or guesses the sequence numbers that the two ends expect, which were set up in the three-way handshake, and injects packets that the receiver accepts as part of the conversation. At the application level, the target is the session token, usually a cookie, which can be captured by packet sniffing on an unencrypted connection, stolen through cross-site scripting, or fixed in advance so the user logs in with an identifier the attacker knows.
Two neighbours are often blurred. A replay attack resends captured traffic to repeat an action, while hijacking continues a live session. A man-in-the-middle attack places the attacker in the path for the whole exchange, which is one route to hijacking. Defences follow the method: encrypting the session with TLS, unpredictable sequence numbers (RFC 6528) and session identifiers, issuing a new identifier at login, marking cookies Secure and HttpOnly, and timing out idle sessions.
Exam relevance: a scenario in which an attacker gains access without credentials by using a victim’s existing session is likely to describe session hijacking. Candidates are expected to separate it from replay and to match each defence to the form it stops.