[MUSIC]
Hello there, today we will be talking about session management.
And I'm going to give you a very quick introduction to the concept.
Then I'm going to discuss the ways that web applications can manage the session ID
lifecycle for each user securely.
Next I'm going to mention how to safely exchange these session
ID tokens using cookies.
Finally I'm going to discuss ways of expiring the session securely.
When this lesson is finished, you will be able to evaluate a system to determine
if it follows the generally prescribed secure methods for session management.
Let's dive right in.
Because HTTP is stateless,
in order to create the notion of a state we need to use some sort of mechanism to
remember a previous request as being a portion of a much larger session.
Many web applications use cookies as a way to create a session.
The server generates some piece of data, then gives this data to the browser.
On subsequent requests, the browser gives the piece of data back to the server,
and the server uses this piece of data to identify that the particular
browser is associated with a specific account on the web application.
Note that every web application uses sessions.
State management can also be achieved using HTTP authentication, for example.
However, we will concentrate, on this course,
on examining sessions using cookies, as this is the most common.
So here is a representation of a very simple session management finite state
machine, with a clear start state, various session states, and an end state.
As you can see, the state transitions
are induced by the browser by sending restful requests to the server.
What's missing in this very simple session management finite state machine
is a transition from the logged in state to the logged out state,
where the transition occurs due to an expired session.
Note that you can set a cookie attribute and give it an expiry date, so
that this will provide a way to expire the session.
Now this finite state machine is very, very simple.
And this is a way for
us to be able to have a fundamental understanding of session management.
Now there are several things that you want to keep in mind when you
are writing your web application, and specifically,
when you need to create a secure session life cycle.
What you want to do is to create strong tokens.
What this means, effectively, is from the very beginning,
make sure to create tokens.
So these tokens are what you are giving to the web browser from the web server.
Make sure to create these tokens that are difficult to guess.
You want these sessions tokens to be as random as possible.
We want to make sure that attackers can't brute force through session token values
to guess any existing sessions.
This is because if attackers are able to guess existing session tokens,
they can take over the session associated to those session tokens.
Another thing that we want to keep in mind is to make sure that the transportation
of these session tokens from the web server to a browser is always
using an encrypted channel.
So HTTPS should be used between the browser and the server.
Another thing that you want to make sure to do is to make sure these token
data that you are giving to the web browser,
they should never be used as part of a URL.
This is because these are in the clear, they're stored in browser history,
they're stored in log data.
They can be used by unsuspecting users to send links to their friends.
This means that if a token is out in the clear in a URL,
that token must be deemed tainted.
So with that said, another thing that you want to keep in mind with web applications
are that the sessions that they use should be expired after some time that
isn't too, too long, for example 10 or 15 minutes.
You also want to prevent logins from more than one place.
This is because it makes session management easier to implement safely, and
reduces complexity.
And also, you want to make sure that if a session token, indeed,
is stolen by an attacker.
If your web application happens to allow multiple logins from more than one place,
your system won't be able to tell whether that is because an attacker has used
a session token, or it's because a user happens to be logged in more than once.
So preventing logins from more than one place removes that ambiguity.
Another thing that you want to make sure to keep in mind is to have a look at your
cookie scope, both the cookie domain scope and path scope.
You want to set cookie scope to be as restrictive as possible.
So remember that the name of the game is to keep session data for each user secret.
Double check that your cookie scope is reduced as much as possible,
the domain scope and the path scope of the cookie.
Also make sure that the cookie is inaccessible via JavaScript,
and is only sent back to the server, so
making sure that this cookie attribute of HTTP only, is set.
Remember that cookie domain scope can be such that, if you specify a cookie scope,
and the cookie scope is set to the parent domain of the web application.
Any web applications in the sub domains of that parent domain will then be able to
receive the cookie from the user's browser if the user happens to access it.
For example, if you had food.com as your cookie scope, and
that is the parent domain of your web application, and
your web application happens to live in webapp.food.com.
Then testapp.food.com will also be able to receive
the cookies that you have set for webapp.food.com,
if a user happens to browse to testapp.food.com.
Thinking about expiring these sessions, you want to make sure that your web
application has a proper logout functionality, and
it's working as expected.
You want to make sure that the session information on the server side is cleared
out every time a log out occurs.
And the server should invalidate that particular web browsers session
token cookie.
And any new logins should generate a completely new session token cookie.
And that data generated for that cookie should be as random as possible.
You could, in addition, implement a defensive session termination.
What that means is, you could implement your web application to be such that,
if the server receives invalid request from a client,
the server can force the client to perform a re-authentication.
In summary, we talked about session management, and
I showed you a very simple finite state machine for session management so that
you'd have a fundamental understanding of what that functionality would look like.
And then we talked about managing the life cycle for a session.
And also talked about making sure to expire these sessions properly.
That's it for now, thanks for listening.