>> Our next topic is application attacks.
Ultimately that's where the vulnerabilities are.
They're in our applications,
but first of all, have you
ever taken a class in programming?
If so how much of that class
was devoted to writing secure code?
I'm going to guess that in another class was devoted to
writing secure code. I'm I right?
Probably I'm right because most of the classes,
especially early on, focus just on functionality.
Then we tend to think of security as an afterthought.
As long as we do that, we're
never going to produce secure code.
Security needs to be plant-in,
>> built-in, and designed-in.
>> It needs to be tested and reviewed.
Certification processes and accreditation processes
need to focus on security.
It really needs to be a purposeful process.
Until we start designing our applications and
a more secure fashion and implement security
>> throughout the software development life-cycle,
>> we're going to continue to see
the security issues that we see.
In this lesson, I'll give you
an overview of the types of
application attacks we're going to talk
about in the next few sections.
The first attack that we're going to
look at is a code injection attack.
You've probably heard the phrase
>> garbage in, garbage out.
>> Well, there are certain elements of
code that I can inject into
database applications that will
cause problems on the backend.
That's code injection.
Sometimes we call that fuzzing
or sometimes you'll hear fuzzing used to
describe a penetration test to determine if
>> an application can sufficiently
>> withstand code injection.
>> Just be familiar with the term fuzzing,
which is like testing
the application to see what it will accept.
The next that we'll look at is cross-site scripting.
Cross-site scripting is all about taking
advantage of a user's trust in a website.
A user visits a website that they trust,
and yet an attacker has done something on the backend,
to corrupt the website or
>> redirects the user to a rogue site
>> by taking advantage of some scripting
and causing some malicious attack.
With cross-site scripting, the attack is going
to ultimately impact the user system.
Now, cross-site request forgery
or excess RF sounds familiar,
but it's actually like the opposite
of cross-site scripting.
Cross-site request forgery is going to take
advantage of a website to trust and a user.
Basically, a user logs in and they have already
authenticated to a site like
a banking server, for example.
Then ends hacker is
going to step in and take advantage of
that preexisting session and use
that to manipulate their activity on the backend.
We'll also talk about race conditions.
Anytime you hear of an attack
>> that has to do with timing,
>> it's always a race condition.
Last but not least, we're going
to talk about memory issues.
A lot of times explaining issues with
memory is part of a denial of service attack.
If I can overwhelm what a system is expecting or
provide it with something out of range
that can trigger a memory issue,
which can trigger the system to
lock up or stop responding.
[NOISE] That's what we're going to look at next.