CS3511 Cookies and Sessions

Simon Foley,
Department of Computer Science,
University College Cork
s.foley@cs.ucc.ie
November 7, 2011

c
Simon
Foley

1 / 44

Cookies
Cookies

The HTTP protocol is stateless.

setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

All HTTP requests are treated as independent events, even when they
come from the same client.
Cookies provide a mechanism whereby a web-server can manage a stateful
relationship with a browser by storing the related state in the client browser
and not on the server.
 The server assigns some state to a cookie, which it includes in the

HTTP response.
 The browser stores the cookie in its browser.
 The browser includes any cookie(s) it may hold for a web-site when

making an HTTP request to that website.

Cookies can be used to store a variety of information, for example visit
tracking information, authentication information, etc.

c
Simon
Foley

2 / 44

Cookie Example
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

A PHP script that is used to count the number of times a particular user
(browser) has loaded the script/web-page.
<?php
if (!isset($_COOKIE[views]))
{
setcookie(views,0,0,"/");
$views=1;
}else{
$views=$_COOKIE[views]+1;
}
setcookie(views,$views,0,"/");
echo "I have now seen you = ". $views . " times";
?>

c
Simon
Foley

3 / 44

HTTP Headers on first visit to web page

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

GET http://localhost/messAbout/visitCookie.php HTTP/1.1

....
Keep-Alive: 115
Proxy-Connection: keep-alive
User-Agent: Paros/3.2.13

HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 14:45:02 GMT
Server: Apache
X-Powered-By: PHP/5.3.2
Set-Cookie: views=1; path=/
Content-Length: 29
Content-Type: text/html

c
Simon
Foley

4 / 44

HTTP headers on second visit to web page

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

GET http://localhost/messAbout/visitCookie.php HTTP/1.1

....
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://localhost/messAbout/
Cookie: views=1
Cache-Control: max-age=0
User-Agent: Paros/3.2.13

HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 14:45:42 GMT
Server: Apache
X-Powered-By: PHP/5.3.2
Set-Cookie: views=2; path=/
Content-Length: 29
Content-Type: text/html

c
Simon
Foley

5 / 44

PHP setcookie
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

From the PHP documentation:

bool setcookie (string $name [, string $value [, int $expire = 0
[, string $path [, string $domain [, bool $secure = false
[, bool $httponly = false ]]]]]] )

setcookie(views,0) sets a cookie with identifier views to the value 0.

setcookie(views,0,0) indicates cookie expires at end of session.
setcookie(views,0,0,/thispath,foo.bar) indicates that the cookie
is included in HTTP requests to the domain foo.bar that include the path
/thispath. The domain must be a subset of the domain from which the
response comes (anything else will be rejected by browser).
setcookie(views,0,0,/thispath,foo.bar,true) indicates that the
cookie is sent over an HTTPS connection
setcookie(views,0,0,/thispath,foo.bar,true,true) indicates
cookie should not be available to Javascript in browser (not universal).

c
Simon
Foley

6 / 44

Multiple Cookies and Expiry

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Can have as many cookies as required.

setcookie(views,$views,time()+3600,"/");
setcookie(user,$_SERVER[REMOTE_USER],0,"/");

Results in a response
HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 15:06:56 GMT
Server: Apache
X-Powered-By: PHP/5.3.2
Set-Cookie: views=14; expires=Fri, 29-Oct-2010 16:06:56 GMT; path=/
Set-Cookie: user=homer; path=/
Content-Length: 30
Content-Type: text/html

c
Simon
Foley

7 / 44

Secure Cookies
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

An attacker can eavesdrop over an HTTP connection and gather copies of

cookies. This is a concern if the cookie contains sensitive information such
as usernames and passwords.
HTTPS can be used to support authentic and secure HTTP requests and
responses: the client may be sure of the identity of the server and the
requests/responses are sent in encrypted form over HTTP.
The secure flag in a cookie is set by the web-server and indicates that the
cookie should only be transmitted over a secure HTTPS connection from
the client.
When set to TRUE, the cookie will only be set if a secure connection exists.
It is up to the developer to decide whether the web application sends this
kind of cookie and to be sure that the connection is over HTTPS.
The browser will ignore a secure cookie that is not received over HTTPS.

