1
00:00:06,520 --> 00:00:09,360
- Let's go over different
SQL injection prevention

2
00:00:09,360 --> 00:00:12,390
recommendations, and
specifically the ones by

3
00:00:12,390 --> 00:00:17,200
industry leaders within the
OWASP organization, right?

4
00:00:17,200 --> 00:00:21,060
The number one recommendation
here is the use

5
00:00:21,060 --> 00:00:25,010
of prepared statements
with parameterized queries.

6
00:00:25,010 --> 00:00:29,900
That by far is one of the
most effective ways to combat,

7
00:00:29,900 --> 00:00:33,743
and to prevent, SQL
injection vulnerabilities.

8
00:00:34,690 --> 00:00:37,920
As you know, SQL injections basically are

9
00:00:37,920 --> 00:00:39,950
introduced whenever
software developers create

10
00:00:39,950 --> 00:00:43,500
dynamic database queries that
include users-applied input

11
00:00:43,500 --> 00:00:46,500
and you do not sanitize
input successfully, right?

12
00:00:46,500 --> 00:00:51,500
So input validation is
absolutely crucial here, right?

13
00:00:51,520 --> 00:00:56,130
So option two is the use
of stored procedures.

14
00:00:56,130 --> 00:00:59,710
And that is also an
alternative way of preventing

15
00:00:59,710 --> 00:01:03,350
SQL injection. We talked
about input validation,

16
00:01:03,350 --> 00:01:08,150
allow-list or in the
case of input validation,

17
00:01:08,150 --> 00:01:10,920
kind of the opposite
instead of doing block list,

18
00:01:10,920 --> 00:01:13,480
in this case is actually,
y'know, performing allow-list

19
00:01:13,480 --> 00:01:17,970
of input that is deemed to be appropriate

20
00:01:17,970 --> 00:01:20,380
to be evaluated by a web application.

21
00:01:20,380 --> 00:01:24,320
And then lastly, escaping
all user supplied input.

22
00:01:24,320 --> 00:01:28,960
Now there are some additional
defenses that you can employ

23
00:01:28,960 --> 00:01:31,490
and those include
enforcing least privilege

24
00:01:31,490 --> 00:01:34,420
which is the best practice
that you should do anyways.

25
00:01:34,420 --> 00:01:39,270
So the least privilege
concept of only providing the

26
00:01:39,270 --> 00:01:42,690
privilege that the application,
or user, in this case

27
00:01:42,690 --> 00:01:45,820
we're talking about applications
that they need in order

28
00:01:45,820 --> 00:01:49,300
for them to actually
perform whatever operation

29
00:01:49,300 --> 00:01:51,590
that it's designed for,
right? And not more.

30
00:01:51,590 --> 00:01:55,140
So, in other words, don't run
your applications as a route.

31
00:01:55,140 --> 00:01:57,850
Now, the second one is
performing allow-list

32
00:01:57,850 --> 00:02:00,850
for input validation
as a secondary defense.

33
00:02:00,850 --> 00:02:05,160
Even though we have it above,
in here, basically using it

34
00:02:05,160 --> 00:02:07,790
as a secondary defense,
let's say, if you use

35
00:02:07,790 --> 00:02:08,983
parameterized queries.

36
00:02:10,370 --> 00:02:14,350
Now I want to draw your
attention to this prevention

37
00:02:14,350 --> 00:02:18,820
cheat sheet that is also a created project

38
00:02:18,820 --> 00:02:20,450
by the OWASP organization.

39
00:02:20,450 --> 00:02:23,910
So if you click on that, it
will take you to this page

40
00:02:23,910 --> 00:02:28,910
and, you already know that
the OWASP, or the open web

41
00:02:29,090 --> 00:02:33,120
application security project
initiative and foundation,

42
00:02:33,120 --> 00:02:36,960
they have this project called
the Cheat Sheet Series.

43
00:02:36,960 --> 00:02:39,350
And you see that there
are a significant amount

44
00:02:40,636 --> 00:02:42,900
of proactive controls
and prevention techniques

45
00:02:42,900 --> 00:02:44,690
for many different vulnerabilities.

46
00:02:44,690 --> 00:02:47,520
They have one specifically
for SQL injection

47
00:02:47,520 --> 00:02:51,970
or sequel injection, and they
explain all the different

48
00:02:51,970 --> 00:02:54,870
defenses that I just went over,

49
00:02:54,870 --> 00:02:59,770
and they provide examples of
those defenses as well, right?

50
00:02:59,770 --> 00:03:02,010
Remember that we were
talking about different

51
00:03:02,010 --> 00:03:06,410
Boolean statements, and how
an attacker can use them

52
00:03:06,410 --> 00:03:09,560
to manipulate in the web
application and a database,

53
00:03:09,560 --> 00:03:12,910
to potentially reveal
sensitive information from a

54
00:03:12,910 --> 00:03:17,000
database while a parameterized
query will not be vulnerable

55
00:03:17,000 --> 00:03:20,730
to some of these, if you
implement them correctly.

56
00:03:20,730 --> 00:03:23,510
So again, take advantage of this resource.

57
00:03:23,510 --> 00:03:28,030
It goes beyond the scope of the CEH exam,

58
00:03:28,030 --> 00:03:30,320
but it's something that
I strongly recommend

59
00:03:30,320 --> 00:03:32,710
for you to become familiar with.

60
00:03:32,710 --> 00:03:35,659
Not only about the attacks,
y'know, and become familiar with

61
00:03:35,659 --> 00:03:38,140
what vulnerabilities
all about how to exploit

62
00:03:38,140 --> 00:03:40,880
those vulnerabilities, but
what are the recommendations

63
00:03:40,880 --> 00:03:44,820
on how to prevent them, or
mitigate them, or, y'know

64
00:03:44,820 --> 00:03:48,523
of course eliminating them
from your applications.