WEBVTT

00:00.000 --> 00:03.450
>> Our next topic is
application attacks.

00:03.450 --> 00:06.510
Ultimately that's where
the vulnerabilities are.

00:06.510 --> 00:08.520
They're in our applications,

00:08.520 --> 00:10.080
but first of all, have you

00:10.080 --> 00:11.925
ever taken a class
in programming?

00:11.925 --> 00:13.800
If so how much of that class

00:13.800 --> 00:16.140
was devoted to
writing secure code?

00:16.140 --> 00:19.080
I'm going to guess that in
another class was devoted to

00:19.080 --> 00:22.215
writing secure
code. I'm I right?

00:22.215 --> 00:25.335
Probably I'm right because
most of the classes,

00:25.335 --> 00:28.200
especially early on, focus
just on functionality.

00:28.200 --> 00:31.545
Then we tend to think of
security as an afterthought.

00:31.545 --> 00:33.330
As long as we do that, we're

00:33.330 --> 00:35.385
never going to
produce secure code.

00:35.385 --> 00:37.620
Security needs to be plant-in,

00:37.620 --> 00:39.764
>> built-in, and designed-in.

00:39.764 --> 00:42.180
>> It needs to be
tested and reviewed.

00:42.180 --> 00:45.635
Certification processes and
accreditation processes

00:45.635 --> 00:47.375
need to focus on security.

00:47.375 --> 00:50.630
It really needs to be
a purposeful process.

00:50.630 --> 00:53.570
Until we start designing
our applications and

00:53.570 --> 00:55.718
a more secure fashion
and implement security

00:55.718 --> 00:58.010
>> throughout the software
development life-cycle,

00:58.010 --> 00:59.090
>> we're going to
continue to see

00:59.090 --> 01:01.225
the security issues that we see.

01:01.225 --> 01:03.320
In this lesson, I'll give you

01:03.320 --> 01:04.820
an overview of the types of

01:04.820 --> 01:06.680
application attacks
we're going to talk

01:06.680 --> 01:09.080
about in the next few sections.

01:09.080 --> 01:11.270
The first attack
that we're going to

01:11.270 --> 01:13.490
look at is a code
injection attack.

01:13.490 --> 01:14.875
You've probably heard the phrase

01:14.875 --> 01:17.270
>> garbage in, garbage out.

01:17.270 --> 01:18.860
>> Well, there are
certain elements of

01:18.860 --> 01:20.450
code that I can inject into

01:20.450 --> 01:22.310
database applications that will

01:22.310 --> 01:24.065
cause problems on the backend.

01:24.065 --> 01:25.840
That's code injection.

01:25.840 --> 01:27.800
Sometimes we call that fuzzing

01:27.800 --> 01:29.900
or sometimes you'll
hear fuzzing used to

01:29.900 --> 01:32.660
describe a penetration
test to determine if

01:32.660 --> 01:34.396
>> an application
can sufficiently

01:34.396 --> 01:36.154
>> withstand code injection.

01:36.154 --> 01:38.660
>> Just be familiar
with the term fuzzing,

01:38.660 --> 01:40.010
which is like testing

01:40.010 --> 01:43.150
the application to see
what it will accept.

01:43.150 --> 01:47.810
The next that we'll look at
is cross-site scripting.

01:47.810 --> 01:50.690
Cross-site scripting
is all about taking

01:50.690 --> 01:53.165
advantage of a user's
trust in a website.

01:53.165 --> 01:55.520
A user visits a website
that they trust,

01:55.520 --> 01:58.355
and yet an attacker has done
something on the backend,

01:58.355 --> 01:59.854
to corrupt the website or

01:59.854 --> 02:02.119
>> redirects the
user to a rogue site

02:02.119 --> 02:04.070
>> by taking advantage
of some scripting

02:04.070 --> 02:06.430
and causing some
malicious attack.

02:06.430 --> 02:09.110
With cross-site scripting,
the attack is going

02:09.110 --> 02:11.785
to ultimately impact
the user system.

02:11.785 --> 02:14.450
Now, cross-site request forgery

02:14.450 --> 02:16.895
or excess RF sounds familiar,

02:16.895 --> 02:18.440
but it's actually
like the opposite

02:18.440 --> 02:20.075
of cross-site scripting.

02:20.075 --> 02:22.580
Cross-site request
forgery is going to take

02:22.580 --> 02:25.220
advantage of a website
to trust and a user.

02:25.220 --> 02:28.100
Basically, a user logs
in and they have already

02:28.100 --> 02:29.330
authenticated to a site like

02:29.330 --> 02:31.130
a banking server, for example.

02:31.130 --> 02:32.420
Then ends hacker is

02:32.420 --> 02:34.070
going to step in and
take advantage of

02:34.070 --> 02:36.050
that preexisting session and use

02:36.050 --> 02:38.785
that to manipulate their
activity on the backend.

02:38.785 --> 02:41.400
We'll also talk about
race conditions.

02:41.400 --> 02:42.716
Anytime you hear of an attack

02:42.716 --> 02:44.149
>> that has to do with timing,

02:44.149 --> 02:46.390
>> it's always a race condition.

02:46.390 --> 02:48.590
Last but not least, we're going

02:48.590 --> 02:50.240
to talk about memory issues.

02:50.240 --> 02:52.160
A lot of times
explaining issues with

02:52.160 --> 02:54.610
memory is part of a
denial of service attack.

02:54.610 --> 02:57.830
If I can overwhelm what
a system is expecting or

02:57.830 --> 02:59.525
provide it with
something out of range

02:59.525 --> 03:01.460
that can trigger a memory issue,

03:01.460 --> 03:03.140
which can trigger the system to

03:03.140 --> 03:05.060
lock up or stop responding.

03:05.060 --> 03:08.340
[NOISE] That's what we're
going to look at next.