c
Simon
Foley

8 / 44

Cookie Integrity
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

An attacker that controls the connection can also interfere with the values.
HTTPS can be used to secure the connection from this kind of attack.
Once the browser receives the cookie, a malicious client can easily modify
the cookie value (either directly, or via a proxy such as Paros).
The server can use a cryptographic one-way hash function to ensure the
integrity of a cookie value.
Attempted solution: given a cookie with identifier id and value v, then,
given some secret known only to the server, compute a cryptographic
checksum using a suitable one-way hash function h():
ck = h(v, secret)
and include this hash value in the cookie. An attacker cannot forge ck
without knowing the secret.
Before using a cookie presented by the browser the application should
re-compute the checksum and confirm it matches the checksum provided.

c
Simon
Foley

9 / 44

PHP script protecting the integrity of the variable value

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

<?php
$secret="my server secret";
$seperator = --;
if (!isset($_COOKIE[views])){
$views=1;
}else{
$cut=explode($seperator, $_COOKIE[views]);
if (md5($cut[0].$secret)==$cut[1]){
$views=$cut[0]+1;
}else{
die(Cookie data corrupted);
}
}
$splice=$views . $seperator . md5($views.$secret);
setcookie(views,$splice,0,"/");
echo "I have now seen you = ". $views . " times";
?>

c
Simon
Foley

10 / 44

Sample HTTP Request and Response

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

GET http://localhost/messAbout/visitCookie.php HTTP/1.1

...
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://localhost/messAbout/
Cookie: views=1--c4ca4238a0b923820dcc509a6f75849b
Cache-Control: max-age=0
User-Agent: Paros/3.2.13

HTTP/1.1 200 OK
Date: Fri, 29 Oct 2010 15:41:21 GMT
Server: Apache
X-Powered-By: PHP/5.3.2
Set-Cookie: views=2--c81e728d9d4c2f636f067f89cc14862c; path=/
Content-Length: 29
Content-Type: text/html

c
Simon
Foley

11 / 44

Problems with the script

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

The script only attempts to prevent the cookie variable value v from
corruption: it implements the cookie as [id, v, d, p, h(v, secret)].
A malicious client could take a copy of the cookie [id, v, d, p, h(v, secret)]
and change, for example, the expiry date to d resulting in the valid cookie
[id, v, d , p, h(v, secret)].
A determined and malicious client might have another cookie
[id , v , d , p , h(v , secret)] from the same server for a different variable id .
If the same secret was used to compute the checksum of this cookie then
the attacker can cut-and-paste variable values to give, for example, the
valid cookie [id, v , d, p, h(v, secret)].
We need to secure all the values in the cookie from modification.

c
Simon
Foley

12 / 44

A tasty (good) cookie recipe

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Given cookie attributes

 $secret a server secret

 $id a variable identifier,

 $v a value for the variable
 $d an expiry date,
 $p path information,
 ...

then compute a checksum $ck= h($id,$v,$d,$p,$secret, ...), given

a suitable one-way hash function h() and a server $secret. sha1 is a
reasonable one-way hash function for this.
Then we do: setcookie($id, "$v--$ck", $d, $p), where -- is the
separator to enable us to distinguish between the variable value and the
checksum.

c
Simon
Foley

13 / 44

A tasty (good) cookie script

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

<?php
$secret="my server secret";
$id=views;
$expiry=0;
$path="\";
$separator = --;
if (!isset($_COOKIE[$id])){
$views=1;
}else{
$cut=explode($seperator, $_COOKIE[$id]);
$views=$cut[0];
$values=$views.$id.$expiry.$path.$secret;
if (md5($values)==$cut[1]){
$views=$views+1;
}else{
die(Cookie data corrupted);
}
}
$splice=$views.$id.$expiry.$path. $secret . $seperator . md5($views);
setcookie(views,$splice,0,"/");
echo "I have now seen you = ". $views . " times";
?>

c
Simon
Foley

14 / 44

No perfect cookie
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

