1. Cookies and sessions
Saturday, February 23, 2019Saturday, February 23, 2019

2. 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.)
Saturday, February 23, 2019Saturday, February 23, 2019

3. 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.
Saturday, February 23, 2019Saturday, February 23, 2019

4. 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.
Saturday, February 23, 2019Saturday, February 23, 2019

5. 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.
Saturday, February 23, 2019Saturday, February 23, 2019

6. 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
Saturday, February 23, 2019Saturday, February 23, 2019

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

8. 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.
Saturday, February 23, 2019Saturday, February 23, 2019

9. Using cookies for login
Browser
Server
Filesystem or Database
Type username
& password
Send username & password
Authenticate
Store a random number valid only for next 10 minutes
Cookie = the 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
Saturday, February 23, 2019Saturday, February 23, 2019

10. 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, …
Saturday, February 23, 2019Saturday, February 23, 2019

11. 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
Saturday, February 23, 2019Saturday, February 23, 2019

12. 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.
Saturday, February 23, 2019Saturday, February 23, 2019

13. 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."; ?>
Saturday, February 23, 2019Saturday, February 23, 2019

14. 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
echo "You need to <a href='login.php'>Log in</a>";
?>
Saturday, February 23, 2019Saturday, February 23, 2019

15. 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."; ?>
Saturday, February 23, 2019Saturday, February 23, 2019

16. Summarizing cookies vs sessions
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
Saturday, February 23, 2019Saturday, February 23, 2019

17. 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
Saturday, February 23, 2019Saturday, February 23, 2019

18. 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
Saturday, February 23, 2019Saturday, February 23, 2019

19. 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.
Saturday, February 23, 2019Saturday, February 23, 2019