- [Instructor] Cookies are often used
for web application authentication.
After a user logs in to a system,
the web server provides a cookie so that the user
doesn't need to continuously log in to the system
every time he or she requests a new web page.
Presenting the cookie with each request,
causes the web server to reference the earlier
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 user name and a password
and has a login button.
I have two accounts that I know exist on this server,
and I'm going to go 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 ane 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 the 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've discovered so far.
We have two users and their cookie values
and what 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 six, five, four, three, two.
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 user name.
After thinking about this for a while,
I realize that the text value at the end of the cookie
is actually figured out by taking the user name,
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
using a technique known as header manipulation.
You can see up here the cookie JSESSIONID value.
I'm going to add to the end of this
a value including the session 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 user name 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 need to go through all these hoops
to figure out the value yourself.