A determined and malicious client can still replay old cookies with this
recipe. For example, when visiting for the fifth time, the client keeps a copy
of the cookie. At some later date when the client visits for the tenth time
the client can easily replay the old fifth cookie.
The server could include a sequence number in the hashed cookie and then
keep track of the last sequence number issued to each client. However, this
requires state at the server side which defeats the purpose of the cookie.
If we are concerned about replay of cookie state then the server should
manage the state and use, for example, a PHP session to relate the state to
the visiting client (well see this shortly).

c
Simon
Foley

15 / 44

Authentication Cookies
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

When a user logs in (eg authenticated using the login.php code described
earlier in notes) then an authentication cookie is set in the browser by the
login program for the website and path.

user website
website user

HTTP request, ... userid, password

HTTP Response, ... AuthCookie

When the authenticated user subsequently makes an HTTP request to the

website, the authentication cookie is included.
user website

HTTP request, ...

AuthCookie

Before responding, the website must check that the authentication cookie is
valid for the given request.
While the underlying mechanics is not unlike Basic HTTP authentication,
the advantage to using authentication cookies is that we can associate other
attributes with the cookie, such as expiry dates, access constraints, etc.

c
Simon
Foley

16 / 44

A Tasty Authentication Cookie

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

We can use our tasty recipe for authentication cookies.

Let capability be a string of attributes that denotes what can be done by
a user presenting the cookie. For example, it could include the userid and
the URL (to which the user has access).
Let expiry be the expiry date of the capability.
If serverSecret is a secret known only to the server then the cookie is
cookie = (capability,expiry, h(capability.expiry.serverSecret))
So long as h() is a cryptographically strong one-way hash function then the
authentication cookie cannot be forged by a malicious user. Furthermore, a
legitimate holder of a cookie cannot modify it in order to obtain a different
capability.
Minimal work is required at the server to validate the cookie, which is good.
Make sure the cookie is sent over HTTPS!

c
Simon
Foley

17 / 44

A not so tasty authentication cookie: FatBrain.com [circa 1999]

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

When a user logs into the website (providing userid and password) an
authentication cookie is given to them which contains their userid and
sequence number as plaintext (roughly speaking, it was actually encoded
using GET attributes).
On a subsequent visit, the presented cookie is validated by the server which
checks that the sequence number is valid for the given user.
However, the scheme used predictable sequence numbers: when a user logs
in, the sequence number is simply incremented! This meant that an
attacker had a good chance of guessing/predicting other users sequence
numbers (at the time, fatbrain.com had about 1 user-login per second).
Userids, passwords and sequence numbers where also sent over HTTP
which meant that they were vulnerable to an eavesdropping attack.
For more information see:
http://cookies.lcs.mit.edu/seq sessionid.html

c
Simon
Foley

18 / 44

Cookies and Privacy

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

When viewing a Web page, images or other objects may set cookies in the
visitors browser.
A cookie may include information about a visitor that is known by they
website that created it: the visitors IP address, browsing activity, account
information, etc.
This information may be used to help tailor advertisements to visitors. Sites
may share this information and result in a loss of privacy of the visitor.
First-party cookies are cookies that are set by the same domain that is in
your browsers address bar.
Remember that a site cannot issue a cookie related to a different domain.
Thus, first party cookies can be used to track visitor actions within the
domain/website.

c
Simon
Foley

19 / 44

c
Simon
Foley

Third Party Cookies

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Third-party cookies are cookies that are set by one of objects, images, etc
within the web page but coming from a different domain (to that of the
web-page).
 User visits foobar.com/index.html,

 Page includes an image tag pointing to thirdParty.com/tp.php.

 Loading the banner image silently sets/checks a cookie for the

domain thirdParty.com.
Third party cookies can be used to track visitor actions across multiple
domains/websites.
Most browsers permit third-party cookies by default, but can be configured
to block third-party cookies.

c
Simon
Foley

21 / 44

Third Party Cookies

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Suppose that thirdParty.com provides a third-party cookie tracking

service to foobar.com and example.com. The script tp.php includes
setcookie("TPtracking", "..." , $expires, "/" , ".thirdParty.com");
$image = "R0lGODlhBQAFAJH/AP///wAAAMDAwA ... \n";
header(Content-type: image/gif);
echo base64_decode($image);

