Don't like this style? Click here to change it! blue.css

LOGIN:
Welcome .... Click here to logout

Sessions, Cookies, LocalStorage

The main three ways users are remembered.

But first:

Hosting A LAMP Stack

So I wanted to do this with Heroku, it was just too hard to get sqlite working for me. The reason for this is simple, sqlite is a bad choice for Heroku. So I'll show you a more temporary method.

Linux, Apache, MySQL, PHP == LAMP

This is the oldest and still most common stack on the internet.

So it's important to learn because the concepts that emerged from the LAMP world crafted the rest of web security.

Paiza.cloud my Heroku backup

Create a Paiza Cloud account Head to https://paiza.cloud/en/. This Japanese company made a quick launch server where we can mess around. Use your GitHub account to register.

Server Settings They will give you some options, select Node, PHP, Postgres, Jupyter Notebook, and Apache.

Clone Get these 3 files into your public_html folder: https://github.com/AndyNovo/paiza-php-demo

Sessions and Cookies

A TON of old-school security is centered around sessions, cookies, and local storage. So we need to play with them.

Almost all storage anywhere is what I would call key/value storage. That is, some string acts as a key which is associated with some other string "the value" that stores some data. XML, JSON, Sessions, Cookies, Local Storage, Arrays, Associative Arrays, and many other data storage formats are essentially just key/value pairs of various complexity.

SESSIONS are server-side key/value storage for a particular user of a particular service.

COOKIES are client-side key/value pairs that get sent with every request to a given server.

Local Storage is client-side only key/value storage.

There are a lot of client-side variants of localStorage: sessionStorage (localStorage but less permanent), indexedDB, Web SQL, Shared Storage, Cache Storage

PHP Sessions

In PHP we can start a session with a user using the line session_start(); which gives you access to a super-global associative array called $_SESSION. Here is a sample:

Banana Launch: Get that script running in a file called banana.php and visit the page several times.

The $_SESSION array persists over many trips to the server allowing the user to resume some experience on subsequent visits.

How?

Cookie view: Now inspect the network interactions with banana.php, in particular find the part of the request called a cookie and find the value of your PHPSESSID. Now see if you can clear your cookies (Chrome has a clear browser history with a 1 hour option) and refresh the request. Notice how the response has a set-cookie header.

Give the user a cookie: Use the command setcookie("andy", "rules"); to ask the user to remember you. Inspect how the cookies evolve from first request to second request.

Inspect the cookies in the developer tools:

Server-Side View of Cookies/Sessions

The user doesn't have access to the SESSION storage, but the server has access to the cookies. Note that each "cookie" is ONE key/value pair. You get 20 per domain.

Show everything: Use the lines print_r($_COOKIE); and print_r($_SESSION); to inspect the key/value pairs for both cookie and session.

Backdoor Session Viewing: Now on your server do the following from a terminal sudo more /var/lib/php/sessions/sess_REPLACE_BY_SESSION_ID_HERE to see where that session was stored.

Client-Side View

Open the developer tools, go to the Application tab, edit the cookies.

First Session Hijack: Now, clear your cookies, hit refresh a couple of times and get a new PHPSESSID. Share your URL and your PHPSESSID in the class chats. Get my PHPSESSID, go to the page AS ME, set the PHPSESSID to my value and refresh ten times. Now when I go back to refresh I'll find way more bananas!

So the upshot is that sessions give you inter-visit data storage on the server, cookies are used to store a unique-looking id that identifies the session. The user can then resume that session by giving that unique id. Gaining access to someone else's sessionid lets you act as them with immunity.

Many sites use this setup to remember the login state of a user or other things about them. So controlling that sessionid is very important.

Daily Flag

http://sessions.fsg.opalstacked.com/

Stretch stuff

So here are some extra things in this area that would be worth exploring if we have time: