Norman is sort of close but not quite there.
The session id is merely some sort of unique number/string which in turn is used to load session information for a given session. In other words, it's used to distingush one user from another.
The session id has to somehow come from the client because the server itself does not remember who made what request. Typically, the session id is stored as a cookie on the client. But it could be stored in POST or GET data.
So given that the session id is stored on the client and is transmitted to the server on each request then it is possible for someone to intercept it. This in turn could allow that someone to pretend to be another user. It's not real easy to intercept a session id (unless you have direct access to the clients computer) but it can be done.
There are some things that can be done to help protect against session hijacking. You can for example store the ip address of the client's computer in the session data and check that it has not changed. Not a perfect solution (ip's can be spoofed plus users behind firewalls often share the same public ip) but it helps.
Finally, note that having a session id does not automatically give the client the ability to directly modify session data. They still need to go through your web application so session data itself is secure unless you allow the user to change it.
