Hello everyone. Today we
are going to talk about the session management threat
called session fixation. Specifically, we will explain
what session fixation is, and talk about a specific
example of it, and how to prevent
these vulnerabilities. After this lesson, you'll
be able to discuss ways to prevent session fixation
vulnerabilities. Let's dive in. Session fixation
basically comes about, when a web application trusts a session ID
that is given to it. For example,
an attacker can trick a victim client into using a particular session ID using some methods, where for example, one method could be that
because the web application inherently is designed to take in the session ID through a URL, it causes that web
application to be vulnerable to
session fixation attacks. Then what an attacker
can do is to create a phishing email, which contains
the web applications URL, where a session ID
is set in that URL. This phishing email can be
sent to the victim client, and then the victim client
can go and click on this URL, and then is forced to use
that particular session ID. Another method could be that an attacker sends
a victim client to a specially crafted login page that the attacker controls, and then uses
a hidden form field to give the victim client
a particular session ID. Another way could be that if the web application is vulnerable to
cross-site scripting, the attacker can generate
a phishing email which contains the vulnerable
web applications URL, in addition to a malicious
script that is injected there. In this malicious script, the client then runs it and is forced to use
a specific session ID. To give you a more
concrete example of how this would look like, here is a diagram of the first instance that
I discussed earlier. This diagram is from OWASP. Here what happens is, first the attacker goes and logs into the vulnerable
web application, and then, the vulnerable
web application sends back a
particular session ID. Then the attacker creates a URL, or generates a particular
web server's login URL, and includes the session ID
as a parameter in that URL. Now, with that, this URL is
sent to the victim, and then, so the victim clicks on this login URL which
contains a session ID. When that happens, the victim
then also sends in the username and password
to the web server, and because the attacker
knows the session ID, then the attacker can
access a user's account. How do we go and prevent this
in our web applications? What we would want
our web application to do is, on the server side, it shouldn't accept
just any old session token if it's presented
with one during login. Also, if the web application
on the server side is presented with a session
token during login, that token should be canceled
on the browser side, and the server side should force the browser to return
to the start page. Also, upon a successful login, a new session token
should be given. In addition to that, we shouldn't use session IDs in our URLs. In summary, we talked about what session fixation
is and I discussed an example to give you a more concrete idea of
how it would be attacked. Then we discussed how
you would go about preventing session
fixation vulnerabilities. That's it for now. Thank
you for listening.