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