Can't an attacker just change his/her session (or cookie because it's stored locally) information then fool the server that he's the legitimate user?

Say for example, if a website uses the database id as an identifier, the attacker logs in to his account to get his cookie. Then just modify his ID to impersonate another legitimate user.

  • 1
    Could you explain more precisely what is your purpose and the context of your problem? Otherwise the answer you will win might be as short as your question: "Yes of course!" – daniel Azuelos Oct 19 '16 at 14:47
  • 7
    Yes, yes they can. – Awn Oct 19 '16 at 15:59
  • 22
    Yes, yes they can. – drewbenn Oct 19 '16 at 19:48
  • 1
    How do you get the database ID of another legitimate user? – immibis Oct 19 '16 at 21:40
  • 1
    @immibis Not quite that he asked about that, but they are usually an auto-incremental integer. Meaning they are sequential, and in the vast majority of the cases the main administrative user has the ID of 1. They're also used in URLs, to open up a users' profile page and so forth. In short, the user ID is not secret information. – ChristianF Oct 20 '16 at 9:46

Yes, if you can guess another user's session key then you can become them. This is why you need to have a unpredictable session key that can be revoked.

There have been cases where best practice haven't been followed, for example Moonpig produced an API which used a session key that was the user's ID which is set on account creation as a consecutive number. This meant that you could be any user. If that user wanted to stop you, they couldn't as it is the key for all the sessions they are engaged in and can't be changed as it is the unique ID for them within the Moonpig database.

This is a really good example of how to do it wrong. Session keys should be unpredictable and able to be thrown away (possibly able for one user to have many session keys).

As @Mindwin mentioned in the comments, the session key should be in the HTTP payload (cookies or form data [best practice is in cookies]) and not in the URL. This is because having session data in the URL makes it so you have to put it in the URL of every link, stops you from persisting a session if the user leaves and comes back, copying the URL and sending it to someone gives them your session data and there is a limit of characters that a URL can be.

You should also use HTTPS wherever possible so that an attacker can't snoop on the HTTP payload and get a copy of the session key that way (this is how Firesheep worked).

  • 1
    There have been cases where this hasnt happened, you probably wanted to write There have been cases where this has happened. – Bakuriu Oct 20 '16 at 10:12
  • 1
    I could see it that both could be used depending on how you interpret the first paragraph so i have slightly changed the wording to clarify what i was meaning. – Topher Brink Oct 20 '16 at 10:33
  • "This is because the URL is not encrypted when using HTTPS" Just to be clear, the URL is encrypted when using HTTPS but everything else you mention about sharing the link is true. – Turnerj Oct 20 '16 at 13:32
  • 2
    ahh, thanks @Turnerj, I had forgotten where things were in the stack. – Topher Brink Oct 20 '16 at 13:36
  • 2

Yes. It can.

Session information is stored in server side (except the session token) while cookies in the other way are stored in the client side (browser). So the attacker might change the session token to hijack a session.

The attack is commonly known as session hijacking through cookie manipulation. But the attacker must use a valid session token which can be found easily if a site is badly configured. A badly configured site might store a token in the url, or does not generate a random one etc...

Here are four main methods used to hijack a session :

  • Session fixation - When session id are being accepted from URL.
  • Session sidejacking - When the attacker can steal the session cookie through packet sniffing
  • Cross-site scripting - When the attacker hacks the users computer into running a code which is treated as trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.
  • Malware - Can hijack a browser to steal a it's cookie files without a user's knowledge.

The best practice to be protected would be to store the session token inside a cookie. However if the session token does not match strong criteria such as randomness, uniqueness, resistance to statistical and cryptographic analysis it might be possible for an attacker manipulate the session.

  • How about CSRF? Though the session token is not compromised, it is still used for session hijacking. – spectras Oct 20 '16 at 9:19
  • 3
    Session information need not be stored server-side; that's the usual implementation but it's not mandatory for security. Instead you can store it client-side (e.g. in cookies) with a cryptographic signature. – R.. Oct 20 '16 at 15:21

There seems to be some confusion between cookeis and session information here, so lets start by sorting that out:

  • Cookies are stored on the client. The user can therefore change them if they want to.

  • Session information is stored on the server. That means the user can not change it.

