Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated: 1 00:00:00,420 --> 00:00:06,360 In the earlier videos, we discussed what sequel injection vulnerabilities are and what causes sexual 2 00:00:06,360 --> 00:00:13,620 addiction vulnerabilities and how one can detect and exploit them when this all sounds fun from an attack 3 00:00:13,620 --> 00:00:19,860 us point of view, it is important to understand how to mitigate such harmful web vulnerabilities to 4 00:00:19,860 --> 00:00:21,710 make the Internet more secure. 5 00:00:22,620 --> 00:00:23,640 Not in this video. 6 00:00:23,730 --> 00:00:28,620 Let's discuss some of the mitigation techniques for sequel injection vulnerabilities. 7 00:00:30,200 --> 00:00:38,810 We should never append untrusted data to any scale query and always a sanitized user input before processing 8 00:00:38,810 --> 00:00:45,950 it at the server side, and the last but not least always used parametrized queries. 9 00:00:46,880 --> 00:00:52,490 Use of prepared statements with parametrized queries is the best way to prevent a sequel. 10 00:00:52,490 --> 00:00:55,520 Injection vulnerabilities in Web applications. 11 00:00:56,180 --> 00:01:03,410 Parametrized queries forced the developer to first define all the sequel code and then pass in each 12 00:01:03,410 --> 00:01:05,060 parameter to the query later. 13 00:01:05,930 --> 00:01:12,800 This allows the database to distinguish between code and data, regardless of what the user input is 14 00:01:12,800 --> 00:01:13,400 supplied. 15 00:01:14,490 --> 00:01:21,930 No prepared statements ensured that an attacker is not able to change the intent of a query, even when 16 00:01:21,930 --> 00:01:24,390 sequence commands are inserted by an attacker. 17 00:01:24,870 --> 00:01:31,470 Let's go through this example to better understand how SQL injection can be prevented using prepared 18 00:01:31,470 --> 00:01:32,160 statements. 19 00:01:33,330 --> 00:01:38,730 If you observe the piece of code that is highlighted here, we are defining the ESKIL code that is to 20 00:01:38,730 --> 00:01:42,660 be executed with placeholders for parameter values. 21 00:01:43,290 --> 00:01:50,100 Later, we are programmatically adding the parameter values using prepared statement, set string function 22 00:01:50,400 --> 00:01:52,350 and then we are executing the query. 23 00:01:52,750 --> 00:01:59,700 If you observe the prepared statement or set string function argument, we are testing the input values 24 00:01:59,700 --> 00:02:00,300 to string. 25 00:02:01,230 --> 00:02:07,980 This will prevent any injected ESKIL from being executed as we are properly casting the input to the 26 00:02:07,980 --> 00:02:09,340 right data type. 27 00:02:09,990 --> 00:02:13,200 So this is how we can use prepared statements in Java. 28 00:02:13,840 --> 00:02:19,770 Remember, sequel injection vulnerabilities can cause the worst damage when exploited by an attacker. 29 00:02:20,340 --> 00:02:26,220 As we have already seen in earlier examples, they allow an attacker to extract all the data from the 30 00:02:26,220 --> 00:02:31,970 database and it is extremely important for developers to be aware of secret injection vulnerabilities. 31 00:02:32,820 --> 00:02:40,050 This section of the course has provided some examples of how SQL injection vulnerabilities can be identified, 32 00:02:40,050 --> 00:02:41,910 exploited and prevented. 33 00:02:43,140 --> 00:02:49,140 And as I just mentioned, the best way to avoid sequel injection vulnerabilities is to use prepared 34 00:02:49,140 --> 00:02:53,140 statements if you cannot use prepared statements for some reason. 35 00:02:53,640 --> 00:02:59,810 Make sure that proper input validation is implemented, preferably using a white listing approach. 4019