Session-ID

A session ID ( session identifier English, German session ID ) is used in applications to stateless protocols as an identification mark to identify several related requests of a user and assign a session. In particular, for Web applications, see session IDs wide use.

On the World Wide Web services of any kind using the HTTP protocol are offered. These services are often composed of several related requests and responses. To buy something, for example, in a webshop, the user Browsed browsing the catalog, can be some Mark item in your shopping cart and then execute the order.

So complicated operations are not directly supported by HTTP, because it is a stateless protocol. An HTTP request returns a single website only and does not remember which user belongs to. To summarize several such requests and assign the user with each request a session ID is sent along. This session ID can remember and then assign the individual requests a joint session of the web application.

In general, the session automatically after a certain time (timeout) or by logging out is terminated and the session ID is deleted. It is therefore not possible, the current state of a session - to save and later recall them - for example by applying a bookmark. This restriction may be intended by the operator of the service, to prevent direct linking to individual pages of his offer (" Deep Links ").

Function

The session ID, and session ID is generated by the server at the beginning of a session (session). The session ID must be sent with the response from the server to the client and are delivered from this with any further access to the server. Using the unique session ID, the server-side data stored ( example: shopping cart) can be unambiguously associated with a user on each access.

So the session ID must be re- transmitted to the client with any 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 its previous session.

Realization

Technically, the transmission of session ID in the context of HTTP by so-called cookies, paste in the URIs or hidden form fields can be achieved.

Since the function of a cookie from the server can not be assumed, many applications support both forms of transmission: In the first response, the session ID is transmitted both as a cookie and in the URIs. If the next request, the session ID in a cookie, the URIs for the remainder of the session will not be modified.

Transmission in the HTTP header ( cookie)

Cookies are an extension of HTTP that has been developed for solving such problems. The server can have its response ( HTTP response ) send a small data packet to the browser that this in any other request ( HTTP request ) is send them along to the same server again.

The session ID transmission with cookies so only requires the one-time transfer the session ID from the server to the client, all subsequent requests contain the session ID. One advantage is that the session ID is maintained even when static web pages or images.

The problem with this approach is that cookies can remain even across the restart of the browser away, and are used by some companies to collect data about the user. For this reason, some users have disabled the acceptance of cookies in your browser. Some Web applications have, in turn, explicitly point out that the acceptance of cookies to be enabled - for example, to sign up.

Transmission in the URI

As a result of a user requests usually take place by clicking a link or submitting of a form, the session ID can also be transmitted that each URI is modified within a web page so that it contains the session ID.

For this purpose, two approaches used:

Session ID in a URI

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

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

A session ID can be sent to the server also similar to the transmission in the query part of a URI in the data portion of an HTTP request. To this end, the session ID is transmitted when submitting an HTML form using the POST method. In general, the session ID in a hidden form field ( input elements of type " hidden" ) is stored. Because also of the HTML source code needs to be modified, this method may additionally or alternatively to transfer in the URI can be used.

Store the session information on the server

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

/ tmp/sess_hvb0es1qdv5o91ogspmfk9ck77 UserID | i: 212; cart content | a: 2: {i: 0; s: 8: " Article 1 "; i: 1; s: 8: " Article 2 ";} But session data can be stored in other ( central ) locations, for example on network drives, into a memcached or database, most Webprogrammiersprachen support this.

Security

What type of transmission is chosen for the session ID, in effect, the server trusts that the client has the same ID back ends, which was transferred to him. A user can, however, since it controls the client side, return any session ID. If this Session ID match that of another user, the spying and manipulating the data of other users is possible.

It is therefore of utmost importance that session IDs can not be guessed. This is usually achieved by the session ID is randomly selected from a range of values ​​is so large that it can not be searched, and the probability of randomly encountering a session ID currently in use is extremely low.

Possible attacks on an existing session are described in Session Hijacking. The approach, as an attacker to create a valid session and another user foist is called session fixation.

724697
de