Session hijacking.
In this lesson,
we are going to talk all about session hijacking.
But before we do, we need to talk about session management
because session management
is a fundamental security component
in our web applications these days.
When we talk about session management,
this enables web applications to uniquely identify a user
across a number of different actions and requests
while keeping the state of the data generated by that user
and ensuring it's assigned to that user.
Now, when we do session management, for instance,
you log into my website,
and there's a lot of other students
who are logged into my website right now.
When you're logged in,
I need to know what lesson you're watching,
I need to know what quiz you've passed,
and all of that is session information
while you're connected to me.
And then when you're done with that session,
I need to save that in my database
so that way when you log in next time,
we didn't lose your results.
Now, a lot of the way that people do this though
is not just in the database, but they also use cookies.
We're talking about cookies in the cyber sense.
And the reason we have to use cookies
is because web or HTTP is a stateless protocol.
This means that the server doesn't preserve any information
about the client by default.
So if you want to store that information,
you have to either store it in a cookie or in your database.
Now, cookies allow web applications
to retain this information about the users of the website.
And normally these cookies
are going to be stored on your client.
Now, a cookie is essentially just a text file.
It's a text file that's used
to store information about a user
when they visit the website.
Now that cookie is created
when the server first sends the HTTP response header
with that cookie.
Then any subsequent request headers
that are sent by the client will also include the cookie
so we can send that information back and forth.
Because of that, we want to make sure
that that cookie is protected
because it is being transmitted across the internet.
Now when we talk about session cookies like these,
these are going to be non-persistent,
they reside in memory.
And when you're done
and you close out that browser instance, guess what?
That cookie would be deleted as well.
But not all cookies are just session cookies.
Some cookies are going to be more persistent,
and these are known as persistent cookies
because they stay around for a while.
These cookies are stored in the browser cache
until they're deleted by the user
when you do the clearing your cookies
or when they pass a defined expiration date.
For instance, you might connect to my website
and my cookie might say,
"This cookie is good for seven days."
And so if you came back in eight days,
that cookie would be gone
and you'd be like a new user to us.
If we were configured that way,
that's the way cookies work.
Now, when we talk about cookies, again,
they have to be protected.
And so when you're sending these cookies or you're storing
any kind of confidential information in them,
you should make sure they are encrypted.
By encrypting those cookies,
you can keep that information confidential
because remember, confidentiality and encryption
go hand in hand.
Now the next thing we need to talk about
is session hijacking.
As I said, a lot of these cookies are session cookies.
And so session hijacking relates to this really well.
When we talk about session hijacking,
it's a type of spoofing attack
where the attacker disconnects a host
and then replaces it with his or her own machine,
spoofing the original host IP address,
or using some other mechanism.
For instance, a lot of session hijacking attacks occur
through the theft or the modification of cookies.
So if I can steal your cookie,
I can take over your session and pretend I'm you.
Now, another way that this can be done
is by doing session prediction.
Session prediction attacks
are simply a type of spoofing attack
where the attacker attempts to predict the session token
to hijack that session.
Now, this session token has to be generated
using a non-predictable algorithm,
and it must not reveal any information
about the session client.
Essentially, it's a one-time use ticket
for the duration of that session.
And so it might be some long random number,
but how it's generated has to be non unpredictable.
If it is predictable, somebody can guess it
and they can take over your session.
So the last thing I want to talk about here
is cookie poisoning.
I know, we've talked a lot about cookies
and it's making me hungry.
But let's talk about cookie poisoning
and then we'll finish up this lesson.
When we talk about cookie poisoning,
this modifies the contents of a cookie
after it's been generated and sent by the web service
to the client's browser
so that that newly modified cookie can then be used
to exploit vulnerabilities in a web application.
If you want to be able to counter cookie poisoning
on your systems, you want to make sure you validate
the input of your web app
to account for any tampered-with cookies.
By doing encryption of your cookies
during transmission and storage,
you can help prevent this,
and if you delete cookies from the browser cache
when the client terminates their session,
it doesn't leave those cookies sitting there,
being able to be poisoned by somebody else.
So, this is all about good cookie management.
Now, I know a lot of people are against cookies in websites,
and a lot of people turn off cookies.
But a lot of sites need these cookies to operate.
And so you have to be able to think about this
if you're the guy or girl who's programming these websites:
Do you have to use cookies to do this?
Can you do this as saving things in your own database?
Can you do this another way?
And if you can't and you have to use cookies,
make sure you're doing it securely
by making sure they're very time limited,
they're deleted when you're done,
and they're encrypted anytime you're storing data in them.