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.