The sequence of interactions between client and server, or between user and system; the period during which a user is logged in or connected. used for authentication and also ensures security. The period of time a user interfaces with an application. Sessions are typically short-lived and connection-oriented communication. The user session begins when the user accesses the application and ends when the user quits the application.

The session of activity that a user with a unique IP address spends on a Web site during a specified period of time. The number of user sessions on a site is used in measuring the amount of traffic a Web site gets. The site administrator determines what the time frame of a user session will be (e.g., 30 minutes). If the visitor comes back to the site within that time period, it is still considered one user session because any number of visits within that 30 minutes will only count as one session. If the visitor returns to the site after the allotted time period has expired, say an hour from the initial visit, then it is counted as a separate user session. 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.

Contrast with unique visitor, hit, click-through and page view, which are all other ways that site administrators measure the amount of traffic Web site gets.

HTTP/1.0 was thought to only allow a single request and response during one Web/HTTP Session. Protocol version HTTP/1.1 improved this by completing the Common Gateway Interface (CGI), making it easier to maintain the Web Session and supporting HTTP cookies and file uploads.

Synchronization : This layer allows a process to add checkpoints which are considered as synchronization points into the data. These synchronization point help to identify the error so that the data is re-synchronized properly, and ends of the messages are not cut prematurely and data loss is avoided.

Dialog Controller : The session layer allows two systems to start communication with each other in half-duplex or full-duplex.

Session Initiation Protocol (SIP) based Internet phone call is a signaling protocol used for initiating, maintaining, and terminating real-time sessions that include voice, video and messaging applications. SIP is used for signaling and controlling multimedia communication sessions in applications of Internet telephony for voice and video calls, in private IP telephone systems, in instant messaging over Internet Protocol (IP) networks as well as mobile phone calling over LTE (VoLTE). SIP is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). A call established with SIP may consist of multiple media streams.

Software implementation :TCP sessions are typically implemented in software using child processes (subprocess/subtask) and/or multithreading, where a new process or thread is created when the computer establishes or joins a session. HTTP sessions are typically not implemented using one thread per session, but by means of a database with information about the state of each session. The advantage with multiple processes or threads is relaxed complexity of the software, since each thread is an instance with its own history and encapsulated variables.

web sessions /Server-side sessions : 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 some embedded systems with no storage. The load-balancing problem can be solved by using shared storage or by applying forced peering between each client and a single server in the cluster, although this can compromise system efficiency and load distribution.A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM for storage of session data. This method is applicable for servers 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).

Client-side web sessions : Client-side sessions use cookies and cryptographic techniques to maintain state without storing as much data on the server. When presenting a dynamic web page, the server sends the current state data to the client (web browser) in the form of a cookie. The client saves the cookie in memory or on disk. With each successive request, the client sends the cookie back to the server, and the server uses the data to “remember” the state of the application for that specific client and generate an appropriate response.This mechanism may work well in some contexts; however, data stored on the client is vulnerable to tampering by the user or by software that has access to the client computer. To use client-side sessions where confidentiality and integrity are required, the following must be guaranteed:

Confidentiality: Nothing apart from the server should be able to interpret session data.
Data integrity: Nothing apart from the server should manipulate session data (accidentally or maliciously).
Authenticity: Nothing apart from the server should be able to initiate valid sessions.

To accomplish this, the server needs to encrypt the session data before sending it to the client, and modification of such information by any other party should be prevented via cryptographic means. To improve efficiency and allow for more session data, the server may compress the data before creating the cookie, decompressing it later when the cookie is returned by the client.

HTTP session token

A session token is a unique identifier 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—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 HTTP cookie include JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI), and ASPSESSIONID (ASP).

Session Cookie

The session cookie is stored in temporary memory and is not retained after the browser is closed. Session cookies do not collect information from the users computer. They typically will store information in the form of a session identification that does not personally identify the user.

Session ID

Session identifier, session ID or session token is a piece of data (unique number) that is used in network communications (often over HTTP) to identify a session for a specific user for the duration a series of related message exchanges. session ID can be stored as a cookie, form field, or URL (Uniform Resource Locator). Some Web servers generate sessionIDs by simply incrementing static numbers. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP. For example, a buyer who visits a seller’s website wants to collect a number of articles in a virtual shopping cart and then finalize the shopping by going to the site’s checkout page. This typically involves an ongoing communication where several webpages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper’s cart, and a session ID is one way to achieve that goal.

Session IDs are often used to identify a user that has logged into a website, they can be used by an attacker to hijack the session and obtain potential privileges. A session ID is usually a randomly generated string to decrease the probability of obtaining a valid one by means of a brute-force search. Many servers perform additional verification of the client, in case the attacker has obtained the session ID. Locking a session ID to the client’s IP address is a simple and effective measure as long as the attacker cannot connect to the server from the same address, but can conversely cause problems for a client if the client has multiple routes to the server (e.g. redundant internet connections) and the client’s IP address undergoes Network Address Translation

Session hijacking

also known as TCP session hijacking, a security attack on a user session over a protected network. The most common method of session hijacking is called IP spoofing, when an attacker uses source-routed IP packets to insert commands into an active communication between two nodes on a network and disguising itself as one of the authenticated users. This type of attack is possible because authentication typically is only done at the start of a TCP session. Another type of session hijacking is known as a man-in-the-middle attack, where the attacker, using a sniffer, can observe the communication between devices and collect the data that is transmitted.

Session management (process of keeping track of a user’s activity across sessions of interaction with the computer system)

keeping track of which applications are open and which documents each application has opened, so that the same state can be restored when the user logs out and logs in later. For a website, session management might involve requiring the user to re-login if the session has expired. It is also used to store information on the server-side between HTTP requests.

Desktop session management

A desktop session is all the windows currently running and their current content. Session management on Linux-based systems is provided by X session manager. On Microsoft Windows systems, session management is provided by the Session Manager Subsystem (smss.exe); user session functionality can be extended by third-party applications like twinsplay.

Browser session management

Session management is particularly useful in a web browser where a user can save all open pages and settings and restore them at a later date. To help recover from a system or application crash, pages and settings can also be restored on next run. Google Chrome, Mozilla Firefox, Internet Explorer, OmniWeb and Opera are examples of web browsers that support session management. Session management is often managed through the application of cookies.

Web server session management

Hypertext Transfer Protocol (HTTP) is stateless: a client computer running a web browser must establish a new Transmission Control Protocol (TCP) network connection to the web server with each new HTTP GET or POST request. The web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by the web developer to make the stateless HTTP protocol support session state. For a discussion of the methods used to accomplish this see HTTP cookie and Session ID.

Session management over SMS

Just as HTTP is a stateless protocol, so is SMS. As SMS became interoperable across rival networks in 1999, and text messaging started its ascent towards becoming a ubiquitous global form of communication, various enterprises became interested in using the SMS channel for commercial purposes. Initial services did not require session management since they were only one-way communications (for example, in 2000, the first mobile news service was delivered via SMS in Finland). Today, these applications are referred to as application-to-peer (A2P) messaging as distinct from peer-to-peer (P2P) messaging. The development of interactive enterprise applications required session management, but because SMS is a stateless protocol as defined by the GSM standards, early implementations were controlled client-side by having the end-users enter commands and service identifiers manually.

Start a PHP Session

A session is started with the session_start() function. Session variables are set with the PHP global variable: $_SESSION. Now, let’s create a new page called “demo_session1.php”. In this page, we start a new PHP session and set some session variables

<?php
// Start the session
session_start();
?>
<!DOCTYPE html>
<html>
<body>

<?php
// Set session variables
$_SESSION[“favcolor”] = “green”;
$_SESSION[“favanimal”] = “cat”;
echo “Session variables are set.”;
?>

</body>
</html> //source : w3school

Session poisoning

Session poisoning (also referred to as “session data pollution” and “session modification”) is a method to exploit insufficient input validation within a server application. Typically a server application that is vulnerable to this type of exploit will copy user input into session variables.