foobar.com embeds a 1-pixel square image in index.html:

<img src="http://thirdParty.com/tp.php?cust=foobar"
width="1" height="1" border="0" >

Further information could be passed to tp.php, such as information about

what is being viewed on the web-page.
thirdParty.com can use this cookie to track a visitor as he/she browses
from foobar.com to example.com.
c
Simon
Foley

22 / 44

Third party (cookie) sites: leaking your information

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Provide advertising services.

 First-party sites arrange with ad networks to place ads on their pages

via images or javascript code.

 For example, Googles Adsense (googlesyndication.com,

doubleclick.net), AOL (advertising.com, tacoda.net),

Yahoo!(yieldmanager.net)
Provide Analytics services:
 measure traffic, characterize users by downloading a JavaScript file

and send back information in a URL.

 For example, google-analytics.com (urchin.js), 2o7.net (Omniture),

atdmt.com (Microsoft/aquantive), quantserve.com (Quantcast)

Tie to a Person:
 foo.bar provides email service, passes user identity to

thirdParty.com/tp.php who can tie to browsing at other

(participating) sites.
c
Simon
Foley

23 / 44

Big Business
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

A longitudinal study of 1,200 popular web-sites [Krishnamurthy 2010] that

examined whether the web-sites were using third-party tracking services.
Results show increase use of these services. For example, increase in use of
Googles tracking services

c
Simon
Foley

24 / 44

European Union telecommunication privacy Directive

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Under the existing ePrivacy Directive, it is acceptable to use cookies for

legitimate purposes if the users are provided:
with clear and precise information about the purposes of
such use, so as to ensure that users are made aware of
information being placed on the terminal equipment they are
using

Certain cookie types (session cookies and those strictly necessary for
specific service explicitly requested by the subscriber or user) appear to be
exempt from the requirements.
Website users are typically notified about cookies by means of privacy
statements and online terms and conditions (where applicable).
A revised version of the directive may (2011) require more explicit
notification/agreement for the user.

c
Simon
Foley

25 / 44

c
Simon
Foley

c
Simon
Foley

c
Simon
Foley

PHP Sessions
Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

PHP Sessions provide stateful support for a PHP application whereby

certain data may be preserved across subsequent accesses.
The data related to a visitor accessing a web-site is associated with a
unique session id. The data related to a visitor is stored at the website and
the session-id is given to the user as a cookie (or within the URL). On a
subsequent accesses the session-id is used to retrieve the visitor information.
For example, suppose that instead of an authentication cookie we use a
session to implement (persistent) login:
<php?
session_start();
// simon is authenticated and permitted access everything
$_SESSION[userid]= simon;
$_SESSION[access]= all;
echo Logged in;
?>

c
Simon
Foley

28 / 44

The resulting HTTP response

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

On the first visit by the user, a session id is set as a cookie in response:

HTTP/1.1 200 OK
Date: Sun, 07 Nov 2010 13:13:22 GMT
Server: Apache
X-Powered-By: PHP/5.3.2
Set-Cookie: PHPSESSID=a5873580a38a1032d77b452205103aae; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
...

This cookie (session id) is presented on each subsequent visit.

PHP also creates a file sess a5873580a38a1032d77b452205103aae in
the (server) directory specified by variable session.save path in
php.ini. This file contains the data associated with this visitors session:
userid|s:5:"simon";access|s:3:"all";

c
Simon
Foley

29 / 44

Storing Secrets in Sessions

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Recall our dictum that whenever possible we should avoid storing secrets.
Suppose that we stored the users password in the session
$_SESSION[password]= $userpassword;

One might argue that the secret is safe as it is stored on the server and not
communicated to the client.
However, while the website developer may have been careful to properly
protect the user passwords in the mysql database he/she may have
overlooked the fact that other applications on the server might have access
to that part of the file system that contains the session data.
We should therefore, wherever possible, secure the session variable values.
For example,
$_SESSION[password]= sha1($userpassword);

c
Simon
Foley

30 / 44

Session ids in Cookies versus URLs

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

A session id can be stored in a cookie or given as parameter in URL

(configured in php.ini)
As a cookie, the request is
GET http://localhost/login.php HTTP/1.1
Host: localhost
...
Cookie: PHPSESSID=a5873580a38a1032d77b452205103aae

as a URL, the request is

GET http://localhost/session.php?PHPSESSID=a5873580a38a1032d77b452205103aae HTTP/1.1
Host: localhost
...

What are the advantages/disadantages of the different approaches?

c
Simon
Foley

31 / 44

Brute Force Session id Hijacking

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

If an attacker can determine the session identifier of another visitor then it

may be possible for the attacker to hijack the session and masquerade as
the other visitor to the website.
For example, suppose that Bobs website generates a new session id by
simply incrementing the value of the last session id issued.

 Alice connects/authenticates to Bobs website and receives a session

id (cookie) sessA .
 Suppose that malicious Mike knows that Alice recently connected to

the website.
 Malicious Mike connects/authenticates to Bobs website and receives

a session id (cookie) sessM .

 Malicious Mike repeatedly decrements sessM and visits the website

with the value as cookie and will fairly quickly end up making an
HTTP request to Bob that appears to come from an authenticated
Alice.

c
Simon
Foley

32 / 44

Brute Force Session id Hijacking

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Session ids should be random and infeasible for an attacker to predict.

Suppose that Bob revised his session id algorithm so that when a new
session is created the session id is calculated as the md5 hash of the current
time catenated with a 4-digit random number. For example,
 Alice visits website on Sun 7 Nov 2010 15:15, her session id is

c3cdfe22f6fa8c72e977db2858b538ad2753 (random val 2753).

 Malicious Mike visits the website on Sun 7 Nov 2010 15:17, and his

session id is 211c021d04984ccfd81bee2c12e407847652.
 Assuming Mike knows that Alice visited recently, then Bob can brute

force Alices session id by testing session ids for recent times along
with all possible 4-digit random values.
Mike might have collected his past session identifiers and recognized
patterns that indicate how session identifiers are generated.

c
Simon
Foley

33 / 44

c
Simon
Foley

Randomness and Session ids

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Just because c3cdfe22f6fa8c72e977db2858b538ad2753 is long and

looks random does not mean it is random: the last 4 digits provide the
randomness (assuming they are actually random) and everything else in
the number can be predicted.
Intuitively, Entropy gives us a measure of the underlying randomness in a
variable. In the previous example the entropy is given as approximately 13
bits (the number of bits that represent the random value 0 .. 9999).
[Assumes 4 digit numbers cannot be predicted in any way by an attacker]
The entropy gives us an idea of how much computational effort is required
to guess the session id by brute force means.
In practice, session ids should be at least 128 bits in length and should be
generated by a secure random number generator which should give an
entropy of around the same number of bits.
Remember that PHPs rand function is not secure (pretty close to 0 bits of
entropy) and mt rand has around 32 bits of entropy. The openssl secure
random number generator is best.

c
Simon
Foley

35 / 44

[Aside: Conventional Random Number Generators]

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Conventional pseudo-random number generators typically use algorithms

that produce a predictable sequence of numbers: an attacker who knows an
earlier random value can guess/predict later values.
For example, given constants c1 , c2 and N then the ith random number Xi
is computed as

Xi = (c1 Xi1 + c2 ) mod N

where Xi1 is previous random value generated; the generator is seeded by
a random value X0 .
Suppose this generator is used to generate n-bit session ids (2n 1 = N ).
If Malicious Mikes request for a session id (assigned as Xi ) is followed by
Alices request for a session id (assigned as Xi+1 ), then Mike can easily
determine Alices key. This is regardless of the secret that the KDC might
use to seed the PRNG.
In this example, the entropy in the generated values is effectively 0.

c
Simon
Foley

36 / 44

Session ids in PHP

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

The standard support for session ids in PHP computes the session id as a
one-way hash of a combination of the IP address of the visitor, a
time-stamp and the result from a random number generator.
From php.ini:
...
session.entropy_length = 16
session.entropy_file = /dev/urandom
session.hash_function = 1

Here we select 16 bytes of entropy from /dev/urandom which is the usual

