WEBVTT 0:00:03.620000 --> 0:00:06.020000 Hello everyone and welcome. 0:00:06.020000 --> 0:00:10.800000 In this video we are going to be taking a look at how to bypass server 0:00:10.800000 --> 0:00:13.320000 side input filters. 0:00:13.320000 --> 0:00:18.960000 And just like the previous video, we are going to be utilizing a live 0:00:18.960000 --> 0:00:24.660000 lab and we'll be taking a look at a different vulnerable web application 0:00:24.660000 --> 0:00:30.600000 that still has relevancy or is still realistic in terms of the server 0:00:30.600000 --> 0:00:34.540000 side filtering or server side filters being used. 0:00:34.540000 --> 0:00:38.020000 So we'll essentially be following the same process. 0:00:38.020000 --> 0:00:43.820000 The only difference is you'll now start to get an understanding as to 0:00:43.820000 --> 0:00:49.840000 the importance of learning about more about server side filtering in not 0:00:49.840000 --> 0:00:53.680000 really in terms of how it works because I've already covered that. 0:00:53.680000 --> 0:00:57.980000 Roughly speaking in terms of the techniques that are utilized but that 0:00:57.980000 --> 0:01:02.720000 is really not important from the perspective of a web app pen tester. 0:01:02.720000 --> 0:01:07.580000 What is really important is that you are time efficient with regards to 0:01:07.580000 --> 0:01:13.360000 your testing and the methodology that you utilize. 0:01:13.360000 --> 0:01:17.060000 So one of the things that you'll realize as you progress in this career 0:01:17.060000 --> 0:01:20.640000 is manual testing is always great. 0:01:20.640000 --> 0:01:26.340000 But once you've identified a vulnerable input or an input that you think 0:01:26.340000 --> 0:01:32.220000 is vulnerable, the next phase is to utilize the correct payloads for example 0:01:32.220000 --> 0:01:38.220000 and essentially automate the process of performing the testing. 0:01:38.220000 --> 0:01:42.900000 So with that being said, we'll get started now with the live lab. 0:01:42.900000 --> 0:01:56.200000 So you can choose to go through the lab before you watch the video or 0:01:56.200000 --> 0:01:59.100000 after it's entirely up to you. 0:01:59.100000 --> 0:02:03.540000 And more importantly, this particular lab will not provide you with a 0:02:03.540000 --> 0:02:05.120000 caliilonic system. 0:02:05.120000 --> 0:02:06.960000 However, one is required. 0:02:06.960000 --> 0:02:12.740000 So you can utilize your own and the tool will be utilizing primarily is 0:02:12.740000 --> 0:02:17.960000 going to be your web browser but will also be utilizing burp suite. 0:02:17.960000 --> 0:02:22.040000 And as I said, you don't need to follow along exactly with the demonstration 0:02:22.040000 --> 0:02:27.780000 is just a more so a very helpful video that'll save you a lot of time. 0:02:27.780000 --> 0:02:32.460000 But to save you time in this video, let me switch over into my caliilonic 0:02:32.460000 --> 0:02:37.000000 system. And let me fire up the lab and we can get started. 0:02:37.000000 --> 0:02:41.420000 All right, so I'm currently in my caliilonic system. 0:02:41.420000 --> 0:02:51.400000 I've started up the lab and this is the damn vulnerable web application. 0:02:51.400000 --> 0:02:54.200000 This is an intentionally vulnerable web application. 0:02:54.200000 --> 0:03:00.120000 But as I said, prior or previously, it is one that I like using to introduce 0:03:00.120000 --> 0:03:01.140000 you to this process. 0:03:01.140000 --> 0:03:04.940000 And of course, we'll be putting everything together in the next video 0:03:04.940000 --> 0:03:08.680000 in the in the sense that we'll be taking a look at an actual real world 0:03:08.680000 --> 0:03:09.720000 web application. 0:03:09.720000 --> 0:03:13.880000 But for now, let's, you know, log into DVWA. 0:03:13.880000 --> 0:03:19.640000 So the credentials for DVWA are in the lab documentation and the username 0:03:19.640000 --> 0:03:23.360000 is just admin and the password is just password. 0:03:23.360000 --> 0:03:24.900000 So fairly simple. 0:03:24.900000 --> 0:03:26.840000 I'm not going to save that here. 0:03:26.840000 --> 0:03:31.440000 And as you can see, DVWA has a set of different vulnerabilities you can 0:03:31.440000 --> 0:03:35.580000 try out will be sticking to cross set scripting because again, it's the 0:03:35.580000 --> 0:03:40.280000 most relevant, at least it was in the case of client side filtering. 0:03:40.280000 --> 0:03:43.480000 But again, it'll also make sense that we stick to that. 0:03:43.480000 --> 0:03:47.880000 You can obviously try the same for SQL injection as that would make the 0:03:47.880000 --> 0:03:49.700000 most sense as well. 0:03:49.700000 --> 0:03:56.160000 But the great thing with DVWA similar to Motilidae to is the fact that 0:03:56.160000 --> 0:03:59.640000 you have the ability to play around with the security level. 0:03:59.640000 --> 0:04:04.440000 So if I click on DVWA security, you can see the default security level 0:04:04.440000 --> 0:04:06.140000 is set to impossible. 0:04:06.140000 --> 0:04:08.460000 And you have the ability to change it here. 0:04:08.460000 --> 0:04:12.020000 So you can say low, medium, high, impossible, right? 0:04:12.020000 --> 0:04:18.800000 And right over here, you can see that there's also the inclusion of PHP 0:04:18.800000 --> 0:04:25.100000 IDs or PHP IDS, if you will, version 0 .6, which is a PHP intrusion detection 0:04:25.100000 --> 0:04:29.700000 system. And it's a additional security layer or rather security layer 0:04:29.700000 --> 0:04:33.320000 for PHP based web applications. 0:04:33.320000 --> 0:04:39.020000 And PHP IDs works by filtering any user supplied input against a blacklist 0:04:39.020000 --> 0:04:42.280000 of potentially malicious code. 0:04:42.280000 --> 0:04:48.180000 It is used in DVWA to serve as a live example of how web application firewalls 0:04:48.180000 --> 0:04:50.580000 can help improve security. 0:04:50.580000 --> 0:04:54.840000 And in some cases, how WAFs can be circumvented. 0:04:54.840000 --> 0:04:58.500000 So you can enable it for your current session and keep that in mind. 0:04:58.500000 --> 0:05:02.500000 And you can also simulate and attack and view the IDS log there. 0:05:02.500000 --> 0:05:04.020000 We're not really focusing on that. 0:05:04.020000 --> 0:05:07.520000 What I wanted to highlight are the security levels. 0:05:07.520000 --> 0:05:09.480000 So we'll start off at the low level. 0:05:09.480000 --> 0:05:12.140000 And again, that don't worry about that. 0:05:12.140000 --> 0:05:15.460000 The only reason I'm doing that is to highlight a couple of things. 0:05:15.460000 --> 0:05:19.060000 So the low security level, as you can see here, is completely vulnerable 0:05:19.060000 --> 0:05:22.400000 and has no security measures at all. 0:05:22.400000 --> 0:05:26.580000 All right, so there'll be no server side input filtering, regardless as 0:05:26.580000 --> 0:05:31.100000 to whether it is, you know, validation, whether there's encoding going 0:05:31.100000 --> 0:05:35.840000 on, or whether that there is sanitization, or even, you know, the presence 0:05:35.840000 --> 0:05:37.980000 of a rejects filter. 0:05:37.980000 --> 0:05:44.080000 The medium security level is mainly to give you an example of bad security 0:05:44.080000 --> 0:05:48.540000 practices with regards to input filtering on the server side. 0:05:48.540000 --> 0:05:51.940000 And then the high security level, and we'll be going through all three 0:05:51.940000 --> 0:05:57.660000 and bypassing each, is essentially an extension to the medium difficulty 0:05:57.660000 --> 0:06:04.240000 with a mixture of harder or alternative bad practices to attempt to secure 0:06:04.240000 --> 0:06:08.100000 the code. And as you can see, the vulnerability may not allow the same 0:06:08.100000 --> 0:06:13.120000 extent of exploitation similar in various capture the flag competition. 0:06:13.120000 --> 0:06:15.440000 So we'll start off with the low level. 0:06:15.440000 --> 0:06:16.800000 And there we are. 0:06:16.800000 --> 0:06:18.740000 So the current security level is low. 0:06:18.740000 --> 0:06:20.340000 We can confirm it right over here. 0:06:20.340000 --> 0:06:24.560000 And we'll go into the reflected cross side scripting section. 0:06:24.560000 --> 0:06:27.500000 And from this point on, because there isn't protection, we can pretty 0:06:27.500000 --> 0:06:31.520000 much go ahead and, you know, put in a standard script or JavaScript payload 0:06:31.520000 --> 0:06:33.960000 here for cross side scripting. 0:06:33.960000 --> 0:06:37.880000 But before we do that, let's try and get an understanding as to what exactly 0:06:37.880000 --> 0:06:39.960000 is going on now. 0:06:39.960000 --> 0:06:44.520000 One of the really cool features of DVWA is it gives you the ability to 0:06:44.520000 --> 0:06:45.940000 view this source code. 0:06:45.940000 --> 0:06:50.100000 So if I click on that button here, you can see it's now displaying the 0:06:50.100000 --> 0:06:55.680000 server side source code that is going to be performing the input filtering 0:06:55.680000 --> 0:06:57.640000 if there is any. 0:06:57.640000 --> 0:07:00.940000 Now, given that we're currently on the low security level, you can see 0:07:00.940000 --> 0:07:07.220000 that even the HTTP header or the value for the cross side scripting protection 0:07:07.220000 --> 0:07:10.580000 header used by the browser to essentially enable cross side scripting 0:07:10.580000 --> 0:07:12.280000 protection is set to zero. 0:07:12.280000 --> 0:07:15.520000 And if we take a look at this if statement here that checks for input, 0:07:15.520000 --> 0:07:21.520000 and then reflects back what was input back on the page, you can see that 0:07:21.520000 --> 0:07:23.200000 there is no filtering. 0:07:23.200000 --> 0:07:28.340000 And in terms of, you know, inputting a cross side scripting payload here, 0:07:28.340000 --> 0:07:32.580000 it looks like there isn't any sanitization or, as I said, filtering of 0:07:32.580000 --> 0:07:35.620000 any kind. So what does that mean? 0:07:35.620000 --> 0:07:39.420000 What that means is that we can pretty much just type in, you know, script 0:07:39.420000 --> 0:07:42.300000 and I'll just use my history here. 0:07:42.300000 --> 0:07:47.280000 We can just put in the standard alert here, and I'll just click on submit. 0:07:47.280000 --> 0:07:48.160000 And there you go. 0:07:48.160000 --> 0:07:50.860000 All right, so that's really not that interesting. 0:07:50.860000 --> 0:07:56.460000 And just to show you how it works, because the script was added as a suffix 0:07:56.460000 --> 0:08:00.420000 or appended to the end of the hello message. 0:08:00.420000 --> 0:08:03.540000 The way this would work is, you know, if I just said Alexis, you can see 0:08:03.540000 --> 0:08:08.600000 it says pretty much just depends it to the, to the end of the word hello. 0:08:08.600000 --> 0:08:12.900000 And based on what we saw in the source code, just revisit revisiting it 0:08:12.900000 --> 0:08:16.780000 again. You know, it's using a pre tag right over here. 0:08:16.780000 --> 0:08:21.460000 And inside the pre tag, there is the inclusion of the information or the 0:08:21.460000 --> 0:08:25.860000 data, the value of the actual name parameter. 0:08:25.860000 --> 0:08:30.340000 And that is also indicated in the URL where we have the parameter, which 0:08:30.340000 --> 0:08:34.000000 in this case is called name, and the value is what we put in. 0:08:34.000000 --> 0:08:37.840000 And we also looks like we have a hash or a pound symbol there, which is 0:08:37.840000 --> 0:08:39.260000 quite interesting. 0:08:39.260000 --> 0:08:41.760000 And I'll keep a close eye on that. 0:08:41.760000 --> 0:08:44.940000 So the next step obviously is to ramp up security. 0:08:44.940000 --> 0:08:47.580000 So click on DVWA security. 0:08:47.580000 --> 0:08:49.720000 And let's go into medium. 0:08:49.720000 --> 0:08:53.580000 Now, as I said, there's many ways we can sort of approach this, this, 0:08:53.580000 --> 0:08:58.720000 you know, two primary ways we can either go into this in a black box sense 0:08:58.720000 --> 0:09:09.620000 where we and or rather the other approach we can take is we take a look 0:09:09.620000 --> 0:09:13.720000 at it and then we try and figure out what's going on in order to bypass 0:09:13.720000 --> 0:09:17.040000 the actual input filter. 0:09:17.040000 --> 0:09:19.900000 And I said, this is all on the server side. 0:09:19.900000 --> 0:09:26.160000 So I think what we'll do is for the medium security level, we will view 0:09:26.160000 --> 0:09:34.620000 the source code just after the rendering. 0:09:34.620000 --> 0:09:37.840000 So you can see it's pretty much the same page we're taking a look at reflected 0:09:37.840000 --> 0:09:39.200000 cross site scripting. 0:09:39.200000 --> 0:09:43.040000 So just to see how the web application works, if I type in my name here, 0:09:43.040000 --> 0:09:48.620000 so Alexis, and click submit, you can see the functionality looks the same. 0:09:48.620000 --> 0:09:55.600000 If we view the actual source here, we can see that X XSS protection is 0:09:55.600000 --> 0:09:58.480000 still set to zero, which means it's not active. 0:09:58.480000 --> 0:10:01.400000 We then have the check for input. 0:10:01.400000 --> 0:10:06.560000 And we then have the get input section here. 0:10:06.560000 --> 0:10:07.960000 Thank you for the comments. 0:10:07.960000 --> 0:10:11.340000 But we have a name variable and that's equal to string replace. 0:10:11.340000 --> 0:10:17.440000 So in this case, what is being utilized is the string replace function 0:10:17.440000 --> 0:10:21.060000 in PHP. All right, now this is very important. 0:10:21.060000 --> 0:10:28.420000 The reason this is important is primarily because what we have here is 0:10:28.420000 --> 0:10:33.980000 not really matching or rejects filtering as we saw previously. 0:10:33.980000 --> 0:10:37.320000 And the best way to demonstrate this is to just search for that particular 0:10:37.320000 --> 0:10:41.100000 function. So I'll just say string replace. 0:10:41.100000 --> 0:10:44.860000 And in this case, we'll take a look at the W three schools documentation 0:10:44.860000 --> 0:10:50.660000 here that highlights that in this particular case, it tells us right over 0:10:50.660000 --> 0:10:56.160000 here that the string replace function replaces some characters with some 0:10:56.160000 --> 0:10:58.800000 other characters in a string. 0:10:58.800000 --> 0:11:03.260000 All right, so it's pretty much replacing or sanitizing the input, if you 0:11:03.260000 --> 0:11:08.680000 will. So it's, you know, getting rid or ensuring that, you know, whatever 0:11:08.680000 --> 0:11:12.460000 was input is stripped of any illegal characters. 0:11:12.460000 --> 0:11:16.560000 And in this particular case, it looks like a very basic filter that only 0:11:16.560000 --> 0:11:22.200000 filters script. Now what that means is that if this is configured correctly, 0:11:22.200000 --> 0:11:25.800000 I cannot go ahead and say script alert. 0:11:25.800000 --> 0:11:29.660000 And I'll just use the simple payload that we're all accustomed to vice 0:11:29.660000 --> 0:11:34.980000 a submit. You can see it reflects back what is inside the script tags, 0:11:34.980000 --> 0:11:37.140000 which means script is not being processed. 0:11:37.140000 --> 0:11:45.300000 Now, if I said, you know, H one, Alexis, H one, and I click on submit, 0:11:45.300000 --> 0:11:46.640000 you can see that that's still work. 0:11:46.640000 --> 0:11:48.540000 So it accepts other tags. 0:11:48.540000 --> 0:11:54.280000 Now that is very interesting in the context of cross site scripting, specifically. 0:11:54.280000 --> 0:11:59.780000 Now one of the really cool resources I want to share with you is the official 0:11:59.780000 --> 0:12:04.000000 OASP cross site scripting filter evasion cheat sheet. 0:12:04.000000 --> 0:12:05.660000 You can easily just search for it. 0:12:05.660000 --> 0:12:07.440000 It's fairly easy to find. 0:12:07.440000 --> 0:12:11.620000 But this will sort of give you a various set of payloads that you can 0:12:11.620000 --> 0:12:17.800000 use to again, do exactly this pretty much evade or bypass input filters, 0:12:17.800000 --> 0:12:23.140000 regardless as to whether they are client side filters or server side filters. 0:12:23.140000 --> 0:12:26.660000 And you can see there's quite a lot that are, you know, for different 0:12:26.660000 --> 0:12:33.240000 use cases based on what is being what exactly is being filtered or sanitized. 0:12:33.240000 --> 0:12:39.560000 So for example, one that really works quite well are the IMG, the actual 0:12:39.560000 --> 0:12:41.840000 IMG tags or IMG payloads. 0:12:41.840000 --> 0:12:46.700000 The reason this will work is primarily because in this particular case, 0:12:46.700000 --> 0:12:52.440000 what is being filtered or sanitized is the utilization of the script tag. 0:12:52.440000 --> 0:12:57.440000 Right. Now if you if we take a look at the source code again, you can 0:12:57.440000 --> 0:13:04.540000 see that because it's not using a regular expression filter, it this is 0:13:04.540000 --> 0:13:09.180000 right over here is case sensitive, which means we can easily bypass this, 0:13:09.180000 --> 0:13:13.940000 you know, without even taking a look at a cheat sheet by just saying script, 0:13:13.940000 --> 0:13:18.200000 right. And again, I'm hedging that this works because again, it might 0:13:18.200000 --> 0:13:25.400000 not. So we'll just say, and I'll still be processed the same. 0:13:25.400000 --> 0:13:28.700000 And we will just, you know, format that correctly. 0:13:28.700000 --> 0:13:29.640000 And I hit submit. 0:13:29.640000 --> 0:13:30.420000 And there we are. 0:13:30.420000 --> 0:13:34.140000 All right. So even though that this is a sort of an added level layer 0:13:34.140000 --> 0:13:40.020000 of security, in terms of a filter being present, clearly, if you were 0:13:40.020000 --> 0:13:45.780000 to analyze the actual server side filter, it'd be fairly easy to identify 0:13:45.780000 --> 0:13:49.900000 a payload that works or a sort of a bypass, if you will. 0:13:49.900000 --> 0:13:55.040000 Now, you might be sitting there to yourself and saying, well, yeah, that's 0:13:55.040000 --> 0:13:57.780000 because you knew the filter, and that is correct. 0:13:57.780000 --> 0:14:00.180000 Now I'm going to show you the black box approach. 0:14:00.180000 --> 0:14:07.120000 So let's say we had no insight as to what the source code or rather, you 0:14:07.120000 --> 0:14:10.100000 know, the actual server side filter looked like. 0:14:10.100000 --> 0:14:15.260000 How would we, you know, find a how do we find a payload that would work 0:14:15.260000 --> 0:14:19.280000 or that would bypass, you know, whatever filter is there? 0:14:19.280000 --> 0:14:24.180000 Again, remember, we're under the assumption now that we don't know what 0:14:24.180000 --> 0:14:28.120000 type of filtering is being used, whether we have a rejects filter, or 0:14:28.120000 --> 0:14:32.700000 whether we have, you know, any form of validation or sanitization. 0:14:32.700000 --> 0:14:36.920000 Well, one of the ways is through the cross-ed scripting filter evasion 0:14:36.920000 --> 0:14:39.120000 cheat sheet by OASP. 0:14:39.120000 --> 0:14:44.920000 But the problem with this is that this is too, this is not as time efficient 0:14:44.920000 --> 0:14:49.820000 as I would hope or that I would hope for you. 0:14:49.820000 --> 0:14:54.000000 Now that doesn't mean that that what I've just said negates the value 0:14:54.000000 --> 0:14:58.880000 of this particular filter evasion cheat sheet, quite the contrary, you 0:14:58.880000 --> 0:15:03.440000 can definitely take a look at this during your own free time. 0:15:03.440000 --> 0:15:07.180000 But again, I'm looking at this from the perspective of a pen tester or 0:15:07.180000 --> 0:15:08.240000 a bug bounty hunter. 0:15:08.240000 --> 0:15:13.040000 So what I would do, and this is what I usually do in Web Appentests, is 0:15:13.040000 --> 0:15:16.240000 I sort of understand what's going on in the background. 0:15:16.240000 --> 0:15:21.660000 Okay, so we'll now perform the black box approach and methodology for 0:15:21.660000 --> 0:15:26.700000 the medium security level and the high security level without taking a 0:15:26.700000 --> 0:15:29.300000 look at the source code for the high security level. 0:15:29.300000 --> 0:15:33.500000 Alright, so first thing I like doing is obviously firing up burp suite. 0:15:33.500000 --> 0:15:37.260000 Again, you can use OASP ZAP or whatever you're comfortable with. 0:15:37.260000 --> 0:15:43.000000 The community version of of burp suite will work just fine. 0:15:43.000000 --> 0:15:49.380000 There we are, just start up a temporary project and I'll utilize the burp 0:15:49.380000 --> 0:15:56.360000 browser. Okay, so there we are, I'll just go into the proxy and I'll use 0:15:56.360000 --> 0:15:59.440000 the burp browser here because it's much simpler, don't need to play around 0:15:59.440000 --> 0:16:05.400000 with my proxy settings. 0:16:05.400000 --> 0:16:08.780000 So we will just navigate to this URL here, because we'll need to sign 0:16:08.780000 --> 0:16:14.020000 in again. And I'll just go into the burp browser, there we go, based and 0:16:14.020000 --> 0:16:17.860000 go. And let me just disable intercept temporarily. 0:16:17.860000 --> 0:16:19.860000 And we will log in now. 0:16:19.860000 --> 0:16:23.680000 So admin and password, nothing wrong there. 0:16:23.680000 --> 0:16:28.740000 And because this is a new session, we need to go into the DVWA security 0:16:28.740000 --> 0:16:33.360000 menu and click on medium firstly. 0:16:33.360000 --> 0:16:35.240000 So I'll submit that, there we are. 0:16:35.240000 --> 0:16:38.800000 And now we can go into the reflected cross-site scripting page. 0:16:38.800000 --> 0:16:45.980000 And we are trying to figure out what exactly is going on when we send 0:16:45.980000 --> 0:16:49.080000 data. Alright, or when we try and send our name. 0:16:49.080000 --> 0:16:51.540000 So I'm now going to enable intercept. 0:16:51.540000 --> 0:16:54.820000 And I'll just click on submit. 0:16:54.820000 --> 0:16:59.840000 There we are. And you can see that we intercept that get request. 0:16:59.840000 --> 0:17:01.020000 And that's very important. 0:17:01.020000 --> 0:17:02.680000 This is a get request. 0:17:02.680000 --> 0:17:13.160000 And you can see that the parameter is passed along in the actual URL. 0:17:13.160000 --> 0:17:19.760000 So if we forward this, and we can see that, yep, that reflects back perfectly, 0:17:19.760000 --> 0:17:25.120000 as expected. And is this performing, I'm assuming, because we are utilizing 0:17:25.120000 --> 0:17:30.800000 chromium, that this is going to perform some URL encoding. 0:17:30.800000 --> 0:17:34.680000 So we'll just stick with the standard payload here. 0:17:34.680000 --> 0:17:37.540000 Again, just to see what's happening. 0:17:37.540000 --> 0:17:42.100000 There we are. So yes, URL encoding is being performed automatically, which 0:17:42.100000 --> 0:17:48.340000 is great. And as I said previously in the encoding section, you can easily 0:17:48.340000 --> 0:17:56.820000 decode, you can easily encode or decode HTML or URL URLs. 0:17:56.820000 --> 0:18:00.520000 So if you're going to the decoder here with burp, I can decode this as 0:18:00.520000 --> 0:18:03.820000 HTML, it's not encoded in HTML. 0:18:03.820000 --> 0:18:04.600000 But you can do that. 0:18:04.600000 --> 0:18:06.620000 I can also decode it in URL. 0:18:06.620000 --> 0:18:09.120000 And you can see that that's exactly what we put in. 0:18:09.120000 --> 0:18:13.220000 So you can now start to see why browsers do this, they just ensure that 0:18:13.220000 --> 0:18:15.160000 whatever's input is sent correctly. 0:18:15.160000 --> 0:18:17.380000 But anyway, that's a different tangent. 0:18:17.380000 --> 0:18:22.200000 So if I now hit forward, you can see that, yeah, that's exactly what we 0:18:22.200000 --> 0:18:23.360000 found previously. 0:18:23.360000 --> 0:18:26.840000 So how would I automate this if I didn't know, you know, what type of 0:18:26.840000 --> 0:18:28.400000 filtering was being used? 0:18:28.400000 --> 0:18:33.580000 Well, to answer that question, I utilize burp suites in truder module. 0:18:33.580000 --> 0:18:39.980000 Okay, and in addition to that, I also utilize a set of word lists called 0:18:39.980000 --> 0:18:48.700000 sec lists. All right, best resources, I can recommend to anyone getting 0:18:48.700000 --> 0:18:50.700000 into web app pen testing. 0:18:50.700000 --> 0:18:54.520000 So it is essentially a security testers companion, it is a collection 0:18:54.520000 --> 0:18:59.900000 of multiple types of lists during security assessments collected in one 0:18:59.900000 --> 0:19:05.920000 space. The list types include usernames, passwords, URLs, sensitive data 0:19:05.920000 --> 0:19:10.480000 patterns, fuzzing payloads, which is what we're focused on right now, 0:19:10.480000 --> 0:19:12.200000 web shells and many more. 0:19:12.200000 --> 0:19:15.460000 So you can easily just if you're on Kali, you can clone the repository 0:19:15.460000 --> 0:19:16.980000 and save it somewhere. 0:19:16.980000 --> 0:19:22.900000 Or you can do what I did, just install or download them directly using 0:19:22.900000 --> 0:19:26.180000 the official Kali Linux repository. 0:19:26.180000 --> 0:19:32.140000 So sudo apt get install, sec lists, I believe I have the latest version. 0:19:32.140000 --> 0:19:37.340000 There we are. And sec lists once installed, if you follow this particular 0:19:37.340000 --> 0:19:43.180000 technique, will be under user share and sec lists. 0:19:43.180000 --> 0:19:45.380000 So not word list, but sec lists. 0:19:45.380000 --> 0:19:47.860000 All right, so just keep that in mind. 0:19:47.860000 --> 0:19:51.600000 Now the one, the lists we're going to be using are under fuzzing, and 0:19:51.600000 --> 0:19:54.720000 you'll see how I'll use them to automate the process.