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!"
    – dan
    Commented Oct 19, 2016 at 14:47
  • 8
    Yes, yes they can.
    – Awn
    Commented Oct 19, 2016 at 15:59
  • 23
    Yes, yes they can.
    – user15392
    Commented Oct 19, 2016 at 19:48
  • 1
    How do you get the database ID of another legitimate user? Commented Oct 19, 2016 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
    Commented Oct 20, 2016 at 9:46

6 Answers 6


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
    Commented Oct 20, 2016 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. Commented Oct 20, 2016 at 10:33
  • 1
    "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
    Commented Oct 20, 2016 at 13:32
  • 2
    ahh, thanks @Turnerj, I had forgotten where things were in the stack. Commented Oct 20, 2016 at 13:36
  • 2
    Tom Scott has a really good analysis of the Moonpig issue.
    – TRiG
    Commented Oct 21, 2016 at 10:32

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
    Commented Oct 20, 2016 at 9:19
  • 4
    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. Commented Oct 20, 2016 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.

  • 4
    …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
    Commented Oct 20, 2016 at 9:23
  • 5
    @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
    Commented Oct 20, 2016 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
    Commented Oct 20, 2016 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
    Commented Oct 20, 2016 at 13:20
  • 2
    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
    Commented Oct 20, 2016 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
    Commented Oct 20, 2016 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. Commented Oct 21, 2016 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 :)

  • 1
    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
    Commented Oct 19, 2016 at 15:56
  • 1
    Is this answer not suggesting mitigations for how to prevent an attacker interrupting legitimate cookies to copy/impersonate?
    – kwah
    Commented Oct 20, 2016 at 9:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .