This depends on the webserver used. If we take PHP on Unix as an example it may store the session on the filesystem in the /tmp folder. It creates a file here with the name of the users session ID prefixed with sess_ (Example: /tmp/sess_9gk8f055hd61qll6a8pjpje2n2).The contents of the session can be optionally encrypted before being placed on the browser. For Apache sessions (not necessarily PHP) you may use the mod_session_crypto module (Read more here).
The owner of the session can not change the session variables as he feels like unless the application allows him to do it. The application logic has to provide means to change the session in order for the user to change the variables.
The session object is never transmitted to the client and only a reference to the session (e.g. PHPSESSID) is passed to the client. The session ID should have high entropy and minimum 16 bytes of length in order to be very hard to guess. See OWASP Top 10 - Broken authentication and session management for more information about that. Also see this OWASP Cheat sheet for specific information on how to secure sessions.
Attacks against session storage:
If there exists a flaw like for example LFI (Local File Inclusion) it may be possible for an attacker to read their own and other users session objects by including the file on the file system. For example if the following example worked I could possibly read my own session data: