In computer network security, session fixation attacks attempt to exploit

Exploit (computer security)

An exploit is a piece of software, a chunk of data, or sequence of commands that takes advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic...

 the vulnerability of a system which allows one person to fixate (set) another person's session

Session (computer science)

In computer science, in particular networking, a session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user . A session is set up or established at a certain point...

 identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs

Uniform Resource Locator

In computing, a uniform resource locator or universal resource locator is a specific character string that constitutes a reference to an Internet resource....

 (query string

Query string

In World Wide Web, a query string is the part of a Uniform Resource Locator that contains data to be passed to web applications such as CGI programs....

) or POST data.

Attack scenarios

Alice

Alice and Bob

The names Alice and Bob are commonly used placeholder names for archetypal characters in fields such as cryptography and physics. The names are used for convenience; for example, "Alice sends a message to Bob encrypted with his public key" is easier to follow than "Party A sends a message to Party...

 has an account at the bank http://unsafe/. Unfortunately, Alice is not very security savvy.

Mallory

Alice and Bob

The names Alice and Bob are commonly used placeholder names for archetypal characters in fields such as cryptography and physics. The names are used for convenience; for example, "Alice sends a message to Bob encrypted with his public key" is easier to follow than "Party A sends a message to Party...

 is out to get Alice's money from the bank.

Alice has a reasonable level of trust in Mallory, and will visit links Mallory sends her.

A simple attack scenario

Straightforward scenario:

1. Mallory has determined that http://unsafe/ accepts any session identifier, accepts session identifiers from query strings and has no security validation. http://unsafe/ is thus not secure.
2. Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe/?SID=I_WILL_KNOW_THE_SID". Mallory is trying to fixate the SID to I_WILL_KNOW_THE_SID.
3. Alice is interested and visits http://unsafe/?SID=I_WILL_KNOW_THE_SID. The usual log-on screen pops up, and Alice logs on.
4. Mallory visits http://unsafe/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account.

Attack using server generated SID

A misconception is that servers which only accept server generated session identifiers are safe from fixation. This is false.

Scenario:

1. Mallory visits http://vulnerable/ and checks which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2.
2. Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank, http://vulnerable/?SID=0D6441FEA4496C2."
3. Alice logs on, with fixated session identifier SID=0D6441FEA4496C2.

Attacks using cross-site cooking

Another session fixation attack, cross-site cooking

Cross-site cooking

Cross-site cooking is a type of browser exploit which allows a site attacker to set a cookie for a browser into the cookie domain of another site server....

, exploits browser vulnerabilities

Browser exploit

A browser exploit is a form of malicious code that takes advantage of a flaw or vulnerability in an operating system or piece of software with the intent to alter a user's browser settings without their knowledge...

. This allows the site
http://evil/ to store cookies in Alice's browser in the cookie domain of another server http://good/, which is trusted. This attack can succeed even when there is no vulnerability within http://good/, because http://good/ may assume that browser cookie management is secure.

Scenario:

1. Mallory sends Alice an e-mail: "Hey, check out this cool site, http://evil/".
2. Alice visits http://evil/, which sets the cookie SID with the value I_WILL_KNOW_THE_SID into the domain of http://good/.
3. Alice then receives an e-mail from Mallory, "Hey, check out your bank account at http://good/".
4. Once Alice logs on, Mallory can use her account using the fixated session identifier.

Attacks using cross-subdomain cooking

This is like cross-site cooking, except that it does not rely on browser vulnerabilities. Rather, it relies on the fact that wildcard cookies can be set by one subdomain that affect other subdomains.

Scenario:

1. A web site www.example.com hands out subdomains to untrusted third parties
2. One such party, Mallory, who now controls evil.example.com, lures Alice to her site
3. A visit to evil.example.com sets a session cookie with the domain .example.com on Alice's browser
4. When Alice visits www.example.com, this cookie will be sent with the request, as the specs for cookies states, and Alice will have the session specified by Mallory's cookie.
5. If Alice now logs on, Mallory can use her account.

Each of these attack scenarios has resulted in Cross-calation, where Mallory has successfully gained access to the functions and data normally reserved for Alice.

An alternate attack scenario does not require Alice to log in to a site. Rather, simply by fixing the session, Mallory may be able to spy on Alice and abuse the data she enters. For example, Mallory may use the above attacks to give Alice her own authenticated session—so Alice will start using the site with all the authentication of Mallory. If Alice decides to purchase something on this site and enters her credit card details, Mallory might be able to retrieve that data (or other confidential data) by looking through the historical data stored for the account.

Do not accept session identifiers from GET / POST variables

Session identifiers in URL (query string, GET variables) or POST variables are not recommended as they simplify this attack – it is easy to make links or forms which set GET / POST variables.

Additionally, session identifiers (SIDs) in query strings enable other risk and attack scenarios;

• The SID is leaked to others servers through the Referrer
• The SID is leaked to other people as users cut & paste "interesting links" from the address bar into chat, forums, communities, etc.
• The SID is stored in many places (browser history log, web server log, proxy logs, ...)

Note: Cookies are shared between tabs and popped up browser windows. If your system requires to be hit with the same domain (www.example.com?code=site1 and www.example.com?code=site2 ), cookies may conflict with one another between tabs.

It may be required to send the session identifier on the URL in order to overcome this limitation. If possible use site1.example.com or site2.example.com so there is not domain conflicts in the cookies. This may incur costs with extra SSL certificates.

This behavior can be seen on many sites by opening another tab and trying to do side by side search results. One of the sessions will become unusable.

Best solution: Identity Confirmation

This attack can be largely avoided by changing the session ID when users log in. If every "important" request requires the user to be authenticated with ("logged into") the site, an attacker would need to know the id of the victim's log-in session. When the victim visits the link with the fixed session id, however, they will need to log into their account in order to do anything "important" as themselves. At this point, their session id will change and the attacker will not be able to do anything "important".

A similar technique can be used to solve the phishing

Phishing

Phishing is a way of attempting to acquire information such as usernames, passwords, and credit card details by masquerading as a trustworthy entity in an electronic communication. Communications purporting to be from popular social web sites, auction sites, online payment processors or IT...

 problem. If the user protects their account with two passwords, then it can be solved to a great extent.

Solution: Store session identifiers in HTTP cookies

The session identifier on most modern systems is stored by default in an HTTP cookie

HTTP cookie

A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is used for an origin website to send state information to a user's browser and for the browser to return the state information to the origin site...

, which has a moderate level of security as long as the session system disregards GET/POST values. However, this solution is vulnerable to cross-site request forgery

Cross-site request forgery

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts...

.

Solution: Utilize SSL / TLS Session identifier

When enabling HTTPS

Https

Hypertext Transfer Protocol Secure is a combination of the Hypertext Transfer Protocol with SSL/TLS protocol to provide encrypted communication and secure identification of a network web server...

 security, some systems allow applications to obtain the SSL / TLS

Transport Layer Security

Transport Layer Security and its predecessor, Secure Sockets Layer , are cryptographic protocols that provide communication security over the Internet...

 session identifier. Use of the SSL/TLS session identifier is very secure, but many web development languages do not provide robust built-in functionality for this.

SSL/TLS session identifiers may be suitable only for critical applications, such as those on large financial sites, due to the size of the systems. This issue, however, is rarely debated even in security forums.

Regenerate SID on each request

A countermeasure against session fixation is to generate a new session identifier (SID) on each request. If this is done, then even though an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID. Implementation of such a system is simple, as demonstrated by the following:

• Get previous Session Identifier OLD_SID from HTTP request.
• If OLD_SID is null, empty, or no session with SID=OLD_SID exists, create a new session.
• Generate new session identifier NEW_SID with a secure random number generator.
• Let session be identified by SID=NEW_SID (and no longer by SID=OLD_SID)
• Transmit new SID to client.

Example:

If Mallory successfully tricks Alice into visiting http://victim/?SID=I_KNOW_THE_SID, this HTTP request is sent to victim:

GET /?SID=I_KNOW_THE_SID HTTP/1.1

Host: victim

victim accepts SID=I_KNOW_THE_SID, which is bad. However, victim is secure because it performs session regeneration. victim gets the following response:

HTTP/1.1 200 OK

Set-Cookie: SID=3134998145AB331F

Alice will now use SID=3134998145AB331F which is unknown to Mallory, and SID=I_KNOW_THE_SID is invalid. Mallory is thus unsuccessful in the session fixation attempt.

Unfortunately session regeneration is not always possible. Problems are known to occur when third-party software such as ActiveX or Java Applets are used, and when browser plugins communicate with the server. Third-party software could cause logouts, or the session could be split into two separate sessions.

Accept only server-generated SIDs

One way to improve security is not to accept session identifiers that were not generated by the server. However, as noted above, this does not prevent all session fixation attacks.

if (!isset($_SESSION['SERVER_GENERATED_SID'])) {
session_destroy; // destroy all data in session
}
session_regenerate_id; // generate a new session identifier
$_SESSION['SERVER_GENERATED_SID'] = true;

Logout function

A logout function is useful as it allows users to indicate that a session should not allow further requests. Thus attacks can only be effective while a session is active. Note that the following code performs no Cross-site request forgery

Cross-site request forgery

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts...

 checks, potentially allowing an attacker to force users to log out of the web application.

if (isset($_GET['LOGOUT']))
session_destroy; // destroy all data in session

Time-out old SIDs

This defense is simple to implement and has the advantage of providing a measure of protection against unauthorized users accessing an authorized user's account by using a machine that may have been left unattended.

Store a session variable containing a time stamp of the last access made by that SID. When that SID is used again, compare the current timestamp (in PHP you can get this by using the time function call) with the one stored in the session. If the difference is greater than a predefined number, say 5 minutes, destroy the session. Otherwise, update the session variable with the current timestamp.

