WEBVTT 00:07.190 --> 00:13.250 Injection attacks are malicious actions by inputting untrusted data into an interpreter for evaluation, 00:13.250 --> 00:18.920 where the system calls the operating system to trigger the execution of the script or the external function, 00:18.920 --> 00:22.430 or accessing back end data using a database language. 00:22.430 --> 00:24.620 I know that sounds like French to me too. 00:24.650 --> 00:30.860 What we're really saying here is inside each website you've got a place where you can put input information. 00:30.860 --> 00:33.500 That information is usually your username and password. 00:33.500 --> 00:36.770 Maybe it's a search block where you're doing a search query. 00:36.800 --> 00:41.990 Maybe it's just someplace where you're typing in information for an email or a blog, or even a forum 00:41.990 --> 00:42.590 post. 00:42.590 --> 00:48.500 But all those places where you can inject information, allow for malicious actors to inject code or 00:48.500 --> 00:53.090 script, which a malicious actor can then utilize to perform an attack. 00:53.120 --> 00:58.970 That attack is known as an injection attack, and whenever a web application employs an interpreter, 00:58.970 --> 01:05.940 i.e. how I utilize that data, it processes that untrusted data, making the use of the injection attack, 01:05.940 --> 01:08.130 which then allows somebody to click on it. 01:08.130 --> 01:10.980 And that's where we get that injection attack from the part. 01:11.880 --> 01:17.940 Injection attacks that inject malicious JavaScript into a web application is then executed by other 01:17.940 --> 01:18.600 users. 01:18.600 --> 01:25.650 This is known as a cross-site scripting attack, where the attacker uses malicious code or JavaScript, 01:25.650 --> 01:30.630 in this case to trick the user's browser into performing an unwanted action. 01:30.630 --> 01:32.070 So what are we saying here? 01:32.070 --> 01:33.300 You click on something. 01:33.300 --> 01:36.570 Let's say that you're on a forum post and you love unicorns. 01:36.570 --> 01:37.920 We'll just use unicorns. 01:37.950 --> 01:39.180 So you love unicorns. 01:39.180 --> 01:42.900 And there's a little picture of a unicorn on a forum post, and you want to click on it because you 01:42.900 --> 01:43.440 want to see it. 01:43.440 --> 01:44.610 You want to blow it up. 01:44.610 --> 01:47.610 Well, you click on that little thumbprint, it blows up the unicorn. 01:47.610 --> 01:52.680 But what's really happening in the back end is that a malicious code has snuck into your system and 01:52.680 --> 01:58.830 then tracks through your browser to then perform the action that the malicious actor wanted to utilize. 01:58.830 --> 02:00.750 This is known as cross-site scripting. 02:00.750 --> 02:06.840 It's providing that two way information between the server and your browser that the threat actor is 02:06.840 --> 02:12.120 utilizing to execute code, than by getting a response from your browser. 02:12.150 --> 02:18.300 There are two types of cross-site scripting attacks persistent and non-persistent within a persistent 02:18.300 --> 02:18.900 attack. 02:18.930 --> 02:21.360 The website stores the code on the site. 02:21.390 --> 02:27.120 It typically through a message board or that unicorn picture I was talking about, and the user unknowingly 02:27.120 --> 02:32.280 activates it by clicking on either the code or the text, or even the picture. 02:32.310 --> 02:34.590 This is known as a persistent attack. 02:34.620 --> 02:40.290 A non-persistent attack, also known as a reflected cross-site scripting attack, is a server software 02:40.290 --> 02:40.800 flaw. 02:40.830 --> 02:46.770 This is where the server has a flaw embedded within it, and the malicious actor goes in and changes 02:46.770 --> 02:52.800 something within the initial software or within the web page itself to provide the attack structure. 02:52.800 --> 02:57.810 So you click on something that was legitimate before, but somebody took advantage of the server software 02:57.810 --> 03:02.250 and then changed that link into something that it shouldn't be, i.e. making it malicious. 03:02.250 --> 03:05.320 That's a non-persistent cross-site scripting attack. 03:05.350 --> 03:09.550 There are different mitigation strategies that we can use for cross-site scripting, and many of these 03:09.580 --> 03:12.040 are cross functional meaning across the board. 03:12.040 --> 03:17.260 Many of these would be utilized not just for cross-site scripting, but for all injection attacks as 03:17.260 --> 03:17.890 a whole. 03:17.920 --> 03:20.560 The first one is an HTTP referrer. 03:20.590 --> 03:25.540 A referrer is where the header serves as the means of verifying the source of the request. 03:25.570 --> 03:30.820 This aids in ensuring the original request and the expected sources, meaning that the referrer says, 03:30.820 --> 03:32.410 are you supposed to be here? 03:32.410 --> 03:34.270 Is this something that I'm supposed to be doing? 03:34.270 --> 03:35.860 And if so, I verify you? 03:35.890 --> 03:36.850 We're good to go. 03:36.850 --> 03:40.210 If not, I don't think this is a good idea, so I'm not going to do it. 03:40.240 --> 03:42.580 The same site attribute setting. 03:42.580 --> 03:45.520 This is a setting within the same site attribute that takes cookies. 03:45.520 --> 03:47.770 And it says, are we going to be strict with our cookies? 03:47.800 --> 03:49.630 Are going to be lax with our cookies. 03:49.630 --> 03:51.580 How are we going to provide a defense against this? 03:51.580 --> 03:57.520 By preventing the transmission of cookies within different injection attacks, we can use a Captcha 03:57.520 --> 03:59.560 where we identify different pictures. 03:59.560 --> 04:02.500 So again I'll use my unicorn reference because why not right. 04:02.530 --> 04:06.580 And we can have all kinds of different pictures where it says, hey, out of these nine pictures available, 04:06.610 --> 04:07.780 pick all the unicorns. 04:07.780 --> 04:12.310 And if you successfully pick all the unicorns, it may provide more unicorns for you to pick on, or 04:12.310 --> 04:14.860 it may gain you access into the site itself. 04:14.890 --> 04:16.300 We have tokens. 04:16.300 --> 04:21.610 These incorporate a unique token within each user request, and it provides legitimacy by validating 04:21.610 --> 04:24.220 the source against the server and it says everything checks out. 04:24.220 --> 04:26.230 You can then come into my website. 04:26.230 --> 04:30.880 We can do protection frameworks within it, which provides safeguards and features against these types 04:30.880 --> 04:32.080 of attacks. 04:32.080 --> 04:36.910 We can do a double submit cookie where we're writing different cookies and we're saying, hey, resubmit 04:36.910 --> 04:37.180 this. 04:37.210 --> 04:39.190 We're going to randomly generate this one cookie. 04:39.220 --> 04:41.410 We're going to embed it into a hidden field. 04:41.410 --> 04:44.230 And then we're going to compare that based on your submission. 04:44.230 --> 04:47.500 And if it compares and contrasts properly you're good to go. 04:47.530 --> 04:52.240 We can do a user authentication where we go through and say, you know what, I know that you authenticated 04:52.240 --> 04:54.580 once, but this is kind of sensitive. 04:54.580 --> 04:56.500 Uh, this provides some banking information. 04:56.500 --> 05:00.190 Why don't you go ahead and re-authenticate again just to verify that you are who you say you are? 05:00.220 --> 05:06.650 We can do a web application firewall where we just utilize Lies a defence in depth strategy, where 05:06.650 --> 05:10.040 the firewall goes in and stops certain types of injection attacks. 05:10.070 --> 05:14.930 It provides a little bit more robustness to our web applications, and it's just a technology feature 05:14.930 --> 05:16.460 you're probably already aware of anyway. 05:16.490 --> 05:18.890 And then finally we want to do software updates. 05:18.920 --> 05:25.070 A lot of these flaws that we see within servers and within sites themselves are simply need to be patched. 05:25.100 --> 05:27.500 We're already aware of the flaws, the fixes are there. 05:27.500 --> 05:31.910 You just literally need to go in and press that little button that says, let's upgrade our site to 05:31.940 --> 05:32.840 the newest addition. 05:32.840 --> 05:38.180 Cross-site request forgery occurs when a malicious website, email, blog, instant message, or comparable 05:38.180 --> 05:44.780 program tricks the authenticated user's browser into performing unwanted action on a trusted website. 05:44.810 --> 05:50.180 So let's say that you go into a website or a blog, or even a website, and you click on that little 05:50.180 --> 05:51.140 phishing email. 05:51.170 --> 05:57.650 You by clicking on that phishing email, you've interpreted a script that then performs an action on 05:57.650 --> 05:58.430 your behalf. 05:58.460 --> 06:04.310 That action could be telling your browser on the back end to go to your bank account and transfer funds. 06:04.310 --> 06:09.970 It's a pre-written script, so a lot of times you may bank with Chase, but the script is designed for 06:09.970 --> 06:12.220 Bank of America and so it doesn't work. 06:12.220 --> 06:16.510 It'll still try to go to the Bank of America's website and sign you in, using your session cookies 06:16.510 --> 06:19.000 to authenticate your your browser. 06:19.000 --> 06:22.000 But if you don't bake with Bank of America, no harm, no foul. 06:22.030 --> 06:26.500 However, let's say that you do bank with Bank of America by going through and providing that script 06:26.500 --> 06:30.880 and clicking all the right buttons and injecting your username password, you could suddenly find that 06:30.880 --> 06:33.130 your entire bank account has been emptied out. 06:33.130 --> 06:38.470 This is cross-site request forgery within cross-site scripting or XSS. 06:38.500 --> 06:43.630 We're talking about the server side being the attack platform under cross-site request forgery. 06:43.660 --> 06:49.510 We're talking about the client or your browser being the site of the malicious action and cross-site 06:49.510 --> 06:50.440 request forgery. 06:50.440 --> 06:57.820 The client is utilizing malicious software or a malicious script to interact with a legitimate server 06:57.820 --> 07:00.100 to process a malicious action. 07:00.130 --> 07:04.840 The different techniques for mitigating cross-site request forgery are almost exactly as they are the 07:04.840 --> 07:08.580 same for cross-site scripting, there's really no change between the two. 07:08.610 --> 07:14.250 Server side request forgery takes place much like cross-site request forgery, except the server is 07:14.250 --> 07:15.480 doing the request. 07:15.510 --> 07:19.980 Unlike cross-site request forgery, where it's the client performing the malicious action against another 07:19.980 --> 07:26.790 server, this occurs when a server does a malicious action against another server, where a server which 07:26.790 --> 07:33.060 was legitimate in nature, where a user or an action on that server performed a malicious script or 07:33.060 --> 07:35.910 malicious act against another legitimate server. 07:35.910 --> 07:38.910 This is known as server side request forgery. 07:38.940 --> 07:44.640 Much like cross-site scripting and cross-site request forgery, a lot of these things are the same. 07:44.640 --> 07:46.680 However, there are some new ones as well. 07:46.680 --> 07:53.430 We want to do input validation, where we validate users inputs to ensure that the URLs or the scripting 07:53.430 --> 07:54.480 is validated. 07:54.480 --> 07:56.280 We don't want special characters. 07:56.280 --> 08:00.510 We don't want language that looks or adopts to be, uh, coding. 08:00.510 --> 08:01.650 We just don't want to allow it. 08:01.680 --> 08:06.030 We want to allow just the basics zero through nine, uppercase and lowercase letters. 08:06.030 --> 08:08.800 And when possible, We don't want those special characters. 08:08.800 --> 08:14.440 We want to do release privilege, where only you only have access to the amount of privilege within 08:14.440 --> 08:16.930 the network as you decently need. 08:16.960 --> 08:21.310 That means that we're not going to have the janitor out there having CEO access or access to server 08:21.310 --> 08:22.660 configuration files. 08:22.690 --> 08:26.680 If someone leaves our IT department and goes to a different department, we're going to go back through 08:26.680 --> 08:28.630 and say, you don't need access to this anymore. 08:28.630 --> 08:30.370 You just have least privilege. 08:30.370 --> 08:37.120 We're going to do URL validation where we validate and sanitize the URLs by removing potentially malicious 08:37.120 --> 08:42.760 characters and validate that they are exclusively referenced and expected host of an IP address. 08:42.790 --> 08:46.480 Of course, we're going to use secure coding to make sure that we go through, and there's no vulnerabilities 08:46.480 --> 08:51.220 in there that web application firewall and the patching those haven't changed. 08:51.220 --> 08:55.930 We're going to provide dedicated libraries where we're not going through GitHub or some other third 08:55.930 --> 08:57.820 party website that's unverified. 08:57.850 --> 09:04.060 To provide those libraries for our coding, we want to use dedicated, verifiable, validated libraries 09:04.060 --> 09:05.350 when we're doing our coding. 09:05.350 --> 09:10.460 We also want to do a reverse proxy and we want to have some process of isolation when we're going through 09:10.490 --> 09:12.560 in creating our server software directory. 09:12.560 --> 09:18.590 Transversal is a web application server that allows an attacker to gain unauthorized access to restricted 09:18.590 --> 09:21.380 directories and files within the subdomain. 09:21.380 --> 09:27.020 That means that you interact with a website, and it's giving you permission to access certain directories 09:27.020 --> 09:32.060 or files that normally you just wouldn't have access to and shouldn't have access to through normal 09:32.060 --> 09:32.720 means. 09:32.750 --> 09:37.130 This would be like me going onto a web application, playing a video game, and going in and saying, 09:37.130 --> 09:37.730 you know what? 09:37.760 --> 09:42.080 Instead of being level 20, I'm just going to put this little code in there and instantly rise to level 09:42.080 --> 09:49.790 60 without any kind of, uh, validation or authentication and allowing myself to instantly gain that 09:49.820 --> 09:54.050 information and change the code of the actual game itself. 09:54.050 --> 09:56.150 This is known as directory traversal. 09:56.180 --> 10:00.050 Again, a lot of the same mitigation strategies are going to be utilized. 10:00.050 --> 10:04.790 As we've already discussed before, we're going to use secure coding web application firewalls. 10:04.790 --> 10:08.810 We're also going to make sure that our file handling libraries are correct and that they've been validated.