Hi, within this lecture, we're going to start working on our challenges in the Juice Shop. And we're going to start with the XSS vulnerability because we have solved this. And as you can see we have another sold in here most probably it's because of getting tagged by the Burp Suite. So, we are actually solving some challenges. Maybe we discovered some page in the Burp Suite. It's not very important. Okay. Some of the challenges are pretty easy. Like find this page, just read this page or stuff. So, maybe it's one of the 'Get request' that we actually did but we are not aware of it. It's not very important. Okay. We're going to focus on the things that we're actually going to learn something out of them.

Okay, so as you can see there is an XSS challenge here, and it says that perform a DOM XSS attack. So, I have talked about this before. So, we have covered the reflected XSS, stored XSS but there was another section that we need to cover over here and it's called DOM XSS. And that's how we're going to learn about it. It's not very different than reflected XSS. But the thing, the theory behind it is a little bit different. It says that, please do the attack with this code so that I can understand it. Okay. It really doesn't matter for us. We can use these "iframe src" thing. We have used it before. So, basically we're going to copy this iframe source attack and we're going to try the XSS attacks with this payload over there rather than a script or HTML injection.

We're going to just go for iframe source attack. So, what I'm going to do over here in our terminal, I'm going to run a service called Nikto. It's not a service actually, it's a tool to understand the vulnerabilities, general information about the site that we are doing Pantesting. Okay. It's one of the things that you should do first because it finds general information and general vulnerabilities. So if you just run Nikto you can see different kind of options over here. So, maybe we will use some kind of data out of this result, maybe we won't use. But again, it's something that we should do at the beginning of our web pan testing. So, I'm just going do this. So I'm going to say Nikto and we need to specify the URL and the thing that we're going to run this against.

Okay. So, we know our URL over here and I don't know if it's going to discover something that we should use regarding to DOM based attack but it's the beginning of our web pan testing session. So again, I'm going to do this over here. First of all, we're going to say '.h'. Okay. And we're going to just come over here and copy this thing. So, this is going to be our host and yep here you go, all you have to do is just hit the Enter and it will start running the Nikto as you can see. So, it's something like Dear Buster, that the first thing that we should do before we start our pan testing. Okay. I'm going to leave it running behind. Okay. And we're going to see if we can gather some useful information out of it later. And by the way, nikto does a lot of pinging, does a lot of requests to the website.

Okay. So, if your website that your pan testing is behind a firewall or it has some sort of protection, it may ban you, it may ban your IP address. Okay. Or it may trouble you. So, we're going to see how to detect if there is any firewall later on. Okay. There is no firewall on this one as long as I know, so I'm just running this so maybe if you're against a firewall then maybe you shouldn't run this at all. Okay. But in this case it's fine to do so, so, it will actually find some of the vulnerabilities or some of the issues that we see over here, like it says that, "This side use SSL and Headers are not defined" so I believe there are no headers in our website at all. So, it's an issue but it's not a very important issue. You can actually submit this as an issue to the website that back bound to giving website but most probably you're not going to get a reward out of that one. Okay.

They should include some sort of security headers in their HTML code; in order to have a complete security protocol. But in this case I believe they didn't even care about that one. I'm going to just hit control C because it goes on forever and we're not getting out so much. So, if it was really vulnerable, like of an exploitable machine or really easy machine then we would get some results. But in this case, I believe we're not getting any results. Okay. So, there are some sort of other challenges here as well, like accessing a confidential document. So again, it's part of a game, you can find the documents and stuff but we're not going to focus so much on game side of the things. Okay. We're going to focus on the vulnerability side of the things. A lot more during this section, so that we can actually learn something and we can actually use that things in the real web pan testing.

So, I'm going to open the "owaspjuiceshopatil.herokuapp.com." One more time, we're going to start hunting for the XSS attack, so we can reach the scoreboard from here once we discover it. Okay, we don't have to remember the URL every time. Okay. If you cannot see it you can just write score dashboard. So, I'm going to go for the XSS attack as I said before, so I'm going to copy this and I'm going to find some places that I can inject this code and try. So, as you can see this is our website. Maybe we can try to write a review over here but I believe we cannot write a review unless we are logged in. We don't even have an account yet. So, it's not an option right now. Maybe we can register and try it like that, but we can try the other stuff here as well.

For example, in the customer feedback section, we can write a feedback right. Maybe we cannot change the order. So, we are logged in as anonymous right now because we don't have any account but we can try to inject this in comment and see what happens. Right. So, this is one of the things, this is an input box clearly. And we can try to just do it over there. And again, I'm going to explain what a DOM XSS attack means. Okay, don't worry about it. But right now just try to find it as a reflected XSS attack.

So, in this captcha it's asking for some sort of a mathematical question. So, I'm going to give the result and submit it and we couldn't see anything. So, most probably it doesn't contain an XSS vulnerability over there. So, it's not there. Okay, it's not in the customer feedback section. So, I'm going to go back and try to see other things that I can actually submit this. So, maybe we can try this in the login or password. So, rather than email, we can just try to give this iframe thing, and for the password we can try this as well. So, if I try to login, nothing happens. So, we cannot actually do that. Maybe we can try this in search. You know, that our search bar also works as well. So, if I inject this over here and hit Enter after I do this and here you go. As you can see, we managed to solve this problem, we managed to solve the session, we managed to inject an XSS like a JavaScript code and it got executed on our browser. So, this is how you find the first challenge. But we did what we have done so far right in the XSS section. So, what is the difference between DOM XSS attack and a reflected XSS attack? So, we need to understand that as well. So, as you can see it got executed and if we just refresh this or if we send this link to anyone, it will get executed one more time. Right. So, it's kind of reflected, it's not start if we just go to that website again, it will not run. But there is some sort of a minor difference between them. So, we need to understand it as well. So, if you search for "dom html." Okay, you can see this is a term that we use in the HTML. So, it refers to the document object model. Okay. So, it's a representation of the objects that we use inside of our html code. So, as you can see, we can see the graphs about the dom over here like elements, attributes and stuff. So, it's kind of representation document object modeling. Okay.

And what we do over here is to run this code, run this command inside of the html itself. So, it doesn't even get to the server. So, since this is a Javascript code, even if it's start, even if it's actually the reflected, it got executed on the client side anyway. But this time we're not even sending this to server, it just executes this on the client side and the server doesn't even know about this. Okay. So, if there is any filter on the server regarding to this as well, it won't even work because it works on the html side of the things, the client side of the things. So, that's the main difference between DOM and reflected attack. Not the way we exploit this maybe but the way it got executed on theory in the background. Okay. And now we solve this as well as you can see it's marked as salt. So, DOM base is a little bit different and it's a little bit difficult to find rather we compared with the reflected, maybe sometimes you can find reflected and think that it was DOM or vice versa. It really doesn't matter if you find it, you still get rewarded. So, let's stop here and continue with our challenges in the next lecture.