- [Narrator] Cookies are often used
for web application authentication.
After a user logs into a system,
the web server provides a cookie,
so that the user doesn't need to continuously
log into the system,
every time he or she requests a new webpage.
Presenting the cookie with each request,
causes the web server
to reference the earliest successful login.
One major flaw, with some web applications,
is that they don't use random cookies.
Instead, they use a guessable value.
Let's go ahead and take a look at an example.
Once again, we'll turn to the
WebGoat application security demonstration tool,
and the ZAP web proxy.
This time, we're using a simple web application,
that asks for a username and a password,
and has a login button.
I have two accounts that I know exist on this server,
and I'm going to ahead and start the ZAP application proxy,
and tell it to intercept the login request.
I go back to the application.
The first time, I'll log on with the 'webgoat' account,
and click the login button.
ZAP intercepts that request,
and when I step through it,
I can see the Authentication Cookie right here.
I'm going to go ahead and make a note of that cookie value,
and then go ahead and let this finish.
When I return to the application,
you can see that I've been logged in as 'webgoat'.
I'm now going to log out.
Restart ZAP.
And this time, I'm going to go ahead
and log in with a user named 'aspect'.
Step through this login request,
and then note the authentication cookie value for this user.
Let's take a look at the cookies
that we have discovered so far.
We have two users, and their cookie values.
And we'd like to do is be able
to figure out the cookie value for 'alice'.
The first thing we might notice
when we look at these values,
is that they all begin with the same five-digit number,
so I'm going to presume that Alice's cookie
also begins with 65432.
Then they end with a text value.
At first glance, this text value looks somewhat random.
But the first thing I might realize,
is that each of these text values is the same length
as the username.
After thinking about this for a while,
I realized that the text value at the end of the cookie,
is actually figured out by,
taking the username, reversing the letters,
and then adding one value to each letter.
So, an A would become a B,
a B would become a C,
and so on.
Once I've done this,
I can go ahead and figure out alice's cookie.
I'm now going to return to WebGoat,
and see if I can use this trick to log in as 'alice'.
I'm going to go ahead and finish out the ZAP proxy,
log out of WebGoat,
get this set up to log in as 'alice'.
Restarting the proxy.
And this time, before I let this go through,
I'm going to tamper with this request a little bit.
You can see up here, the cookie JSESSIONID value.
I'm going to add to the end of this,
a value, including the session cookie
that I've computed for 'alice'.
65432fdjmb,
and now I'm going to go ahead and let this process finish.
When I return to WebGoat,
you'll notice that I've now logged in with Alice's username,
without knowing her password.
In this example, we analyzed the login cookie,
and guessed the correct value,
because it wasn't very carefully constructed.
This was a somewhat sophisticated session hijacking attack.
A simpler variation of this attack
involves eavesdropping on a user's unencrypted connection.
If you can simply view the cookie,
you don't have to go through all these hoops
to figure out the value yourself.