1
00:00:02,410 --> 00:00:02,950
Hello.

2
00:00:03,100 --> 00:00:11,530
I will use the VVWA project from GitHub that shows the various vulnerabilities, including SQL injection

3
00:00:11,890 --> 00:00:15,400
and then check how to mitigate them programmatically.

4
00:00:15,730 --> 00:00:22,750
Let's try the first laboratory on sql injection. Lets you understand what the vulnerability consists

5
00:00:22,750 --> 00:00:23,230
of.

6
00:00:23,590 --> 00:00:32,110
I have set up a login page which allows a user to authenticate. Trying with wrong credentials

7
00:00:33,010 --> 00:00:35,190
You will not be able to enter.

8
00:00:35,590 --> 00:00:43,060
Sometimes you can tell if an application is vulnerable to SQL injection by simply injecting a single

9
00:00:43,060 --> 00:00:48,490
quote, which is the character that encloses alphanumeric data

10
00:00:48,490 --> 00:00:56,040
in SQL. The server side query is created by concatenating parts of fixed

11
00:00:56,110 --> 00:00:57,940
sql to sql

12
00:00:57,940 --> 00:01:05,380
tied to user input, then injecting the single quote you can force to generate an incorrect

13
00:01:05,680 --> 00:01:06,840
sql query.

14
00:01:07,600 --> 00:01:12,500
And if the server-side exceptions are not handled

15
00:01:12,850 --> 00:01:17,030
It will allow you to view the details of the error on the browser.

16
00:01:17,590 --> 00:01:22,500
This may indicate the presence of the vulnerability in the server side code.

17
00:01:22,990 --> 00:01:27,040
Now let's try to insert a classic sql injection pattern

18
00:01:27,670 --> 00:01:35,000
that is ' or 1=1;--  for the user name and anything in the password field.

19
00:01:35,050 --> 00:01:35,260
The.

20
00:01:37,570 --> 00:01:43,400
And we managed to enter the reserved section without knowing valid credentials.

21
00:01:43,780 --> 00:01:48,560
So let's see now how you can mitigate the vulnerability programmatically.

22
00:01:48,970 --> 00:01:57,700
Let's go back to the source code of the login page and we comment on the vulnerable SQL query

23
00:01:58,150 --> 00:02:02,390
version, and uncomment the parametric query version.

24
00:02:02,860 --> 00:02:03,530
OK.

25
00:02:07,360 --> 00:02:11,910
And so this will have mitigated the problem.

26
00:02:17,770 --> 00:02:25,680
Now, let's try to put the application back in execution and try again to inject the malicious pattern.

27
00:02:28,800 --> 00:02:29,400
So.

28
00:02:34,830 --> 00:02:35,570
OK.

29
00:02:38,640 --> 00:02:44,640
But this time you see the authentication failed message. So the attack failed.

30
00:02:51,970 --> 00:02:58,960
In applications where data access occours through Object Relational Mapping (ORM) such as in .NET

31
00:02:58,960 --> 00:03:00,960
through Linq to Entities queries

32
00:03:03,750 --> 00:03:09,180
the problem of sql injection is already mitigated natively.

33
00:03:11,460 --> 00:03:19,020
This is because the values possibly deriving from a user input at the Linq query level would be

34
00:03:20,100 --> 00:03:24,180
natively considered as parameters.

35
00:03:31,690 --> 00:03:43,360
The problem we have seen can only exist with .Net, PHP or in Java by creating non parametric queries

36
00:03:43,360 --> 00:03:48,130
that link fixed sql server-side to user input.