Home / Knowledge hub / Session hijacking
Knowledge hub
Session hijacking
Stealing the token that tells your application a browser is logged in.
What it means
Session hijacking means taking the token that tells your application a browser is already logged in, and then using it. Once somebody holds a valid session token, the application has no reason to doubt them.
A script running in your pages can steal it. So can malware on a device, an unprotected connection, or a generator predictable enough to guess.
Why it matters
No password enters this story, so password policies, resets and strength rules do nothing here. Multi-factor at login does not help either, because the attacker joins after that check has already passed.
Session tokens therefore deserve the same care as passwords: where you store them, how long they live, and how fast you can end one. Lifetime is a business decision as much as a technical one. Staying logged in for a month is convenient, and a stolen token then stays useful for a month.
How it shows up
The practical controls are dull and effective. Mark session cookies so scripts cannot read them and so they travel only over HTTPS, which RFC 6265 calls HttpOnly and Secure. Give them a lifetime, and end the session on the server at logout rather than only in the browser.
Then ask your own application an awkward question. If somebody stole a token right now, what would stop it and how would you know? For many applications the honest answers are nothing, and you would not. Recording where a session gets used at least lets you see one account in two places at once. Give people a way to end their own sessions as well. A list of active sessions with a sign out button costs little, and it answers the first question after a lost laptop.
Questions people ask
Session hijacking, answered
How do attackers steal session cookies?
Four routes cover most of it. A script injected into your pages through cross-site scripting. Malware on the user's device. An unprotected network connection. Identifiers predictable enough to guess.
Does HTTPS stop session hijacking?
It closes the network route, which genuinely matters.
It does nothing about a script reading the cookie, malware on the device, or a session that never expires on the server.
Does multi-factor authentication help against this?
Not really. Multi-factor runs at login, and the attacker turns up afterwards holding a token that already passed it.
Session lifetime and the ability to end a session quickly do far more here than anything at the login screen.
How long should a session last?
As long as the business can tolerate and no longer.
A month of staying signed in is convenient for your users, and a stolen token is then useful to an attacker for a month.
Could we tell if somebody hijacked a session?
Only if you record where sessions get used. With that, one account appearing in two places at once becomes visible.
Without it, nobody can answer the question after the fact, which is usually when somebody asks.
Sources
Where this comes from
Related
Terms that sit next to this one
Session fixation
An attacker sets your session id before login, then waits for it to work.
Token
A string that stands in for an identity or a permission.
Account takeover
An attacker ends up signed in as one of your real users.
JWT
A signed token a client carries to prove who is signed in.
XSS
An attacker's script running in your pages, in your customers' sessions.
Would you notice a stolen session?
Cyberlop tests authentication and session handling on every run, and it shows you the exact request that worked. Ask us to run it against one of your applications for 30 days.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.