"Never trust the client" is an old rule in security. That means that you can never trust the information in the cookies - just because the username cookie has the value "Alice" does not mean that "Mallory" was not the one who logged in.

For that reason, vital information is generally not stored in cookies on the client but instead in the session on the server. You then use a cookie with a session ID to connect the two. The session ID is a long random number. If Alice session ID is 20349023490324 the server will have all her session information (such as her username) filed under that number.

The user could change session ID, but since there are so many possible session IDs it is extremely unlikely that she would guess an ID that is actually connected to a user.

In some cases you might want to store data in cookies anyway. To prevent the user from fiddling with them you could sign them with a key you only have on the server. Since the user does not have the key, the server will be able to detect any changes to the cookies since the signature no longer will match.

  • 3
    …which hints that protecting against brute-force session guessing is as important as protecting against brute-force password guessing. Interesting, because I don't believe it is taken as seriously. For instance, I often see questions about banning hosts after X failed login attempts, but rarely, if ever, after X invalid session tokens. – spectras Oct 20 '16 at 9:23
  • 4
    @spectras This depends on how much entropy there is in your session ID. If it is long and and random, the sun eventually exploding might be brute force protection enough. On the other hand, if it is short or not so random... – Anders Oct 20 '16 at 9:29

Session IDs need to be cryptographically safe in the sense that you cannot simply guess them. Usually, it is just a random looking 128-bit number and it has absolutely no obvious connection to the user it is identifying. So in order to impersonate someone else, you need to find the ID of that user. There are ways to do that but they are different to "just modify" it to become someone else.

The server, however, has a table matching real user information and the session ID belonging to that user so it can use that information. But you can never know someone else's session ID just by looking at the one that is stored in your browser.


So many answers seem to be saying that if the session id involves randomness, uniqueness, resistance to statistical and cryptographic analysis or some such, then its ok. This is not really true (as in not complete). A cookie (which contains that id) doesn't have to be guessed because it can be literally intercepted and reused by an attacker. There are also rare but possible instances of a proxy or dmz pass-through system mixing up cookies (I've seen it). For this reason, in addition to the above mentioned, you probably want your application itself to do something like:

On login have the system store the user-agent and ip address of the request in the server-side session. Check all subsequent requests and check that the incoming values for ip and user-agent match those stored in the session. If not, invalidate the server-side session and redirect to the login screen. This will prevent the hijacker from gaining entry. As an acceptable side-effect, the legitimate user will also be kicked out (only when a hijacking attempt occurs), but they can merely log back in.

  • 2
    Though as a user without a static IP, I would be quickly pissed off having to relog all the time. Especially if I have a long, secure password to type or 3-way scheme to go through everytime. Trade-offs I guess. – spectras Oct 20 '16 at 9:28
  • 1
    If the attacker can intercept the client's cookie, can he not also intercept and spoof the agent and IP address? – Fax Oct 20 '16 at 13:20
  • 1
    User agent doesn't add much security against active attackers, you're effectively just adding user agent to the session ID, as anyone who can read the session ID can probably also read and spoof the user agent. IP is a bit harder to spoof, but it can be done. The only real protection against this attack is to encrypt all communications with TLS (https). – thelem Oct 20 '16 at 15:52
  • 1
    The session cookie must be https-only, so that it cannot be literally intercepted and reused by an attacker. Mixing up cookies shouldn't be possible except hostile MITM doing it intentionally. – Peteris Oct 20 '16 at 19:32
  • 1
    If you're using your cellphone to access the site while in a train, you'll be hopping from tower to tower and likely to change IP address pretty frequently. IP pinning for sessions should be a great thing once IPv6 has fully replaced IPv4. – Menno van den Heuvel Oct 21 '16 at 7:45

Yes, sites that don't use cookies with the secure flag on, can suffer from cookie hijacking (on same network) and therefore can be impersonate by other users. Another security measure that the site can be use is keep tracking of users sessions and check how many sessions it as open at same time. Hope this answer you :)

  • I think you might have misunderstood the question. It is about a user changing their own cookies, and the secure flag will not help against that. – Anders Oct 19 '16 at 15:56
  • Is this answer not suggesting mitigations for how to prevent an attacker interrupting legitimate cookies to copy/impersonate? – kwah Oct 20 '16 at 9:03

protected by D.W. Oct 20 '16 at 18:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.