Unix source of randomness for seeding a random number generator. We
also select SHA-1, since it is cryptographically better than MD5.
If the file is left blank then the default seeding method is used (above is
LAMPS default).

c
Simon
Foley

37 / 44

c
Simon
Foley

Session ids in PHP

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

The standard configuration for session id calculation is weak as it uses a

cryptographically weak random number generator whereby the random
numbers generated can be predicted with some effort by the attacker
(around 32 bits of entropy).
An attacker can brute force another users session id within approximately
251 hash operations, which is feasible for a wealthy attacker (a modern
GPU can achieve around 230 hash operations/second).
In a security-critical application you should not rely on the standard PHP
support for secure session ids.
It should be configured to use a source of cryptographically strong random
values and to use a secure one-way hash function. [A patched version of
PHP is available at www.hardened-php.net/suhosin].

c
Simon
Foley

39 / 44

Session Fixation Attack

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Remember that HTTP is stateless

 Session ids are used in an application are used to chain HTTP

requests together/associate with a visitor.

 Session ids are used on the server-side to maintain the session state.

 The authenticated state of a user is just one property of this state

and its possible that the session was created before the visitor
authenticated himself/herself.
Usual strategy is:
 The very first HTTP response carries the session id to the user (and

its not necessarily the result of an authentication).

 Usually in form of a cookie
 This session id is used to chain subsequent individual HTTP requests

c
Simon
Foley

40 / 44

Session Fixation Attack: Overview

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

Session fixation attack: attacker tricks the victim into using a session id
that the attacker already knows.
1. The attacker is given a valid session id from a server. For example, as
redirect http://foobar.com?PHPSESSID=1234 (set in the URL).
2. The attacker tricks the victim to use this session id for his
communication with the server. For example, the victim follows the
link http://foobar.com?PHPSESSID=1234 as a result of a CSRF.

3. In this session, victim sends his credentials to the server. For example,
victim logs in and $ SESSION[userid] is set to their name.
4. From now on, the session is authenticated. As the attacker knows the
session id, he now can access the application under victims identity
A fixation attack can be avoided if the application regenerates the session
id whenever the user authenticates himself/herself and/or when there is a
change of privilege.

c
Simon
Foley

41 / 44

Session Fixation Attack

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

The front page of a website creates a new session for the visitor with an
empty shopping cart, if not already created.
<?php
session_start();
// ...
if (!isset($_SESSION[cart])){
$_SESSION[cart]=$emptycart;
}
// ...
?>

At some point visitor decides to authenticate using login.php. This sets

the session variable userid (which is necessary in order to checkout, etc.).
<?php
session_start();
// .... if authenticated then set session variable
$_SESSION[userid]= $userid;
// otherwise leave session variable unset

This mechanism is vulnerable to a session fixation attack.

c
Simon
Foley

42 / 44

Avoiding a Session Fixation Attack

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

When a user logs in then there is a change of privilege associated with the
session id.
Whenever there is a change of privilege associated with a session id then
the application should generate a new session id for the session. That way,
any other user (attacker) that happens to know the session id prior to the
change of privilege cannot know this new session id.
PHP function session regenerate id() performs this task.
The login.php can be revised as:
<?php
session_start();
// .... if user is authenticated then set session variable
session_regenerate_id();
$_SESSION[userid]= $userid;
// otherwise leave session variable unset

c
Simon
Foley

43 / 44

Security of Session Identifiers

Cookies
setcookie
Secure Cookies
Cookie Integrity
Recipe
Authentication
Privacy
3P Cookie
Session Hijacking
Session Fixation
Conclusion

If an attacker can determine the session identifier of another visitor then it

is possible for the attacker as masquerade as the visitor to the website.

 Session ids should be communicated over HTTPS.

 Session ids must be sufficiently long so as to avoid a brute-force

guessing of (likely) session ids.

 Use cryptographically strong session id generation algorithm. It must

not be possible for an attacker to predict a session id.

 Session ids must expire when the user has finished visiting the website

and/or within a reasonably short period of time. Do not provide a

remember me check box.
 Session ids should be regenerated when there is a change of the

privilege associated with the session.

 Session variables may contain sensitive information and should be

protected on the server.

c
Simon
Foley

44 / 44