The underlying vulnerability is a state management problem: shared state, race condition, ambiguity in use or plain unprotected modifications of state values.

Session poisoning has been demonstrated in server environments where different, non-malicious applications (scripts) share the same session states but where usage differ, causing ambiguity and race conditions.

Session poisoning has been demonstrated in scenarios where attacker is able to introduce malicious scripts into the server environment, which is possible if attacker and victim share a web host.

Session poisoning was first discussed as a (potentially new) vulnerability class in the Full disclosure mailing list. Alla Bezroutchko inquired if “Session data pollution vulnerabilities in web applications” was a new problem in January 2006. However, this was an old vulnerability previously noted by others: “this is a classic state management issue” – Yvan Boily; “This is not new” – /someone.

Earlier examples of these vulnerabilities can be found in major security resources/archives such as Bugtraq, e.g.

July 2001, Serious security hole in Mambo Site Server version 3.0.X by Ismael Peinado Palomo of reverseonline.com
September 2005, PHP Session modification by unknown (from uw-team) and adam_i

Session pollution has also been covered in some articles, such as PHP Session Security, Przemek Sobstel, 2007.

Attack examples

Trivial attack scenario

An example code vulnerable to this problem is:

Session("Login") = Request("login")
Session("Username") = Request("username")

Which is subject to trivial attacks such as

vulnerable.asp?login=YES&username=Mary

This problem could exist in software where

User submits username / password to logon.asp
If password for Mary checks out, logon.asp forwards to vulnerable.asp?login=YES&username=Mary

The problem is that `vulnerable.asp` is designed on the assumption that the page is only accessed in a non-malicious way. Anyone who realizes how the script is designed, is able to craft an HTTP request which sets the logon user arbitrarily.

Exploiting ambiguous or dual use of same session variable

Alla Bezroutchko discusses a scenario where `$_SESSION['login']` is used for two different purposes.

In the login scripts, the session variable stores “This user is logged on”.
In the password reset scripts, the session variable stores “this user wants his password reset”.

A race condition was demonstrated, in which the reset scripts could be exploited to change the logged on user arbitrarily.

Exploiting scripts allowing writes to arbitrary session variables

Alla Bezroutchko discusses examples observed in development forums, which allows writing to arbitrary session variables.

The first example is

$var = $_GET["something"]; 
$_SESSION["$var"] = $var2;

(in which $_GET[“something”] is probably from a selection box or similar).

Attack becomes

vulnerable.php?something=SESSION_VAR_TO_POISON

Session poisoning attacks enabled by php.ini: register_globals = on

`php.ini: register_globals = on` is known to enable security vulnerabilities in several applications. PHP server administrators are recommended to disable this feature.

Note: Real-world examples of session poisoning in enabled by register_globals = on was publicly demonstrated in back in July 2001 article Serious security hole in Mambo Site Server version 3.0.X.

Second example by /someone is

if ($condition1) { 
  $var = 'SOMETHING'; 
}; 
if ($condition2) { 
  $var = 'OTHER'; 
}; 
$_SESSION["$var"] = $var2;

which is vulnerable if:

It is possible for attacker to cause both conditions to be false.
php.ini is misconfigured (register_globals = on), which allows $var default value to be controlled by GPC (GET, POST, or COOKIE) input.

Attack becomes

vulnerable.php?var=SESSION_VAR_TO_POISON

Exploit utilizing a shared PHP server (e.g. shared web hosting)

‘unknown’ of uw-team.org discusses a scenario where attacker and victim shares the same PHP server.

Attack is fairly easy:

The attacker first visits the victim’s page, and e.g. log on.
Attacker then uploads a PHP script to his account, and has it display context of $_SESSION (set by victim script).
Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it.
Attacker visits victim pages to see if anticipated exploit worked.

This attack only requires that victim and attacker share the same PHP server. The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.

Contrast with unique visitor, hit, click-through and page view, which are all other ways that site administrators measure the amount of traffic Web site gets.

