>> Let's talk about cross-site request forgery.
Where cross-site scripting takes
advantage of a user's trust in a website,
cross-site request forgery is the opposite
because it takes advantage of a website's trust in you.
For example, you login to
your bank's website and you get a token
that says you've authenticated and you're good to go.
But let's say that while you're logged in you
also get an email that appears to be from your bank,
and the message entices you to click on a link to
learn about something or get some assistance.
But what clicking on the link actually
does is it sends a request to
the bank website to do something like transfer
some money or something along those lines,
and it exploits the fact that you're
logged into the site so
the bank site trusts you and
believes you have authorized the money transfer.
This requires us to use
some good common sense and watch for things like this.
Generally speaking, when you're logged into your bank,
you don't want to have any other windows open
or other sessions open.
You just want to log in the site,
do what you need to do, and then logout.
That's why these sites also log you out if there's
no activity after a certain point of time.
You want to keep this communication
with your bank very time
restricted because the longer that connection is open,
the more vulnerable you are.
Race conditions are all about timing.
If I'm able to manipulate
a system so that I throw off the timing,
I can take advantage of that.
There are a lot of processes that
need that to happen in order.
For example, I go to a website to
login and I identify myself with my username,
then I authenticate by providing a password,
then I'm authorized to access services.
But if an attacker can slow down
the authentication and speed-up authorization,
then the attacker can get authorized to access
services without even having to prove his identity.
That's a race condition.
Or as another example,
let's say I go to withdraw some money from an ATM.
I make on my request and it checks my balance to see
if I have enough money in
my account to give me the funds,
but what if I make a request?
It gives me the funds,
and then it checks my account status.
That is not how it's supposed to work,
and that could be a race condition
which has to do with timing.
There's a certain type of race condition
called time-of-check/time-of-use or TOC/TOU.
When a process needs access to
a configuration file for instance,
that process is going to validate that the configuration
files there it contains the information that it needs,
but what should happen is that the process should verify
the files there and then immediately use it.
But if the process verifies that the file is
there and then 10 other things happen,
well, an attacker could go in there and modify the file.
Then by the time the process comes around to use it,
it is no longer accurate and no longer has integrity.
That's a time-of-check/time-of-use attack.
Those are attacks on the system architecture,
and it's all about timing.
Now, we have a number of
memory issues that can be attacks.
They include: integer overflows,
memory leaks, and buffer overflows.
With an integer overflow,
what happens is that they're values
calculated that are outside of the expected range.
For example, I asked for a number between one and five,
and you give me the number 6.
It's similar to a buffer overflow where I
asked you for five characters and you give me seven.
Both of these cause memory issues and
input validation and sanitization
should fix both of those,
but if they don't then we have a problem on the back-end.
Then other issues with memory can occur
when applications just aren't well-written.
They don't have their stack of memory that
is allocated to the application,
but when the application closes
it doesn't properly release its memory.
That could cause other applications to have
conflicts and that could cause the system lock up.
This chapter had lots of
information and a lot of this is on the test,
so you'll want to review it.
We talked about types of attackers
like hackers: white hat,
black hat, and gray hat.
We said that white hats are ethical hackers,
but black and gray skirt
the law or skirt ethical standards.
We talked about a tax-like malware
and how it can be distributed in
a lot of different ways;through attachments in email,
through backdoor software intrusions.
We talked about viruses versus worms,
then we talked about network-based attacks
like Smurf and fragile attacks.
We said those are all about spoofing a source address.
We looked at Wi-Fi attacks and attacks on
passwords with brute force and dictionary attacks.
Later, we will fill that discussion
out by talking about remote attacks,
and pass-the-hash, and so forth.
Then we wrap things up by talking
about application attacks.
We really want to know these for
the exam especially things like
cross-site scripting and the importance
of input validation and sanitization.
This is definitely a chapter to go back
through with a fine toothcomb.