Destroy session if Referrer is suspicious

When visiting a page, most browsers will set the Referrer – the page that contained the link that you followed to get to this page.

When the user is logged into a site that is not likely to be linked to from outside that site (e.g., banking websites, or webmail), and the site is not the kind of site where users would remain logged in for any great length of time, the Referrer should be from that site. Any other Referrer should be considered suspicious. However, if the originating request is from a HTTPS page, then the referrer will be stripped. So you cannot depend on this security system.

For example, http://vulnerable/ could employ the following security check:

if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable/') ! 0) {
session_destroy; // destroy all data in session
}
session_regenerate_id; // generate a new session identifier

Verify that additional information is consistent throughout session

One way to further improve security is to ensure that the user appears to be the same end user (client). This makes it a bit harder to perform session fixation and other attacks.

As more and more networks begin to conform to RFC 3704 and other anti-spoofing

Spoofing attack

In the context of network security, a spoofing attack is a situation in which one person or program successfully masquerades as another by falsifying data and thereby gaining an illegitimate advantage.- Spoofing and TCP/IP :...

 practices, the IP address becomes more reliable as a "same source" identifier. Therefore, the security of a web site can be improved by verifying that the source IP is consistent throughout a session.

This could be performed in this manner:

if($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {
session_destroy; // destroy all data in session
}
session_regenerate_id; // generate a new session identifier
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

However, there are some points to consider before employing this approach.

• Several users may share one IP. It is not uncommon for an entire building to share one IP using NAT
  Network address translation
  In computer networking, network address translation is the process of modifying IP address information in IP packet headers while in transit across a traffic routing device....
  
  .
• One user may have an inconsistent IP. This is true for users behind proxies (such as AOL
  AOL
  AOL Inc. is an American global Internet services and media company. AOL is headquartered at 770 Broadway in New York. Founded in 1983 as Control Video Corporation, it has franchised its services to companies in several nations around the world or set up international versions of its services...
  
   customers). It is also true for some mobile/roaming users.

For some sites, the added security outweighs the lack of convenience, and for others it does not.

User Agent

Browsers identify themselves by "User-Agent" HTTP headers. This header does not normally change during use; it would be extremely suspicious if that were to happen. A web application might make use of User-Agent detection in attempt to prevent malicious users from stealing sessions. This however is trivial to bypass, as an attacker can easily capture the victim's user-agent with their own site and then spoof it during the attack. This proposed security system is relying on Security through obscurity

Security through obscurity

Security through obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy of design or implementation to provide security...

.

if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) {
session_destroy; // destroy all data in session
}
session_regenerate_id; // generate a new session identifier
$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];

However, there are some points to consider before employing this approach.

• Several users may have same browser User Agent in Internet café
  Internet cafe
  An Internet café or cybercafé is a place which provides internet access to the public, usually for a fee. These businesses usually provide snacks and drinks, hence the café in the name...
  
  .
• Several users may have same default browser (ex: Internet Explorer 6 in Windows XP SP3 or mini browser in mobile phone).

But User Agent may change legally in few cases. Following examples are the same users. For example MSIE may change the UA string based on compatibility mode:

• Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
• Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2

• Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
• Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

• Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
• Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

Defense in Depth
Defense in depth

Defense in Depth (computing)

Defense in depth is an information assurance concept in which multiple layers of security controls are placed throughout an information technology system...

is to combine several countermeasures. The idea is simple: if one obstacle is trivial to overcome, several obstacles could be very hard to overcome.

A Defence in Depth strategy could involve:

• Enable HTTPS (to protect against other problems)
• Correct configuration (do not accept external SIDs, set time-out, etc.)
• Perform session_regeneration, support log-out, reject illegal referrers, etc.

The following PHP script demonstrates several such countermeasures combined in a Defence in Depth manner:

if (strpos($_SERVER['HTTP_REFERER'], 'https://DiD/') ! 0 ||
isset($_GET['LOGOUT']) ||
$_SERVER['REMOTE_ADDR'] !

$_SESSION['PREV_REMOTEADDR'] ||
$_SERVER['HTTP_USER_AGENT'] !

$_SESSION['PREV_USERAGENT'])
session_destroy;

session_regenerate_id; // generate a new session identifier

$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];
Note that this code checks the current REMOTE_ADDR (the user's IP address) against the REMOTE_ADDR of the previous request. This is in general a robust security practice, as it is likely that a user's IP address will remain the same from one request to the next, and that an attacker will register a different IP address. However, this may cause problems for legitimate users whose internet access is delivered via a proxy pool, where successive requests may be relayed via different proxies with different external IP addresses. Additionally, it provides no protection where the legitimate user and the attacker are behind the same proxy, in which case requests from both will originate from the same IP address.

External links

• Security Corner: Session Fixation
• Session Fixation Vulnerability in Web-based Applications (PDF)
• Session Fixation Video example
• Session Fixation Vulnerabilities The Web Application Security Consortium Threat Classification