Sessions CSCI-UA.0467-002
Sessions
CSCI-UA.0467-002
About HTTP and State
HTTP is a stateless protocol.
That means HTTP requests don't know anything about each other. However, there are situations where we want to maintain state across HTTP requests. What are some of those situations? →
authentication (is this client logged in? … maintaining logged in state means the user doesn't have to log in per request!)
any time that we want to store persistent data about a client, like:
have they visited the site before
what are some user's preferences (personalization)
tracking / analyzing their behavior (!?)
etc.
Maintaining State Between Requests
OK, fine - HTTP is stateless, but maintaining state can be useful.
So… how might we maintain state or share data between requests? →
store data on the server about a user
link that data to the requests from a particular client
by using a session id that represents that client
…that session id is always retransmitted back to the server with every request from the same client!
which essentially maintains state
About That Session ID
Welp! That sounds terribly insecure. Why should that make you wince just a little bit. →
once you own that id, you own that session!
which means that session ids shouldn't be easy to:
steal
guess
This means that:
session ids shouldn't be generated sequentially
they shouldn't be present in the query string of a url (where someone shoulder surfing could see it, it appears in request logs, etc.)
they should be adequately long / complex to prevent brute force guessing
Back to Maintaining State
A browser has to keep a session id, and send it over to the server on every request in order to maintain state. What are some potential mechanisms for doing this? →
add a query string parameter for the session id on each request (is this a good idea? → no! shoulder surfing, logs, etc.)
add a secret form input for every page (input type is hidden), but… → same problem as above if using get, otherwise every request isn't a post
cookies! - text files stored by your browser (Chrome actually stores cookies in a sqlite database, which is essentially just a text file)
they can store a session id which links to more data on the server
as well as client side data (though there are better ways to do this)
Check out the Open Web Application Security Project for more details
Copying Cookie Data, Stealing Sessions!
What do you think will happen if we request the page with curl? Will the name be there? →
curl localhost:3000 Nooope… no info to identify the session, so name isn't there.
We can actually use curl to send cookies by using the --cookie flag. Let's copy over the cookie data…
curl localhost:3000 -v --cookie "connect.sid=..."Shutting Down the Server
What will happen if we restart the server? Will the session data still be present? →
We're using an in-memory session store, so, the session data will not be persisted.
Sessions CSCI-UA.0467-002
Sessions
CSCI-UA.0467-002
About HTTP and State
HTTP is a stateless protocol.
That means HTTP requests don't know anything about each other. However, there are situations where we want to maintain state across HTTP requests. What are some of those situations? →
authentication (is this client logged in? … maintaining logged in state means the user doesn't have to log in per request!)
any time that we want to store persistent data about a client, like:
have they visited the site before
what are some user's preferences (personalization)
tracking / analyzing their behavior (!?)
etc.
Maintaining State Between Requests
OK, fine - HTTP is stateless, but maintaining state can be useful.
So… how might we maintain state or share data between requests? →
store data on the server about a user
link that data to the requests from a particular client
by using a session id that represents that client
…that session id is always retransmitted back to the server with every request from the same client!
which essentially maintains state
About That Session ID
Welp! That sounds terribly insecure. Why should that make you wince just a little bit. →
once you own that id, you own that session!
which means that session ids shouldn't be easy to:
steal
guess
This means that:
session ids shouldn't be generated sequentially
they shouldn't be present in the query string of a url (where someone shoulder surfing could see it, it appears in request logs, etc.)
they should be adequately long / complex to prevent brute force guessing
Back to Maintaining State
A browser has to keep a session id, and send it over to the server on every request in order to maintain state. What are some potential mechanisms for doing this? →
add a query string parameter for the session id on each request (is this a good idea? → no! shoulder surfing, logs, etc.)
add a secret form input for every page (input type is hidden), but… → same problem as above if using get, otherwise every request isn't a post
cookies! - text files stored by your browser (Chrome actually stores cookies in a sqlite database, which is essentially just a text file)
they can store a session id which links to more data on the server
as well as client side data (though there are better ways to do this)
Check out the Open Web Application Security Project for more details
Copying Cookie Data, Stealing Sessions!
What do you think will happen if we request the page with curl? Will the name be there? →
curl localhost:3000 Nooope… no info to identify the session, so name isn't there.
We can actually use curl to send cookies by using the --cookie flag. Let's copy over the cookie data…
curl localhost:3000 -v --cookie "connect.sid=..."Shutting Down the Server
What will happen if we restart the server? Will the session data still be present? →
We're using an in-memory session store, so, the session data will not be persisted.
