1
00:00:10,200 --> 00:00:16,650
So let us conclude our SQL injection topic with the countermeasures that we need to enforce so that

2
00:00:16,650 --> 00:00:18,960
its attacks won't happen.

3
00:00:20,990 --> 00:00:27,470
The first and the most important thing is you have to make no assumptions about the size type or the

4
00:00:27,470 --> 00:00:34,130
content of the data that the user will input, then avoid constructing dynamic ESKIL with concatenated

5
00:00:34,130 --> 00:00:41,030
input values, ensure that the Web configuration files for each application do not contain sensitive

6
00:00:41,030 --> 00:00:49,100
information, sanitize the input, for example, cut the extra HTML characters tags that numbers are

7
00:00:49,100 --> 00:00:49,730
required.

8
00:00:50,620 --> 00:00:57,940
Isolative Observatoire locking it in different domains then ensure all the software patches are updated

9
00:00:57,940 --> 00:00:58,660
regularly.

10
00:00:59,230 --> 00:01:05,560
Regular monitoring of Eskil statements from databases connected applications to identify malicious SQL

11
00:01:05,560 --> 00:01:12,670
statements and the most important thing is the not disclosed database error information to the end users.

12
00:01:13,970 --> 00:01:22,490
We saw Hoelter bathed or as could happen and errors are the most important thing, which help in throwing

13
00:01:22,490 --> 00:01:24,070
out valuable information.

14
00:01:25,850 --> 00:01:33,350
Then use a secure hash algorithm such as S.A.G. 256 to store the user passwords than in plain text,

15
00:01:33,770 --> 00:01:41,330
also validate user supplied data that is sanitisation, then ensure that all user inputs are sanitized

16
00:01:41,330 --> 00:01:49,340
before using them in dynamic ESKIL statements about the use of any Web application which is not tested

17
00:01:49,340 --> 00:01:49,810
by the Web.

18
00:01:49,820 --> 00:01:58,640
So then ensure that the coder tracing and debug messages are removed prior to deploying an application

19
00:01:58,970 --> 00:02:07,610
and finally use data access abstraction layer to enforce secure data access across the entire application,

20
00:02:08,150 --> 00:02:09,400
not common attacks.

21
00:02:09,410 --> 00:02:14,910
Use a specific type of code sequences that allow attackers to gain an unauthorized access.

22
00:02:15,080 --> 00:02:23,030
So make sure that the application does not accept any kind of external tags, inputs, open brackets

23
00:02:23,030 --> 00:02:23,480
close.

24
00:02:23,750 --> 00:02:30,830
For example, if the application is asking for the name of the user, you just have to allow the characters

25
00:02:30,830 --> 00:02:32,120
from A to Z.

26
00:02:32,300 --> 00:02:33,560
That is the alphabets.

27
00:02:35,090 --> 00:02:41,870
In this way, preventing database is one of the most toughest and important job nowadays, many hackers

28
00:02:41,870 --> 00:02:46,770
have a database and reveal the credentials and actually sell them on the web.

29
00:02:46,800 --> 00:02:54,170
So this is really very necessary and important for any security expert to prevent discrimination attacks.

30
00:02:54,980 --> 00:03:02,570
In the next lecture, you will have a brief introduction to cross site scripting that is Exercice.