Session identifier

from Wikipedia, the free encyclopedia

A session identifier (also session ID , session ID or session ID , english session identifier , short English session ID ) is used in applications to stateless protocols for identification purposes to several related questions to identify a user and a session assigned. Session IDs are particularly widely used in web applications .

In the World Wide Web services of all kinds using the Hypertext Transfer Protocol offered (HTTP). These services often consist of several related requests and responses. In order to buy something in a web shop, for example , the user first browses through the catalog, can reserve some items in the shopping cart and then carries out the order.

However, such complicated processes are not directly supported by HTTP because it is a stateless protocol. An HTTP request only returns a single website and does not remember which user belongs to it. In order to combine several such requests and assign them to the user, a session ID is sent with each request. The web application can remember this and thus assign the individual requests to a joint session.

As a rule, the session is terminated automatically ( timeout ) or by logging out after a certain time and the session ID is deleted. It is therefore not possible to save the current status of a session - for example by creating a bookmark - and to call it up again later. This restriction can also be intended by the operator of the service in order to prevent direct linking to individual pages of its offer (“ deep links ”).

function

The Session ID is from the server to begin a session (English session generated). It must be transferred to the client with the response from the server and must be supplied by the client with each subsequent access to the server. With the help of the unique session ID, the data stored on the server (example: shopping cart) can be clearly linked to a user each time it is accessed.

The session ID must therefore be retransmitted to the client with each response from the server. A request that does not contain the session ID is seen as the first request of a new session, so the user loses his previous session.

realization

Technically, the session ID can be transmitted in the context of HTTP using so-called cookies , inserting them into the URIs or invisible form fields.

Since the server cannot assume the function of a cookie, many applications support both types of transmission: With the first response, the session ID is transmitted both as a cookie and in the URIs. If the next request contains the session ID as a cookie, the URIs are no longer modified for the rest of the session.

Transfer in the HTTP header (cookie)

Cookies are an extension of HTTP that was developed to solve such problems. With its response (HTTP response), the server can send a small data packet to the browser, which the browser will send back to the same server with every further request (HTTP request).

The session ID transfer with cookies only requires the one-time transfer of the session ID from the server to the client; all subsequent requests contain the session ID. One advantage is that the session ID is retained even with static websites or images.

The problem with this approach is that cookies can persist even after restarting the browser and are used by some companies to collect data about the user. For this reason, some users have deactivated the acceptance of cookies in their browser. In return, some web applications explicitly state that the acceptance of cookies must be activated in the browser - e.g. B. to register.

Transmission in the URI

Since follow-up inquiries from a user are usually made by clicking on a link or submitting a form, the session ID can also be transmitted by modifying each URI within a website so that it contains the session ID.

There are two common ways of doing this:

Session ID in a URI

Query
http://www.example.com/index?sid=edb0e8665db4e9042fe0176a89aade16
path
http://www.example.com/edb0e8665db4e9042fe0176a89aade16/index

The transmission of the session ID in the URI requires increased programming effort and there are various situations that can lead to the loss of the session. The session ID is also recorded in the server's log file.

Transmission in the data part of an HTTP request (HTML forms)

A session ID can also - similar to the transmission in the query part of a URI - be sent to the server in the data part of an HTTP request. To do this, the session ID is transferred when an HTML form is sent using the POST method . As a rule, the session ID is stored in a hidden form field ( inputelements of the type " hidden"). Because the HTML source code also has to be modified, this method can be used in addition or as an alternative to the transmission in the URI.

Storage of session information on the server

The data of a session, including both the session ID and the user data (user ID, shopping cart contents, etc.), is saved by the web server in a specific directory on the hard drive by default; it is often the temporary directory of the operating system ( /tmp). Such a file looks like this:

/tmp/sess_hvb0es1qdv5o91ogspmfk9ck77
UserID|i:212;Warenkorbinhalt|a:2:{i:0;s:8:"Artikel1";i:1;s:8:"Artikel2";}

Session data can also be stored in other (central) locations, for example on network drives, in a memcached or in a database. Most web programming languages ​​support this.

safety

Whichever transmission type is chosen for the session ID, the server ultimately trusts that the client will send back the same ID that was transmitted to it. However, since a user controls the client side, he can send back any session ID. If this session ID matches that of another user, it is possible to spy on and manipulate the data of other users.

So it is of the utmost importance that session IDs cannot be guessed. This is usually achieved by randomly selecting the session ID from a range of values ​​which is so large that it cannot be searched and the probability of accidentally stumbling across a session ID that is currently in use is extremely low.

Possible attacks on an existing session are described under Session Hijacking . The approach of creating a valid session as an attacker and passing it on to another user is known as session fixation .

Web links