Cookies and session

Monday, October
sohamsengupta@yahoo.com, soham.sengupta.java@gmail.com 1
13, 2014
http://www.flickr.com/photos/torkildr/3462607995/ Cookies and sessions

HTTP is “stateless”
• By default, web servers are “forgetful”
• As far as they can tell, every request comes from a
totally new and different browser
• (Not exactly true. We'll discuss persistent connections in
the context of performance.)
Monday, October
13, 2014

Pros of stateless servers
• Chief benefit: Potential for replication
• Improved performance: A sysadmin can fire up N copies
of a website (on N machines) and any machine can serve
each request.
• Improved reliability: If a machine crashes, then another
can be started up in its place, and no data gets lost in the
process.
Monday, October
13, 2014

Cons of stateless servers
• Chief problem: Keeping track of which requests "go
together"
• Security challenge: If a user submits username & password
in http request X, then tries to access resources in http
request Y, how does the server know that request Y is from
somebody who already logged in?
• By the time that request Y comes in, the server will already
have forgotten that request X ever occurred.
• And on a replicated system, request Y might be served by a
different machine than request X.
Monday, October
13, 2014

Cookies to the rescue!
• Reminder:
• Cookie = a piece of data that is automatically copied
between the client and server
• Cookies can be set by the client (as in the last unit) or
by the server.
Monday, October
13, 2014

A simple way to use cookies for
login…
• When user sends a valid username & password in
request X, the server replies with a cookie containing
the username & password
• When user subsequently makes request Y, the
browser sends along the cookie.
• Sounds appealing: user only needs to log in once
• Serious security hole: anybody who gets his hands on the
user's computer can see cookies
Monday, October
13, 2014

Using just cookies for login
Monday, October
Authenticate
13, 2014
Browser Server
Type username
& password Send username
& password
Cookie =
usernm&pwd
Click a link
or whatever Request page
(send cookie)
Send back
page
Warning
This design contains a
serious security hole.

A more secure way of cookies+login
• When user sends a valid username & password in
request X, the server replies with a cookie containing
a secret that the client couldn't possibly have guessed.
• When user subsequently makes request Y, the
browser sends along the cookie.
• Since the client couldn't have guessed this value without
logging in, the server knows that the user did in fact
previously log in.
Monday, October
13, 2014

Using cookies for login
Monday, October
Authenticate
13, 2014
Browser Server
Filesystem or
Database
Type username
& password Send username
& password
Store a random number
Cookie = the valid only for next 10 minutes
random #
Click a link
or whatever Request page
(send cookie) Check if the number is right;
if so, give another 10 minutes
Send back
page

Session = state stored across
requests
• This is what we call a "session"
• Session is basically an add-on to the basic http
functionality of a website
• So that the website can remember information across
requests.
• You can store lots of stuff in session
• Numbers, strings, stringified objects, …
Monday, October
13, 2014

Pros of sessions
• Stores information between requests
• Much more secure than the simple cookie-based
approach I showed you
• A bad person would need to steal the random number
(cookie) within 10 minutes of its creation
Monday, October
13, 2014

Cons of sessions
• Requires your web server to have write-access to
some sort of storage medium
• File system, database, …, if you want replication
• Otherwise just use memory (lost on server crash)
• Requires user to access site every few minutes
• Though you can configure longer or shorter times
• This is a tradeoff between usability & security.
• EECS servers currently are set to 24 minutes.
Monday, October
13, 2014

Simple example of using session
<?php
session_start();
if (isset($_SESSION['numhits']))
$_SESSION['numhits'] = $_SESSION['numhits']+ 1;
else
$_SESSION['numhits'] = 1;
echo "You hit my server ".$_SESSION['numhits']." times.";
?>
Monday, October
13, 2014

Authentication
(Using hardcoded username&pwd
for now)
<?php session_start(); /* login.php */
if (array_key_exists("username", $_REQUEST)
&& array_key_exists("password", $_REQUEST)) {
/* here is where we would check the username and password */
$_SESSION['uid'] = 1;
echo '<a href="inventory.php">View Inventory</a>';
} else {
?>
<form action="login.php" method="POST">
<div>Username: <input type="text" name="username"></div>
<div>Password: <input type="password" name="password"></div>
<div><input type="submit" value="OK"></div>
</form>
<?php
}
?>
<?php session_start(); /* inventory.php */
if (isset($_SESSION['uid']))
echo "This is where we would show inventory.";
else
Monday, October
echo "You need to <a href='login.php'>Log in</a>";
?>
13, 2014

You can set cookies without session
<?php
$nhits = isset($_COOKIE['numhits']) ?
$_COOKIE['numhits'] : 0;
$nhits = $nhits + 1;
setcookie('numhits', $nhits, time()+86400*365);
/* expires in 365 days */
echo "You hit my server ".$nhits." times.";
?>
Monday, October
13, 2014

Summarizing cookies vs sessions
• Cookies
• Little bits of data that are stored on client but also copied
automatically to the server
• Useful for storing little bits of data on the client, but they are
visible to everybody
• So don't store sensitive data in cookies
• Sessions
• Data is stored on the server (e.g., filesystem), keyed by a
random number
• The random number is sent as a cookie to the browser
• And the random number expires after a little while
Monday, October
13, 2014

When to use cookies vs sessions
• Use cookies when
• You need to save a small amount of data between requests,
and it doesn't need to be kept secret
• Use sessions when
• You need to save a larger amount of data between requests,
or when the data needs to be secret
Monday, October
13, 2014

Examples of information not to
store in unencrypted cookies
• Passwords
• Credit card numbers
• Social security numbers
• Student ID numbers
• Birthdates
• List of diseases the user has contracted
• Anything that must be kept secret
Monday, October
13, 2014

Yet another caveat
• After all of those warnings, you still can save secret
data in cookies, IF IT IS ENCRYPTED
• You will see how to do this later in the term
• But we don't really use encrypted cookies much
because it can cause usability problems.
Monday, October
13, 2014

Cookies and session

More Related Content

Viewers also liked (15)

Similar to Cookies and session (20)

More from Soham Sengupta (20)

Recently uploaded (20)

Cookies and session