[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.