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