WEBVTT 0:00:03.660000 --> 0:00:09.220000 Hello everyone and welcome in this video to tie off the filtering section 0:00:09.220000 --> 0:00:14.400000 of the course. We're going to be taking a look at the process of bypassing 0:00:14.400000 --> 0:00:19.000000 cross-site scripting filters in a real world web application called Camilo 0:00:19.000000 --> 0:00:23.900000 LMS. Now one of the reasons why this video and this particular lab is 0:00:23.900000 --> 0:00:27.020000 going to be important is because it'll tie everything that we've learned 0:00:27.020000 --> 0:00:29.120000 in this course thus far. 0:00:29.120000 --> 0:00:34.240000 So the inclusion of encoding and of course filtering will come into play 0:00:34.240000 --> 0:00:40.500000 and hopefully you'll get a better idea as to how encoding ties into filtering 0:00:40.500000 --> 0:00:47.200000 as well as getting to put into practice some of the techniques that we've 0:00:47.200000 --> 0:00:52.780000 explored in terms of server-side filtering or bypassing server-side filters. 0:00:52.780000 --> 0:00:57.440000 So as I pointed out this video will be utilizing a live lab so you can 0:00:57.440000 --> 0:01:01.420000 get started with it by just clicking on the lab below this video or the 0:01:01.420000 --> 0:01:05.940000 lab associated with this video and the lab itself will have documentation 0:01:05.940000 --> 0:01:09.900000 so you can go through the lab first or through the video but they are 0:01:09.900000 --> 0:01:15.200000 a couple of really cool tips that I'll be showing you in terms of my methodology. 0:01:15.200000 --> 0:01:19.740000 So with that being said let me switch over into the lab environment. 0:01:19.740000 --> 0:01:22.620000 You will not be provided with a calendar in the system so you'll need 0:01:22.620000 --> 0:01:26.180000 to utilize your own but once you start up the lab it'll provide you with 0:01:26.180000 --> 0:01:30.840000 a link to the target web application and I'll essentially be approaching 0:01:30.840000 --> 0:01:35.300000 it from a black box perspective and utilizing online resources in terms 0:01:35.300000 --> 0:01:38.880000 of learning more about the web application in question. 0:01:38.880000 --> 0:01:42.060000 So let me switch over and we can get started. 0:01:42.060000 --> 0:01:45.860000 All right so I'm back in my Kali Linux system and I've just opened up 0:01:45.860000 --> 0:01:49.740000 the link that was provided to me once I started the lab. 0:01:49.740000 --> 0:01:54.760000 As you can see it takes us to a real world web application more specifically 0:01:54.760000 --> 0:01:58.200000 a learning management system called Camilo. 0:01:58.200000 --> 0:02:01.960000 All right that automatically directs us to the home page that requires 0:02:01.960000 --> 0:02:07.520000 us to log in and as you can see at the bottom here in the footer there 0:02:07.520000 --> 0:02:10.740000 is a bit of information disclosure so for example the administrator's 0:02:10.740000 --> 0:02:15.540000 name is John Doe so that is revealed and we get some critical information 0:02:15.540000 --> 0:02:20.600000 and that critical information is the version of Camilo that's running. 0:02:20.600000 --> 0:02:25.780000 In this particular case it looks like we have Camilo 1.9.8 running. 0:02:25.780000 --> 0:02:30.000000 So to begin with one of the first things I like doing is obviously you 0:02:30.000000 --> 0:02:35.200000 know performing some general vulnerability analysis on the target web 0:02:35.200000 --> 0:02:39.540000 application and I can utilize exploit DB or even search exploit which 0:02:39.540000 --> 0:02:44.140000 is the command line utility or the utility that can be used to search 0:02:44.140000 --> 0:02:48.920000 for you know exploits on exploit DB and the exploit database is stored 0:02:48.920000 --> 0:02:50.240000 locally on Kali. 0:02:50.240000 --> 0:02:55.920000 So I can say search exploit and just say Camilo like so and in this case 0:02:55.920000 --> 0:03:10.220000 let me type in the word search exploit and in this case let's also make 0:03:10.220000 --> 0:03:14.800000 sure I am typing in the words correctly and there we are. 0:03:14.800000 --> 0:03:20.540000 So we know that we're dealing with 1 .9.8 and we can see that Camilo LMS 0:03:20.540000 --> 0:03:28.940000 1.9.8 exactly is vulnerable to blind SQL injection and version 1.9.10 0:03:28.940000 --> 0:03:32.260000 is vulnerable to multiple vulnerabilities. 0:03:32.260000 --> 0:03:38.320000 So let's perform some research or analysis on both of these here and we'll 0:03:38.320000 --> 0:03:43.760000 start off with 1.9.10 here so we can easily just I'll navigate to my desktop 0:03:43.760000 --> 0:03:49.380000 here and copy that particular text file from the locally stored version 0:03:49.380000 --> 0:03:54.580000 of the exploit DB or exploit database so user share exploit DB exploits 0:03:54.580000 --> 0:04:13.420000 and then I would say that's 455535.txt and we're looking for 455535.txt 0:04:13.420000 --> 0:04:18.020000 I'll just copy it to my desktop and now if I try and display it we can 0:04:18.020000 --> 0:04:24.240000 see that if we take a look at the actual exploit nodes or POC, exploit 0:04:24.240000 --> 0:04:39.400000 title here actually did I copy the correct one that was 636435 so that's 0:04:39.400000 --> 0:04:49.780000 the correct one we need to copy 36435 so 36435 and we'll just copy it 0:04:49.780000 --> 0:04:55.780000 locally here so I'll now cat the correct exploit or POC and you can see 0:04:55.780000 --> 0:04:59.140000 that there's quite a lot of vulnerabilities within this text file or this 0:04:59.140000 --> 0:05:03.500000 POC and you can see it says right over here under the overview that Camilo 0:05:03.500000 --> 0:05:08.180000 LMS 1.9.10 or prior versions are prone to multiple cross-site scripting 0:05:08.180000 --> 0:05:13.100000 stored and reflected and CSRF vulnerabilities these vulnerabilities allow 0:05:13.100000 --> 0:05:17.900000 an attacker to gain control over valid user accounts in the LMS perform 0:05:17.900000 --> 0:05:22.100000 actions on their behalf redirect them to malicious sites till their credentials 0:05:22.100000 --> 0:05:26.700000 and more the severity is high obviously and in terms of the vulnerability 0:05:26.700000 --> 0:05:30.880000 we want to test we obviously want to try out the reflected cross-site 0:05:30.880000 --> 0:05:36.240000 scripting you know POCs here so you can see these are the POCs and it 0:05:36.240000 --> 0:05:40.560000 looks like we have a few vulnerable endpoints like maincalendaragendalist 0:05:40.560000 --> 0:05:49.680000 .php main messages outbox.php we have main myspace student.php and quite 0:05:49.680000 --> 0:05:53.180000 a few others there are a couple of things that I want to highlight so 0:05:53.180000 --> 0:05:59.460000 these are ready-made POCs that we can try out to see the version of Camilo 0:05:59.460000 --> 0:06:06.620000 that's running on the target web server is indeed vulnerable so these 0:06:06.620000 --> 0:06:12.340000 are to be appended to the actual URL so maincalendaragendalist.php it 0:06:12.340000 --> 0:06:16.200000 looks like there is a parameter with a value and then what comes after 0:06:16.200000 --> 0:06:20.760000 is the actual cross-site scripting payload so based on what we've learned 0:06:20.760000 --> 0:06:24.780000 in the encoding section can you identify what type of encoding is being 0:06:24.780000 --> 0:06:29.500000 performed it should be very simple in this particular case it is URL encoding 0:06:29.500000 --> 0:06:33.920000 and the reason I know that is because we know the format of URL encoding 0:06:33.920000 --> 0:06:38.320000 we know it the prefix is always the percentage symbol and then we have 0:06:38.320000 --> 0:06:43.000000 the hex representation Unicode right over here so we can easily just search 0:06:43.000000 --> 0:06:47.560000 for you know URL decode or even utilize burps suite to perform it automatically 0:06:47.560000 --> 0:06:52.200000 for us so for example in this particular case I'll just use this URL decoding 0:06:52.200000 --> 0:06:56.780000 website and just click on and you can see this is the payload that is 0:06:56.780000 --> 0:07:01.480000 being used so we have a single quote that terminates that terminates a 0:07:01.480000 --> 0:07:07.260000 tag most likely and the payload we're using is on-mouse over this is a 0:07:07.260000 --> 0:07:12.000000 JavaScript functionality so on-mouse over confirm zero and then that is 0:07:12.000000 --> 0:07:16.740000 closed and then we have also the inclusion of a comment being created 0:07:16.740000 --> 0:07:20.520000 here which is interesting so best way to test it is let's just hit enter 0:07:20.520000 --> 0:07:25.480000 here and now when we hover over we can see that yes a dialogue box or 0:07:25.480000 --> 0:07:30.380000 the alert box is brought up with zero included in here okay so we know 0:07:30.380000 --> 0:07:35.160000 we've successfully been able to test for and you know exploit the reflected 0:07:35.160000 --> 0:07:39.520000 cross-site scripting vulnerability now what I really wanted to focus on 0:07:39.520000 --> 0:07:44.260000 specifically is going to be how we can try and see whether other types 0:07:44.260000 --> 0:07:52.020000 of payloads will be utilizing what we've learned in the previous videos 0:07:52.020000 --> 0:07:56.880000 by leveraging the sec lists cross-site scripting payload fuzzing list 0:07:56.880000 --> 0:08:00.580000 and we'll be utilizing burps suite as well so let me fire up burps suite 0:08:00.580000 --> 0:08:06.800000 and we can take a look at a couple of neat tricks all right so fired up 0:08:06.800000 --> 0:08:10.280000 burps suite here and I've opened up the burp browser I've just copied 0:08:10.280000 --> 0:08:15.720000 the URL without the actual payload here and we'll open it in the burp 0:08:15.720000 --> 0:08:19.560000 browser so I'll just paste and go here and I wanted to intercept this 0:08:19.560000 --> 0:08:23.280000 request so that I understand what's going on now if you remember when 0:08:23.280000 --> 0:08:27.840000 we when we decoded the payload that was we were able to identify in the 0:08:27.840000 --> 0:08:32.940000 POC there's a couple of interesting there's something very peculiar about 0:08:32.940000 --> 0:08:38.040000 this type of vulnerability not really the fact that you know in terms 0:08:38.040000 --> 0:08:46.400000 of sort of appending the payload to the end of the value of a particular 0:08:46.400000 --> 0:08:50.540000 parameter in this case the value looks like it's hard-coded so personal 0:08:50.540000 --> 0:08:54.600000 makes sense in terms of the agenda list based on how the web application 0:08:54.600000 --> 0:08:59.180000 is developed but it's more so these two characters here that are interesting 0:08:59.180000 --> 0:09:05.800000 so percentage 27 right over here represents a single quote and percentage 0:09:05.800000 --> 0:09:11.960000 20 represents a space so it looks like any payload that we use will need 0:09:11.960000 --> 0:09:15.680000 to have this in terms of payload processing in order for this to work 0:09:15.680000 --> 0:09:19.580000 and we can see that whatever comes after is just the actual payload itself 0:09:19.580000 --> 0:09:24.220000 so what I'm trying to say here is for example if we go in here and we 0:09:24.220000 --> 0:09:29.940000 send this into the intruder and we try to place our our payload at the 0:09:29.940000 --> 0:09:33.700000 end here so I'm just going to add a position here so we're essentially 0:09:33.700000 --> 0:09:37.720000 appending it to the end and if we go into the payload list and load the 0:09:37.720000 --> 0:09:42.140000 cross-site scripting brute logic payload list that's worked very well 0:09:42.140000 --> 0:09:46.480000 for us and we don't specify any payload processing so we just go with 0:09:46.480000 --> 0:09:51.000000 it as is and let me make sure redirection are enabled if I go ahead and 0:09:51.000000 --> 0:09:55.580000 start this what we will see is that I doubt any of these payloads will 0:09:55.580000 --> 0:09:58.500000 actually work now they might which would you know is quite interesting 0:09:58.500000 --> 0:10:02.500000 but let's just wait for this to complete and let's see what the results 0:10:02.500000 --> 0:10:07.420000 are like all right so the burp suite in truder is done and if we take 0:10:07.420000 --> 0:10:12.960000 a look at the results here right from the first request here you can see 0:10:12.960000 --> 0:10:17.020000 that we can analyze the the actual response and render it to see whether 0:10:17.020000 --> 0:10:21.400000 anything changes in terms of what we experienced when we were testing 0:10:21.400000 --> 0:10:26.880000 it here so it looks like a successful injection will change the layout 0:10:26.880000 --> 0:10:33.620000 of the page ever so slightly and you can see that when we do have a successful 0:10:33.620000 --> 0:10:39.440000 you know successful exploitation of the vulnerability regardless of what 0:10:39.440000 --> 0:10:42.440000 we do with the JavaScript whether we had you know displaying an alert 0:10:42.440000 --> 0:10:46.260000 it looks like the layout of that page changes so let's try and keep that 0:10:46.260000 --> 0:10:50.580000 in mind as we analyze the results from intruder here so it looks like 0:10:50.580000 --> 0:10:55.080000 in most cases these are not working and that's for the same reason I pointed 0:10:55.080000 --> 0:11:00.300000 out earlier so we can actually verify this by you know just copying this 0:11:00.300000 --> 0:11:04.220000 particular payload here for each of you know for a particular request 0:11:04.220000 --> 0:11:09.580000 and you know we can also send this to the repeater there we are and you 0:11:09.580000 --> 0:11:12.720000 know we can also open this up in the browser so in our current sessions 0:11:12.720000 --> 0:11:18.960000 I'll just copy that URL and in here we'll just say paste and go and I'll 0:11:18.960000 --> 0:11:23.540000 just go into the proxy and just for that request both of them and you 0:11:23.540000 --> 0:11:27.680000 can see that that payload did not work all right so that makes sense because 0:11:27.680000 --> 0:11:31.900000 it looks like the format involves the inclusion of a single quote to terminate 0:11:31.900000 --> 0:11:35.920000 the string literal and then a space and then the payload can come after 0:11:35.920000 --> 0:11:40.820000 we can of course explore some of the other payloads to see whether they 0:11:40.820000 --> 0:11:43.840000 worked but we can also play around with a length to see whether we have 0:11:43.840000 --> 0:11:49.340000 any abnormalities here so if we just you know take a look at ones with 0:11:49.340000 --> 0:11:56.440000 a higher length in terms of the response we can see that in certain cases 0:11:56.440000 --> 0:12:02.560000 we have data that's being appended here probably to the html that's of 0:12:02.560000 --> 0:12:06.660000 that particular page but let's see if we have any successful or what appears 0:12:06.660000 --> 0:12:11.380000 to be you know a successful exploitation of the vulnerability just using 0:12:11.380000 --> 0:12:14.840000 the current format that we had utilized and the point that I'm trying 0:12:14.840000 --> 0:12:23.020000 to you know essentially provided with information on how to identify and 0:12:23.020000 --> 0:12:26.800000 test for the vulnerability through the POC but I already explored this 0:12:26.800000 --> 0:12:30.200000 process in the individual cross-site scripting course which is why didn't 0:12:30.200000 --> 0:12:34.640000 go over it but I want you to pay attention to the actual payload format 0:12:34.640000 --> 0:12:40.480000 because that'll play a huge role in the successful exploitation or bypassing 0:12:40.480000 --> 0:12:44.560000 of filters if any and in this case there is a filter because you can see 0:12:44.560000 --> 0:12:49.240000 that it looks like what's being filtered is any inclusion of a greater 0:12:49.240000 --> 0:12:54.580000 than the greater than and less than symbol but let's see whether we have 0:12:54.580000 --> 0:12:58.220000 any successful results it doesn't look like we do so what we're going 0:12:58.220000 --> 0:13:02.940000 to do now is go ahead and discard that intruder session and we are going 0:13:02.940000 --> 0:13:06.680000 to go in here to that same intruder session and we're going to add some 0:13:06.680000 --> 0:13:11.680000 payload processing rules and what we want to do is add a prefix and the 0:13:11.680000 --> 0:13:16.080000 prefix is going to be a single quote and a space and we hit okay and ensure 0:13:16.080000 --> 0:13:20.160000 that payload encoding is performed because again we want to URL encode 0:13:20.160000 --> 0:13:24.240000 the characters and show that the single quote and spaces are included 0:13:24.240000 --> 0:13:27.880000 which in most cases they are and we can go ahead and start the attack 0:13:27.880000 --> 0:13:33.320000 using the same um sec lists uh cross -site scripting for um fuzzing payload 0:13:33.320000 --> 0:13:36.720000 lists so I'll hit okay and I'm going to wait for this to complete and 0:13:36.720000 --> 0:13:40.480000 let's see whether we get any successful whether we're able to find any 0:13:40.480000 --> 0:13:45.900000 successful payloads here all right so the burp intruder session is almost 0:13:45.900000 --> 0:13:49.280000 done here so if we take a look at the responses that we've gotten and 0:13:49.280000 --> 0:13:53.420000 the rendered view again looking for that irregularity in terms of the 0:13:53.420000 --> 0:13:57.980000 layout changing as an indication of you know a potential successful exploitation 0:13:57.980000 --> 0:14:02.300000 of the cross-site scripting vulnerability we can see that in this case 0:14:02.300000 --> 0:14:06.280000 because of what we appended or the payload processing rule that we implemented 0:14:06.280000 --> 0:14:12.000000 it looks like cases we may have payloads that are working so in this case 0:14:12.000000 --> 0:14:16.460000 you can see that this one seems to change the layout slightly and if we 0:14:16.460000 --> 0:14:20.820000 try and utilize this particular payload so if I send this to the repeater 0:14:20.820000 --> 0:14:25.580000 or if I open it up in my current uh browser so the burp browser here this 0:14:25.580000 --> 0:14:29.520000 one should actually work so I'll just open that up and we'll go to the 0:14:29.520000 --> 0:14:33.060000 proxy and I'll forward that request and if we go into burp suite or into 0:14:33.060000 --> 0:14:37.400000 the burp browser there we are we can see that that payload works so the 0:14:37.400000 --> 0:14:41.800000 point here is that you need to factor in especially with you know content 0:14:41.800000 --> 0:14:45.780000 management systems and learning management systems that are vulnerable 0:14:45.780000 --> 0:14:50.140000 or have publicly available cross-site scripting payloads you may need 0:14:50.140000 --> 0:14:54.340000 to change the payload you're using because the you know the default POC 0:14:54.340000 --> 0:14:58.840000 might not work but you also need to ensure that you analyze the POC to 0:14:58.840000 --> 0:15:03.220000 understand whether there is any there are any specific requirements with 0:15:03.220000 --> 0:15:06.400000 regards to how the payload should be structured so you can see in this 0:15:06.400000 --> 0:15:10.700000 case for this particular endpoint it looked like this is a pretty standard 0:15:10.700000 --> 0:15:16.540000 uh you know the single quote and the space uh are required in order for 0:15:16.540000 --> 0:15:21.740000 any payload that is appended to that to work if we just try and append 0:15:21.740000 --> 0:15:25.600000 the payload to personal without the inclusion of a single quote or a string 0:15:25.600000 --> 0:15:30.940000 uh string literal um then you know it would not work and of course a space 0:15:30.940000 --> 0:15:35.740000 so we can obviously take a look at the intrudency which one else uh what 0:15:35.740000 --> 0:15:41.620000 other payloads seem to work and in this case it looks like only a couple 0:15:41.620000 --> 0:15:45.440000 look like they work because the uh output is not changing really for some 0:15:45.440000 --> 0:15:48.800000 of the other payloads here so again we can always play around with a length 0:15:48.800000 --> 0:15:53.560000 to see whether we have any you know peculiarities so if I increase that 0:15:53.560000 --> 0:15:57.840000 to the maximum and we take a look at these here it looks like in certain 0:15:57.840000 --> 0:16:03.180000 cases they are working but not as expected and of course we can try and 0:16:03.180000 --> 0:16:08.860000 see some interesting ones here in this particular case let's just try 0:16:08.860000 --> 0:16:13.780000 and filter through and see whether we get anything interesting in terms 0:16:13.780000 --> 0:16:17.700000 of the output that doesn't look like it's working um and of obviously 0:16:17.700000 --> 0:16:21.360000 you know we can play around and try and find some other payloads here 0:16:21.360000 --> 0:16:27.020000 but let's go back to the we'll set the length to the highest here or rather 0:16:27.020000 --> 0:16:31.360000 let's see this one here as to whether that worked no it doesn't look like 0:16:31.360000 --> 0:16:35.800000 it did um we can see this one looks quite interesting here but nothing 0:16:35.800000 --> 0:16:41.540000 more than that uh if we try let's see uh let's take a look at payload 0:16:41.540000 --> 0:16:47.300000 85 that looks quite interesting it didn't give us a positive result last 0:16:47.300000 --> 0:16:52.520000 time what about the JavaScript alerts that seems to be having some effect 0:16:52.520000 --> 0:16:57.040000 here and let's actually try this one here so i'm just going to open this 0:16:57.040000 --> 0:17:01.960000 up in my current session copy the URL and i'll go into i'll go into burp 0:17:01.960000 --> 0:17:06.800000 suite the browser and i'll just paste that in here there we are and i'll 0:17:06.800000 --> 0:17:10.340000 just forward that request to see whether that payload worked and in this 0:17:10.340000 --> 0:17:14.760000 case it didn't look like it worked so if we click on that hyper reference 0:17:14.760000 --> 0:17:19.480000 link or the SVG here uh by the way we need to forward all of these requests 0:17:19.480000 --> 0:17:24.080000 here so let's see if that worked uh yeah that doesn't seem like it worked 0:17:24.080000 --> 0:17:28.940000 so the point is you know trial and error always ensure you analyze the 0:17:28.940000 --> 0:17:32.860000 web application's response to see whether you might have something a little 0:17:32.860000 --> 0:17:36.540000 bit interesting so you know we can always play around with this so for 0:17:36.540000 --> 0:17:40.680000 example if we take a look at this one here uh that looks like it could 0:17:40.680000 --> 0:17:43.940000 be potentially interesting so i'm just going to again pretty much open 0:17:43.940000 --> 0:17:49.200000 it up copy the URL and i'll then go into the burp browser paste and go 0:17:49.200000 --> 0:17:53.760000 for that request and there we are so we found another payload that works 0:17:53.760000 --> 0:17:58.540000 so you're not limited to just the pocs payload in terms of exploiting 0:17:58.540000 --> 0:18:02.820000 the cross-site scripting vulnerability you just need to understand the 0:18:02.820000 --> 0:18:07.400000 rules behind what is causing the the actual cross-site scripting vulnerability 0:18:07.400000 --> 0:18:11.900000 so the reason why i wanted to utilize this particular real world web application 0:18:11.900000 --> 0:18:17.880000 is to highlight that you know a a web application will have or could have 0:18:17.880000 --> 0:18:21.340000 multiple endpoints that are vulnerable and the rules change significantly 0:18:21.340000 --> 0:18:26.080000 for each of those endpoints in terms of the filtering or the lack they're 0:18:26.080000 --> 0:18:30.460000 in or filtering that is uh that is being performed and in this case we 0:18:30.460000 --> 0:18:40.200000 know it's being try out each of the endpoints in terms of the pocs play 0:18:40.200000 --> 0:18:44.120000 around with the different um with the different payloads you can utilize 0:18:44.120000 --> 0:18:49.760000 and obviously try out the user agent um header cross-site scripting vulnerability 0:18:49.760000 --> 0:18:54.520000 here so we would essentially need to navigate to this end point and uh 0:18:54.520000 --> 0:18:59.280000 if i go in here and let's just change that to the actual end point so 0:18:59.280000 --> 0:19:04.360000 that system status uh if we go into the browser we just need to change 0:19:04.360000 --> 0:19:08.700000 the end point there and make sure that we remove that forward slash there 0:19:08.700000 --> 0:19:14.640000 and we can essentially uh inject it into the uh we can inject it into 0:19:14.640000 --> 0:19:19.460000 the user agent http header here in the request which is pretty cool to 0:19:19.460000 --> 0:19:23.280000 think about so that's one of the really cool things about you know uh 0:19:23.280000 --> 0:19:28.420000 these types of vulnerabilities is the user agent or http headers might 0:19:28.420000 --> 0:19:33.680000 themselves be vulnerable to uh specific vulnerabilities like cross-site 0:19:33.680000 --> 0:19:37.280000 scripting and may not have any filtering so if we send this to the repeater 0:19:37.280000 --> 0:19:43.580000 or to the intruder we can pretty much clear the different uh the the current 0:19:43.580000 --> 0:19:48.580000 positions and just get rid of that user agent value there and just add 0:19:48.580000 --> 0:19:53.980000 a position there and again utilize the same payload um the payload list 0:19:53.980000 --> 0:19:58.120000 here for cross-site scripting we don't have any rules that we've identified 0:19:58.120000 --> 0:20:02.700000 for payload processing so we can just start the attack here and uh i'll 0:20:02.700000 --> 0:20:07.040000 wait for this to complete and let's see what we get uh we actually uh 0:20:07.040000 --> 0:20:10.940000 did not or we forgot to follow redirects so i'm just going to discard 0:20:10.940000 --> 0:20:15.440000 that them go into settings and ensure that we are always following uh 0:20:15.440000 --> 0:20:20.220000 redirects here and i'm going to start the attack there we go and uh let's 0:20:20.220000 --> 0:20:25.060000 see whether we get any successful um cross -site scripting uh or reflections 0:20:25.060000 --> 0:20:30.880000 back based on the payload list we're using okay so analyzing the intruder 0:20:30.880000 --> 0:20:35.420000 results reveals that we're getting a 403 which means we need to be authenticated 0:20:35.420000 --> 0:20:39.880000 so that particular endpoint needs authentication so at this particular 0:20:39.880000 --> 0:20:43.140000 point you can try and take a look at the other vulnerability we identified 0:20:43.140000 --> 0:20:47.840000 that affects Camilo LMS that is our own blind sequel injection that might 0:20:47.840000 --> 0:20:52.460000 be interesting to bypass authentication and then you can try out the remaining 0:20:52.460000 --> 0:20:58.740000 uh POCs in terms of uh you know uh performing or injecting uh the cross 0:20:58.740000 --> 0:21:02.060000 -site scripting payload into the user agent header here in the request 0:21:02.060000 --> 0:21:05.820000 to see whether it works with that being said that is going to conclude 0:21:05.820000 --> 0:21:11.280000 the practical demonstration side of this video alright so that was how 0:21:11.280000 --> 0:21:18.120000 to pretty much identify um and exploit and consequently bypass uh cross 0:21:18.120000 --> 0:21:21.700000 -site scripting uh filter server side cross-site scripting filters in a 0:21:21.700000 --> 0:21:26.000000 real world web application as i said the lab is quite extensible in terms 0:21:26.000000 --> 0:21:30.240000 of additional vulnerabilities you can identify and additional uh filters 0:21:30.240000 --> 0:21:35.340000 you'll need to bypass uh but that also brings us to the end of the filtering 0:21:35.340000 --> 0:21:38.820000 section of this course we're now going to turn our attention to the final 0:21:38.820000 --> 0:21:43.140000 section of this course we will be taking a look at evasion so web application 0:21:43.140000 --> 0:21:47.360000 firewalls intrusion detection systems and of course proxies and how they 0:21:47.360000 --> 0:21:51.700000 can be evaded or bypassed in terms of the ruleset or the restrictions 0:21:51.700000 --> 0:21:55.820000 that they impose so i hope you're really excited for that and i'll be