Can't a user change his session information to impersonate others?

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).

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.

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.