1 00:00:01,040 --> 00:00:09,380 Finally, our first vulnerability HTML injection now, I already showed you an example of this bug in 2 00:00:09,380 --> 00:00:13,290 one of the first videos of the course, and it's very easy to perform. 3 00:00:13,340 --> 00:00:16,260 That's why we're starting with it right now. 4 00:00:17,120 --> 00:00:22,550 This is first bug that we are going to cover for all the bugs that we were covering. 5 00:00:22,550 --> 00:00:26,240 This course will be asking three main questions. 6 00:00:27,050 --> 00:00:27,800 What is it? 7 00:00:28,340 --> 00:00:31,580 How can we do it and how do we fix it? 8 00:00:32,490 --> 00:00:38,930 These are important questions for us, especially how we can discover a certain buck now, luckily, 9 00:00:38,990 --> 00:00:42,350 HTML injection is not one of those critical vulnerabilities. 10 00:00:42,360 --> 00:00:44,550 However, it is considered a bug. 11 00:00:45,000 --> 00:00:48,280 And we are going to start off by explaining what exactly is it? 12 00:00:48,900 --> 00:00:52,080 So what is it to describe it? 13 00:00:52,080 --> 00:00:59,590 In one sentence we can say HTML injection is injecting HTML code into the website page. 14 00:01:00,210 --> 00:01:01,650 Simple as that. 15 00:01:02,280 --> 00:01:03,630 How exactly does it work? 16 00:01:04,230 --> 00:01:05,910 Well, here's an example. 17 00:01:06,330 --> 00:01:12,030 Let's say we have a very simple Web page that performs only one task. 18 00:01:12,600 --> 00:01:19,560 It asks the client to enter their name inside of a user input field once the person enters their name. 19 00:01:20,040 --> 00:01:26,420 For example, let's say that they entered a name from the application, then outputs. 20 00:01:26,460 --> 00:01:27,570 Hello, Tom. 21 00:01:28,490 --> 00:01:36,170 So we noticed that this application reflects what we input to the page we type something in and the 22 00:01:36,170 --> 00:01:40,850 application processes that input and reflected back in a sentence. 23 00:01:40,900 --> 00:01:41,180 Hello. 24 00:01:42,590 --> 00:01:51,500 Sukkoth could look something like this, we have form where we submit our name and after the form it 25 00:01:51,500 --> 00:01:58,760 will output hello and then whatever we brought inside of our input field in our code example, our name 26 00:01:58,760 --> 00:02:00,230 is reflected here. 27 00:02:01,710 --> 00:02:04,410 But the key part of our code is part. 28 00:02:05,640 --> 00:02:07,500 That is what we have control of. 29 00:02:08,160 --> 00:02:15,900 So then comes the question, what would happen if instead of a regular name, we submit in our code? 30 00:02:16,780 --> 00:02:24,070 In this case, a simple open header of size one pegs and Pesta written between header tags would be 31 00:02:24,070 --> 00:02:24,460 enough. 32 00:02:25,180 --> 00:02:29,530 What would happen to the code on the Web page if we injected this? 33 00:02:30,430 --> 00:02:32,050 What would it reflect? 34 00:02:32,980 --> 00:02:37,960 Well, here is where we decide if the page is vulnerable to the e-mail injection or not. 35 00:02:38,710 --> 00:02:43,720 Our HTML code injected in the page would look something like this. 36 00:02:44,700 --> 00:02:51,060 Once added to this code example, but the question is, how will the website process it? 37 00:02:51,480 --> 00:02:57,230 Is it going to process it as a regular string or will it process it as an HTML code? 38 00:02:57,780 --> 00:03:05,790 If the website process it as an HTML code and it outputs test written in header sites one, then we 39 00:03:05,790 --> 00:03:12,300 can conclude that the Web page is vulnerable to HTML injection and that user input field isn't filtered 40 00:03:12,300 --> 00:03:15,900 well enough to block HTML tags and HDMI code. 41 00:03:16,910 --> 00:03:23,660 OK, this was an example in theory, but right now, let's see how that would look like in practice.