What Is Session Hijacking?

Session hijacking is an attack in which an adversary obtains the token identifying somebody else's authenticated session and then uses that token to act as the account holder. MITRE catalogues it as CAPEC-593, an entry that describes the adversary's method rather than a defect in any particular product.

Its list of related weaknesses carries a single CWE, improper authentication, naming the failure at about the broadest level a weakness entry can. Anything specific lives in the four methods filed underneath.

What a Pattern Entry Records That a Weakness Entry Cannot

Graded values appear on three of the fields in the entry. Likelihood of attack is marked High, with typical severity recorded as "Very High". Required skill is rated Low, on the reasoning that taking a poorly protected identity token is well-documented ground.

Prerequisites turn out to be thinner than those ratings suggest. The entry asks only for an application that uses sessions to carry authentication. What it asks of the attacker amounts to reaching that application over the network. No specific flaw appears in either field.

Three security properties are listed as scopes on the consequence table, confidentiality, integrity and availability together, against one impact. That impact is the gain of privileges, delivered by the token the moment the application accepts it. The pattern itself is filed under subverting access control, inside the software domain, which groups it with attacks on permission to act.

The Four Methods Filed Underneath It

Four detailed patterns descend from the entry, with session fixation among them. The others are reusing session identifiers, sidejacking a session on the network, and cross-site tracing. Ordinary usage narrows session hijacking to the capture case, where the catalog keeps all four under one parent.

Above it sits exploitation of trusted identifiers, a meta pattern covering any abuse of a value a system trusts to identify somebody. Another four patterns are recorded as able to precede hijacking; all of them attacks on HTTP message boundaries, request smuggling and response splitting among them.

Compromising the user's machine or the server and lifting the token from it is named as a route too, though the sidejacking page is where it appears. Neither a flaw in the application nor access to the traffic is needed there. Transport protections do nothing against it, since the token is read where it legitimately sits.

Cookie Hijacking on an Unencrypted Channel

One child covers the case that gave cookie hijacking its name. Session sidejacking describes an attacker reading session tokens out of traffic that was never encrypted, then presenting one of them to the application as the victim.

Five weaknesses are associated with that pattern, against one on the parent. Capture-replay authentication bypass is among them, alongside cleartext transmission and a cookie served over HTTPS without the Secure attribute. Not all of them have to be present, as noted in the note attached to that table.

Four prerequisites are listed on that page, describing a setting more than a defect. Shared WiFi, an active session, and the absence of a secure channel are the first three. The fourth asks for traffic that carries the token, either because the victim's request requires it or because the application keeps calling home asynchronously. No injection flaw is needed anywhere in the code, which sets it apart from types of web application attacks that turn on one.

When HttpOnly Is Already Set

Setting the HttpOnly attribute closes the obvious path, so cross site tracing exists to reach around it. The pattern becomes relevant once a cookie can no longer be read through the browser's document.cookie property, which is exactly what that attribute prevents.

A script in the victim's browser is made to issue an HTTP TRACE request, which goes around the restriction without defeating it. The server answers by returning the original request inside the body of its response, cookie headers and all. The cookie that could not be read directly is sitting in that body.

None of that works until four separate conditions are met. TRACE must be enabled on the server, scripting must be on in the browser, and the site must be open to cross-site scripting or to another route past the same-origin policy. The last of the four names HTTP as the protocol in use, though the description on the same page states that SSL offers no protection against the technique.

Likelihood is rated Medium on that page, where the parent and sidejacking are both High. Protection mechanism failure is the weakness it names first, ahead of incorrect use of privileged APIs.

How Is Session Hijacking Prevented?

The awkward part of session hijacking prevention is that the pattern names conditions, never a defective line to fix. Two mitigations appear on the entry itself. Tokens are to be encrypted and signed while in transit, with generation left to a mechanism carrying enough entropy, which the entry notes many standard servers already handle without being asked.

Every session is to time out; an inactive one is to be ended once that limit passes, and a fresh key is to be issued when the user signs back in. Sidejacking adds three of its own, encrypted transport, a token that changes on every transmission, and request sequencing so the server can spot a replay.

Both mitigations on the hijacking entry come down from the meta parent's list of seven. They are condensed versions of two. Among the five left behind are protecting an identifier used for authentication to the assurance level of an authentication token, and checking that every identifier is authentic while the system runs. The parent's timeout mitigation also names twenty minutes as its example, a figure the child drops.

One more opening sits in the execution flow, outside the mitigations entirely. Between discovering a token and exploiting it, the pattern records a middle step where the attacker inserts the found token to confirm it still works. That step is a request carrying a valid identifier from somewhere the session has never been.

A hijacked session is indistinguishable from a real one at the level of the token, because the token is real. Raven Runtime Prevention judges a request by what it does while the application runs, so actions a session had no reason to take are caught as they happen. Book a demo to watch that against a live session.

‍