HTTP/1.0 was thought to only allow a single request and response during one Web/HTTP Session. Protocol version HTTP/1.1 improved this by completing the Common Gateway Interface (CGI), making it easier to maintain the Web Session and supporting HTTP cookies and file uploads.

Dialog Controller : The session layer allows two systems to start communication with each other in half-duplex or full-duplex.

Confidentiality: Nothing apart from the server should be able to interpret session data.

Data integrity: Nothing apart from the server should manipulate session data (accidentally or maliciously).

Authenticity: Nothing apart from the server should be able to initiate valid sessions.

HTTP session token

Session Cookie

The session cookie is stored in temporary memory and is not retained after the browser is closed. Session cookies do not collect information from the users computer. They typically will store information in the form of a session identification that does not personally identify the user.

Session ID

Session hijacking

Desktop session management

Browser session management

Web server session management

Session management over SMS

Start a PHP Session

A session is started with the session_start() function. Session variables are set with the PHP global variable: $_SESSION. Now, let’s create a new page called “demo_session1.php”. In this page, we start a new PHP session and set some session variables

Session poisoning

The underlying vulnerability is a state management problem: shared state, race condition, ambiguity in use or plain unprotected modifications of state values.

Session poisoning has been demonstrated in server environments where different, non-malicious applications (scripts) share the same session states but where usage differ, causing ambiguity and race conditions.

Session poisoning has been demonstrated in scenarios where attacker is able to introduce malicious scripts into the server environment, which is possible if attacker and victim share a web host.

Earlier examples of these vulnerabilities can be found in major security resources/archives such as Bugtraq, e.g.

July 2001, Serious security hole in Mambo Site Server version 3.0.X by Ismael Peinado Palomo of reverseonline.com

September 2005, PHP Session modification by unknown (from uw-team) and adam_i

Session pollution has also been covered in some articles, such as PHP Session Security, Przemek Sobstel, 2007.

Attack examples

Trivial attack scenario

An example code vulnerable to this problem is:

Which is subject to trivial attacks such as

This problem could exist in software where

The problem is that vulnerable.asp is designed on the assumption that the page is only accessed in a non-malicious way. Anyone who realizes how the script is designed, is able to craft an HTTP request which sets the logon user arbitrarily.

Exploiting ambiguous or dual use of same session variable

Alla Bezroutchko discusses a scenario where $_SESSION['login'] is used for two different purposes.

In the login scripts, the session variable stores “This user is logged on”.

In the password reset scripts, the session variable stores “this user wants his password reset”.

A race condition was demonstrated, in which the reset scripts could be exploited to change the logged on user arbitrarily.

Exploiting scripts allowing writes to arbitrary session variables

Alla Bezroutchko discusses examples observed in development forums, which allows writing to arbitrary session variables.

The first example is

(in which $_GET[“something”] is probably from a selection box or similar).

Attack becomes

Session poisoning attacks enabled by php.ini: register_globals = on

php.ini: register_globals = on is known to enable security vulnerabilities in several applications. PHP server administrators are recommended to disable this feature.

Note: Real-world examples of session poisoning in enabled by register_globals = on was publicly demonstrated in back in July 2001 article Serious security hole in Mambo Site Server version 3.0.X.

which is vulnerable if:

Exploit utilizing a shared PHP server (e.g. shared web hosting)

‘unknown’ of uw-team.org discusses a scenario where attacker and victim shares the same PHP server.

Attack is fairly easy:

The attacker first visits the victim’s page, and e.g. log on.

Attacker then uploads a PHP script to his account, and has it display context of $_SESSION (set by victim script).

Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it.

Attacker visits victim pages to see if anticipated exploit worked.

This attack only requires that victim and attacker share the same PHP server. The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.

Share this:

The problem is that `vulnerable.asp` is designed on the assumption that the page is only accessed in a non-malicious way. Anyone who realizes how the script is designed, is able to craft an HTTP request which sets the logon user arbitrarily.

Alla Bezroutchko discusses a scenario where `$_SESSION['login']` is used for two different purposes.

`php.ini: register_globals = on` is known to enable security vulnerabilities in several applications. PHP server administrators are recommended to disable this feature.