From Wikipedia, the free encyclopedia

In computer science, in particular networking, a session is either a lasting connection using the session layer of a network protocol or a lasting connection between a user (or user agent) and a peer, typically a server, usually involving the exchange of many packets between the user's computer and the server. A session is typically implemented as a layer in a network protocol (e.g., telnet or FTP).

In the case of transport protocols which do not implement a formal session layer (e.g., UDP) or where sessions at the session layer are generally very short-lived (e.g., HTTP), sessions are maintained by a higher level program using a method defined in the data being exchanged. For example, an HTTP exchange between a browser and a remote host may include an HTTP cookie which identifies state, such as a unique session ID, information about the user's preferences or authorization level.

When a client may connect to any in a cluster of servers, a special problem is encountered in maintaining consistency when the servers must maintain session state. The client must either be directed to the same server for the duration of the session, or the servers must transmit server-side session information via a shared file system or database. Otherwise, the client may reconnect to a different server than the one it started the session with, which will cause problems when the new server does not have access to the stored state of the old one.

Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in embedded systems with no storage. The load-balancing problem can be solved by using a shared storage or by applying forced peering between each client and a single server in the cluster, hence compromising system efficiency and load distribution.

A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM to storage of session data. This method is applicable to situations with a limited number of clients (e.g. router or access point with infrequent or disallowed access to more than one client at a time).

In the two above-mentioned scenarios, usage of client-side sessions would provide net advantages over server-side sessions: in the first case by reducing the limitations applied to load-balancing algorithms (which usually translates to load distribution optimisation), and in the second case by allowing usage of sessions in web applications which cannot make use of RAM or disk space for storage due to necessity or choice.

Client-side sessions use Cookies and cryptographic techniques to transparently use sessions in scenarios.

At the end of execution of a dynamic web page, the value of session variables is calculated, compressed and transmitted to the client via a Cookie. At this stage the state resides entirely and only on the client file system (or RAM).

For each successive request, once it has been decompressed, the Cookie is forwarded to the server which uses it to "remember" the state of the application on that specific client.

Although this mechanism may suffice in some contexts, it cannot be adopted where confidentiality and integrity are necessary. If one wishes to use client-side sessions instead of server-side sessions, the following must be guaranteed:

1. confidentiality (optional): nothing apart from the server should access session information
2. data integrity: nothing apart from the server should manipulate session data (accidentally or maliciously)
3. authenticity: nothing apart from the server should be able to generate valid sessions

In order to accomplish this, the session data needs to be encrypted before being memorised on the client and modification of such information by any other party should be prevented via other cryptographic means.

A session token is a unique identifier (usually in the form of a hash generated by a hash function) that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier (a small piece of data which is otherwise meaningless and thus presents no security risk) - all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. Examples of the names that some programming languages use when naming their cookie include JSESSIONID (JSP), PHPSESSID (PHP), and ASPSESSIONID (Microsoft ASP).

Understanding Sessions in PHP

• Login session
• Session fixation
• Session poisoning