WEBVTT 0:00:03.560000 --> 0:00:06.120000 Hello everyone and welcome. 0:00:06.120000 --> 0:00:10.720000 In this video, we're going to be taking a look at the process of bypassing 0:00:10.720000 --> 0:00:12.260000 client-side filters. 0:00:12.260000 --> 0:00:18.780000 So the primary focus here is going to be around filters implemented in 0:00:18.780000 --> 0:00:20.180000 client-side languages. 0:00:20.180000 --> 0:00:30.060000 When I say client-side, I mean languages that can be processed by one 0:00:30.060000 --> 0:00:33.860000 of the reasons why I want to highlight this is to sort of give you that 0:00:33.860000 --> 0:00:39.420000 practical example or that practical understanding as to what the difference 0:00:39.420000 --> 0:00:41.840000 is or what the difference looks like. 0:00:41.840000 --> 0:00:49.740000 So I've pointed out severally in the encoding section that there's client 0:00:49.740000 --> 0:00:54.880000 -side and server-side filtering or in that particular case encoding. 0:00:54.880000 --> 0:00:59.920000 And the reason again why I want to state this is pretty much all comes 0:00:59.920000 --> 0:01:05.560000 down to identifying or figuring out what type of filtering is going on, 0:01:05.560000 --> 0:01:10.620000 what type of you know sanitization if any is occurring in terms of characters 0:01:10.620000 --> 0:01:12.500000 being stripped etc. 0:01:12.500000 --> 0:01:15.920000 And one of the cool things that you'll see or rather from the web application 0:01:15.920000 --> 0:01:20.820000 developers perspective is not really a good thing but one of the cool 0:01:20.820000 --> 0:01:25.040000 things you'll see as a web app in tester is if you do run across a web 0:01:25.040000 --> 0:01:30.200000 application that is utilizing a client -side filtering alone, you will 0:01:30.200000 --> 0:01:34.900000 be able to view the actual filter being used and consequently bypass it 0:01:34.900000 --> 0:01:38.580000 because you'll be able to reverse engineer it or to understand what it's 0:01:38.580000 --> 0:01:42.300000 filtering and that'll give you possible ideas as to how you can bypass 0:01:42.300000 --> 0:01:46.580000 the filters. So as I pointed out in the previous video we'll be utilizing 0:01:46.580000 --> 0:01:48.380000 a live lab for this. 0:01:48.380000 --> 0:01:53.240000 So in order to get started just click on the lab below this video or the 0:01:53.240000 --> 0:01:58.620000 lab associated with this video and what will happen is you will be provided 0:01:58.620000 --> 0:02:04.700000 with a link to a deliberately vulnerable web application called OASP Motelide 0:02:04.700000 --> 0:02:09.360000 2 and the reason we're utilizing a deliberately vulnerable web application 0:02:09.360000 --> 0:02:19.680000 is for us to understand this to understand the increase in terms of the 0:02:19.680000 --> 0:02:23.760000 improvement to the filtering and how we can again consequently bypass 0:02:23.760000 --> 0:02:30.860000 that filtering by modifying the format or the syntax of the payload that 0:02:30.860000 --> 0:02:34.260000 we're using again based on the vulnerability we're targeting. 0:02:34.260000 --> 0:02:37.420000 But in most cases when you're dealing with client-side filters you're 0:02:37.420000 --> 0:02:41.880000 most likely testing for cross-site scripting you know specifically or 0:02:41.880000 --> 0:02:45.360000 in most cases it's going to be reflected cross-site scripting but you 0:02:45.360000 --> 0:02:49.260000 know stored cross-site scripting is also an option. 0:02:49.260000 --> 0:02:53.380000 So once you start it up you'll be provided with a link it'll open up in 0:02:53.380000 --> 0:02:58.480000 your browser take you directly to the vulnerable web application. 0:02:58.480000 --> 0:03:02.340000 This lab will not provide you with a calilinic system. 0:03:02.340000 --> 0:03:05.720000 What that means is that you can use your own so just open up the link 0:03:05.720000 --> 0:03:09.660000 within your own calilinic system and you'll be able to use any tools we 0:03:09.660000 --> 0:03:13.780000 don't require the use of any tools apart from just your browser and burp 0:03:13.780000 --> 0:03:17.940000 suite so again if you even if you're on windows or Mac this will work 0:03:17.940000 --> 0:03:22.480000 perfectly fine. So what I'm going to do is I'm going to start up the lab 0:03:22.480000 --> 0:03:26.720000 and switch over into it and we can get started you know we're taking a 0:03:26.720000 --> 0:03:28.880000 look at how we can bypass client-side filters. 0:03:28.880000 --> 0:03:33.160000 So that being said let me switch over and I'll see you there. 0:03:33.160000 --> 0:03:38.000000 All right so I'm back in my calilinic system and as you can see I've opened 0:03:38.000000 --> 0:03:42.360000 up the vulnerable web application that you'll be provided with access 0:03:42.360000 --> 0:03:47.940000 to once you start up the lab and you can see it's running OASMOTILIDATE2. 0:03:47.940000 --> 0:03:52.940000 Now one of the reasons I love using OASMOTILIDATE to introduce concepts 0:03:52.940000 --> 0:03:58.360000 is primarily because number one it has plenty of examples of you know 0:03:58.360000 --> 0:04:02.520000 in this case application inputs that you're likely to find out in the 0:04:02.520000 --> 0:04:06.740000 wild in terms of the implementation and secondly it has the ability to 0:04:06.740000 --> 0:04:13.020000 increase the security level consequently making the web application less 0:04:13.020000 --> 0:04:17.720000 and less vulnerable by improving the security or essentially you know 0:04:17.720000 --> 0:04:20.340000 fixing any of the vulnerability. 0:04:20.340000 --> 0:04:23.500000 So I really like MOTILIDATE for that. 0:04:23.500000 --> 0:04:26.740000 With that being said we don't need to log in or register what we want 0:04:26.740000 --> 0:04:32.880000 to do is navigate to OASM 2017 and into cross-site scripting reflected 0:04:32.880000 --> 0:04:37.760000 first order and we'll just click on the first sample web application that 0:04:37.760000 --> 0:04:40.620000 is vulnerable to reflected cross-site scripting. 0:04:40.620000 --> 0:04:45.260000 So there we are it looks like a simple web application that allows a user 0:04:45.260000 --> 0:04:51.260000 to enter an IP or or a hostname and it'll then perform a DNS lookup on 0:04:51.260000 --> 0:04:59.700000 that IP or based on the way it works we could also test for command injection. 0:04:59.700000 --> 0:05:04.760000 So for example if we said something like ID you can see that doesn't work 0:05:04.760000 --> 0:05:11.100000 and we can try obviously you know trying to add some filter bypasses for 0:05:11.100000 --> 0:05:13.980000 command injection and there you go there we are. 0:05:13.980000 --> 0:05:18.520000 So just by adding a semicolon which terminates the previous command or 0:05:18.520000 --> 0:05:22.960000 ends the previous command and runs whatever comes after we can see that 0:05:22.960000 --> 0:05:26.280000 we're able to you know essentially bypass that filter. 0:05:26.280000 --> 0:05:31.560000 Now if you want to view the actual you know the actual source code for 0:05:31.560000 --> 0:05:37.320000 this particular web application we can just right click and click on view 0:05:37.320000 --> 0:05:41.900000 page source and you want to scroll all the way to the bottom and look 0:05:41.900000 --> 0:05:48.120000 for the HTML comment that says beginning or begin HTML output all right. 0:05:48.120000 --> 0:05:53.260000 So this is where the actual web application lies in terms of the functionality. 0:05:53.260000 --> 0:05:58.040000 So let me just navigate to that point here and there we are. 0:05:58.040000 --> 0:06:04.500000 So we can see that it is the we have the actual JavaScript code here with 0:06:04.500000 --> 0:06:08.620000 the actual filters and in this particular case it looks like a rejects 0:06:08.620000 --> 0:06:09.880000 pattern is specified. 0:06:09.880000 --> 0:06:16.020000 So we can see there is a variable with OS command injection pattern and 0:06:16.020000 --> 0:06:20.660000 that's equal to and there we have the the actual pattern being specified 0:06:20.660000 --> 0:06:24.380000 in this case no pattern because we're running at the lowest security level 0:06:24.380000 --> 0:06:31.280000 and that means that even in the in the case of command injection that 0:06:31.280000 --> 0:06:32.220000 shouldn't be an issue. 0:06:32.220000 --> 0:06:37.580000 So we can see that right over here ampersand and semicolon are not allowed 0:06:37.580000 --> 0:06:45.040000 that's command injection and then for cross-site scripting we can see 0:06:45.040000 --> 0:06:50.340000 so command injection pattern zero or nothing and cross-site scripting 0:06:50.340000 --> 0:06:55.060000 pattern is set to nothing as well in terms of rejects being included. 0:06:55.060000 --> 0:06:59.580000 So this is in the form of a you know if statement that essentially checks 0:06:59.580000 --> 0:07:06.340000 for whatever is input and whether it matches the actual pattern and then 0:07:06.340000 --> 0:07:10.840000 based on whether it does or not it'll then display these these alerts. 0:07:10.840000 --> 0:07:14.500000 So in this case you can see that ampersand and semicolon are not allowed 0:07:14.500000 --> 0:07:19.020000 don't listen to security people everyone knows if we just filtered dangerous 0:07:19.020000 --> 0:07:22.280000 characters cross-site scripting is not possible. 0:07:22.280000 --> 0:07:26.100000 All right so it's a little bit of a comedy here which I like the point 0:07:26.100000 --> 0:07:32.400000 that is trying to make is that you know in this particular case what's 0:07:32.400000 --> 0:07:36.700000 being filtered as least at least in this particular case is going to be 0:07:36.700000 --> 0:07:41.380000 what is considered dangerous characters which in this case the web application 0:07:41.380000 --> 0:07:47.880000 developer seems to have thought are semicolons or the ampersand and in 0:07:47.880000 --> 0:07:52.620000 this particular case you can see that or cross-site scripting it says 0:07:52.620000 --> 0:07:56.160000 characters used in cross-site scripting are not allowed so these are just 0:07:56.160000 --> 0:08:02.300000 message messages displayed when a violation of the rejects pattern is 0:08:02.300000 --> 0:08:06.540000 found. So the key thing I want you to notice this is JavaScript so this 0:08:06.540000 --> 0:08:11.120000 is all being done on the client side and what that means is that if a 0:08:11.120000 --> 0:08:15.320000 filter is implemented here on the client side you'll be able to view it 0:08:15.320000 --> 0:08:19.900000 and then understand you know if there is in this case a rejects pattern 0:08:19.900000 --> 0:08:21.960000 you'll be able to understand how to bypass it. 0:08:21.960000 --> 0:08:32.920000 So if we now try to perform some cross -site scripting you know like an 0:08:32.920000 --> 0:08:39.360000 example alert we can enclose this script tag there we are you can see 0:08:39.360000 --> 0:08:42.720000 it's vulnerable to reflected cross-site scripting which is what we expect 0:08:42.720000 --> 0:08:46.720000 it is also a vulnerable to command injection in this case it would not 0:08:46.720000 --> 0:08:51.380000 be a target for SQL injection because it's not interacting with a database 0:08:51.380000 --> 0:08:57.820000 so in essence what's happening is fairly simple and again if we view the 0:08:57.820000 --> 0:09:02.600000 page source here and we take a look at where the form actually falls you 0:09:02.600000 --> 0:09:08.080000 can see that the action is pretty simple DNS lookup.php and we can probably 0:09:08.080000 --> 0:09:11.940000 try and open up that link in a new tab here in terms of how that works 0:09:11.940000 --> 0:09:17.300000 but that's pretty much the same PHP script or file that we're looking 0:09:17.300000 --> 0:09:25.540000 at here. So we also have the actual you know we also have the actual form 0:09:25.540000 --> 0:09:33.280000 as well as the inclusion of additional headers or HTTP headers but right 0:09:33.280000 --> 0:09:38.900000 over here under where we have the actual you know host name IP specification 0:09:38.900000 --> 0:09:47.220000 we can see that the input type is that of text and the ID's ID target 0:09:47.220000 --> 0:09:53.400000 host input and the autofocus is set there OS command injection point is 0:09:53.400000 --> 0:10:00.580000 one so we can do a little bit is that you know it's fairly easy to understand 0:10:00.580000 --> 0:10:06.360000 and you know we can sort of play around with the with the output so if 0:10:06.360000 --> 0:10:11.580000 we go back to the actual source and let me just open the fresh one here 0:10:11.580000 --> 0:10:20.820000 and let's go and see how things are output we can see that in this particular 0:10:20.820000 --> 0:10:27.700000 case just trying to see where we have the JavaScript code if we take a 0:10:27.700000 --> 0:10:39.160000 look at this here the HTML output yeah so we can see that that works fairly 0:10:39.160000 --> 0:10:46.680000 simply and then the else if and it returned true so we can see on submit 0:10:46.680000 --> 0:10:52.400000 a form and it pretty much reflects back what was input so let's increase 0:10:52.400000 --> 0:10:56.860000 the security or toggle the security to client side security by clicking 0:10:56.860000 --> 0:11:01.160000 on toggle security here and there we are so that means you know things 0:11:01.160000 --> 0:11:06.200000 are a bit harder this time which is perfectly fine so now we view the 0:11:06.200000 --> 0:11:11.700000 actual source here and again I'll just zoom in and we'll navigate all 0:11:11.700000 --> 0:11:17.980000 the way to the bottom where the actual HTML content is and you can now 0:11:17.980000 --> 0:11:25.260000 see that right over here in terms of the rejects pattern or cross-site 0:11:25.260000 --> 0:11:33.640000 scripting it looks like that has increased so we can now see here there's 0:11:33.640000 --> 0:11:39.420000 the rejects pattern what is being filtered and if we enter any information 0:11:39.420000 --> 0:11:46.320000 or data or text rather that contains any of these symbols this message 0:11:46.320000 --> 0:11:50.560000 will be displayed in terms of cross -site scripting so characters used 0:11:50.560000 --> 0:11:53.240000 in cross-site scripting are not allowed so let's actually test it out 0:11:53.240000 --> 0:11:58.540000 so this is one of the reasons why client side filters are not implemented 0:11:58.540000 --> 0:12:02.920000 anymore because again the filtering in the event you are utilizing rejects 0:12:02.920000 --> 0:12:09.340000 filters can easily be deciphered so we can immediately just you know try 0:12:09.340000 --> 0:12:13.120000 and test this out and see whether it is indeed blocking the greater than 0:12:13.120000 --> 0:12:20.140000 and less than symbols let's say alert here and we'll just say one and 0:12:20.140000 --> 0:12:25.480000 then script and oh interesting for some reason I can type more than a 0:12:25.480000 --> 0:12:31.460000 certain set of characters and is there any limit on this being imposed 0:12:31.460000 --> 0:12:36.980000 well we can try and see that by taking a look at the actual form and indeed 0:12:36.980000 --> 0:12:42.260000 there is so for the input we can see that it is limited to a maximum length 0:12:42.260000 --> 0:12:48.120000 of 20 so that's another side of validation if you will input it's another 0:12:48.120000 --> 0:12:53.960000 technique input filtering technique specifically that falls specifically 0:12:53.960000 --> 0:12:58.260000 under data validation and this could be implemented for you know various 0:12:58.260000 --> 0:13:03.800000 reasons but the point is that it is implemented so this is limited to 0:13:03.800000 --> 0:13:10.120000 just the input form within the actual HTML or in this case the PHP page 0:13:10.120000 --> 0:13:16.140000 but but and this is very important we can easily bypass this with burp 0:13:16.140000 --> 0:13:21.120000 suite so I'm just going to open up burp suite here and the way we bypass 0:13:21.120000 --> 0:13:26.980000 this is just by as you obviously guessed just putting in some sample data 0:13:26.980000 --> 0:13:32.280000 and then intercepting that particular get request or post request we'll 0:13:32.280000 --> 0:13:37.620000 see shortly and modifying you know whatever was input with the actual 0:13:37.620000 --> 0:13:42.720000 payload so I'll open up the burp browser and I'll open up this particular 0:13:42.720000 --> 0:13:48.680000 page here and we'll just navigate to it and I'll just forward that there 0:13:48.680000 --> 0:13:55.280000 and there we are the security level is set to zero so I'll just toggle 0:13:55.280000 --> 0:14:01.660000 it again to one and we will wait for that to load up there we are and 0:14:01.660000 --> 0:14:07.420000 now we will just enter some random data here like you know payload and 0:14:07.420000 --> 0:14:13.920000 just click on lookup DNS and we now within the actual post right over 0:14:13.920000 --> 0:14:18.260000 here we'll be able to identify where that is so that's under the actual 0:14:18.260000 --> 0:14:25.780000 content of the of the actual request and we can pretty much change this 0:14:25.780000 --> 0:14:31.260000 here so this is where we would put in our actual payload so we can say 0:14:31.260000 --> 0:14:36.000000 alert right over here again just testing to see whether the input filtering 0:14:36.000000 --> 0:14:41.900000 is still valid and you'll see one of the you'll actually identify one 0:14:41.900000 --> 0:14:45.580000 of the issues here so I'll just forward that and you can see that that 0:14:45.580000 --> 0:14:52.260000 worked now why is this the case why is this the case the reason this is 0:14:52.260000 --> 0:14:58.860000 the case is because and this is one of the disadvantages with input filtering 0:14:58.860000 --> 0:15:05.160000 on the client side is that we can easily bypass the restrictions around 0:15:05.160000 --> 0:15:10.180000 the application input by just modifying the request right so the point 0:15:10.180000 --> 0:15:15.120000 is that you know if I try to enter something like script here again not 0:15:15.120000 --> 0:15:19.560000 modifying the get request and you can see before I even do anything because 0:15:19.560000 --> 0:15:24.960000 it's a client side filter implemented through JavaScript JavaScript is 0:15:24.960000 --> 0:15:30.080000 being runs within the browser and essentially runs that snippet and it 0:15:30.080000 --> 0:15:35.640000 knows you know if any of if the application input or any data that's input 0:15:35.640000 --> 0:15:42.220000 essentially matches with the the actual rejects pattern this is the message 0:15:42.220000 --> 0:15:47.180000 to be displayed so in this case it says you know pretty much that there 0:15:47.180000 --> 0:15:51.520000 is filtering in place but we were easily able to bypass it not by even 0:15:51.520000 --> 0:15:57.260000 using any specific tags you know just by modifying the actual request 0:15:57.260000 --> 0:16:02.640000 and including the actual payload in there and now it also appears that 0:16:02.640000 --> 0:16:06.400000 there isn't any server side filtering and in most cases there wouldn't 0:16:06.400000 --> 0:16:11.700000 be but in this case it looks like it was only implemented on the actual 0:16:11.700000 --> 0:16:18.880000 on the actual client side and then of course you know we can we can try 0:16:18.880000 --> 0:16:24.800000 out a a plethora of different of different cross-site scripting payloads 0:16:24.800000 --> 0:16:29.440000 but in this case the bypass was fairly simple there's also other ways 0:16:29.440000 --> 0:16:35.160000 of bypassing this so for example we can easily bypass this by you know 0:16:35.160000 --> 0:16:41.380000 running or trying to disable JavaScript from running within a particular 0:16:41.380000 --> 0:16:47.500000 page so if we try and say script and alert let's see if I can if that 0:16:47.500000 --> 0:16:51.620000 particular add-on I was able to do that now in this case it looks like 0:16:51.620000 --> 0:16:57.860000 it's not doing this but we can easily disable JavaScript and we can actually 0:16:57.860000 --> 0:17:03.920000 modify the limit that is imposed on the input here the the actual html 0:17:03.920000 --> 0:17:10.640000 limit for the form just by using inspect element here so we'll just locate 0:17:10.640000 --> 0:17:16.800000 the actual the actual input box here or text box if you will and what 0:17:16.800000 --> 0:17:22.020000 we want to do is just look for the maximum length and we can modify that 0:17:22.020000 --> 0:17:27.780000 easily and you know we can set that to a hundred and now again you can 0:17:27.780000 --> 0:17:31.560000 already see that that was imposed and we currently have the security level 0:17:31.560000 --> 0:17:37.180000 set to one we can now put in a payload here so we'll just set the full 0:17:37.180000 --> 0:17:40.620000 one and now you can see that that limit has been removed this is one of 0:17:40.620000 --> 0:17:45.900000 the issues with client side filtering or restrictions or validation if 0:17:45.900000 --> 0:17:50.500000 you will but if I now click on lookup DNS the filtering looks like it 0:17:50.500000 --> 0:17:59.000000 is enabled but if I run the the actual add-on here that disables JavaScript 0:17:59.000000 --> 0:18:05.180000 on this page there we are you can see that it looked like it was vulnerable 0:18:05.180000 --> 0:18:10.440000 but let's try it again here let's just run all right so it's currently 0:18:10.440000 --> 0:18:20.080000 active and now if we try and put in we'd actually need to modify the html 0:18:20.080000 --> 0:18:25.520000 limit there for the actual form so we'll just navigate to where that is 0:18:25.520000 --> 0:18:31.900000 and of course we can just modify the limit here because that'll change 0:18:31.900000 --> 0:18:38.280000 every time you refresh the page because we're not just what is on the 0:18:38.280000 --> 0:18:42.140000 client side when we make a request and receive the resource and from this 0:18:42.140000 --> 0:18:46.640000 point on I can now say put in the payload there hit lookup and you can 0:18:46.640000 --> 0:18:54.920000 now see that in this particular case it is it's still giving us that pop 0:18:54.920000 --> 0:18:58.400000 -up telling us that you know we have some illegal characters which is fine 0:18:58.400000 --> 0:19:04.960000 let's try and modify the actual JavaScript or disable it completely so 0:19:04.960000 --> 0:19:08.560000 what I'll do is I've just refreshed the page and I'll just change the 0:19:08.560000 --> 0:19:15.700000 limit here the max length and I'll put in my JavaScript tag here or actually 0:19:15.700000 --> 0:19:20.120000 let's put that in after a second and the add-on I'm using is just called 0:19:20.120000 --> 0:19:33.680000 disable JavaScript so I'll run it here and there we go I'll need to or 0:19:33.680000 --> 0:19:38.720000 100 we don't want to set it to zero obviously and we put in our tag and 0:19:38.720000 --> 0:19:43.640000 because I've disabled JavaScript if I hit click or lookup here we can 0:19:43.640000 --> 0:19:48.380000 see that nothing happens or nothing is reflected back and that actually 0:19:48.380000 --> 0:19:53.140000 makes sense and I'll explain why so let's try this again I can disable 0:19:53.140000 --> 0:19:58.020000 it on the second run so I'll set that to 100 and I'll just say script 0:19:58.020000 --> 0:20:06.060000 and lookup and in this particular case let's see that's currently let's 0:20:06.060000 --> 0:20:12.040000 run that again so we'll re-send it and there we are so fantastic we were 0:20:12.040000 --> 0:20:17.140000 able to disable it at that point and as a result again still security 0:20:17.140000 --> 0:20:22.200000 level one with the client side filtering we were still able to you know 0:20:22.200000 --> 0:20:26.140000 pretty much exploit the reflected cross -site scripting vulnerability or 0:20:26.140000 --> 0:20:31.380000 bypass the the input filter that was utilizing a rejects pattern or rejects 0:20:31.380000 --> 0:20:36.480000 filter if you will and that's pretty much you know client side filtering 0:20:36.480000 --> 0:20:41.120000 in a nutshell as I said you will really find it in modern web applications 0:20:41.120000 --> 0:20:46.480000 and one final thing that I want to show you as a resource that you can 0:20:46.480000 --> 0:20:52.500000 utilize is going to be the actual it's going to be a very cool website 0:20:52.500000 --> 0:20:57.480000 called rejects 101 if you're not familiar with regular expressions but 0:20:57.480000 --> 0:21:05.180000 if I you know for example if I just go right over here into let's say 0:21:05.180000 --> 0:21:09.520000 I'm just going to open up the source and let's take a look at the rejects 0:21:09.520000 --> 0:21:14.680000 being used so we have this pattern right over here right so fairly simple 0:21:14.680000 --> 0:21:18.660000 to understand in terms of what's going on for me but you can always just 0:21:18.660000 --> 0:21:24.940000 copy a rejects pattern and take it to rejects 101.com where it'll tell 0:21:24.940000 --> 0:21:29.800000 you what's going on so I'll paste that in there and I'll just add the 0:21:29.800000 --> 0:21:35.800000 forward slash there and for some reason it's telling me that this is not 0:21:35.800000 --> 0:21:41.080000 implemented correctly so we have does not match the subject string actually 0:21:41.080000 --> 0:21:48.060000 that makes sense so we'll just set that here let me just copy that as 0:21:48.060000 --> 0:22:02.100000 is and I'll put it in here there we are and we can actually just say you 0:22:02.100000 --> 0:22:18.620000 know this is not dynamic so I'll just paste that in here and we can actually 0:22:18.620000 --> 0:22:24.620000 just include the the dollar symbol there there we are so now this allows 0:22:24.620000 --> 0:22:36.460000 you to see what will be blocked so script alert is one script here and 0:22:36.460000 --> 0:22:49.820000 that doesn't look correct if I try and switch to sorry global and now 0:22:49.820000 --> 0:22:56.380000 if we put in a particular cross-site scripting payload in here you can 0:22:56.380000 --> 0:23:00.380000 see that it matches pretty much right over here matches a single character 0:23:00.380000 --> 0:23:06.220000 in the list so if any of these matches and at that point it would display 0:23:06.220000 --> 0:23:11.680000 this particular message right over here so it's not a very good rejects 0:23:11.680000 --> 0:23:16.780000 filter because again it's just looking for either or pretty much just 0:23:16.780000 --> 0:23:23.120000 one and at that point this can again easily be bypassed by you know leveraging 0:23:23.120000 --> 0:23:27.280000 another cross-site scripting payload that you know does not utilize the 0:23:27.280000 --> 0:23:34.120000 the less than symbol right over here but rejects 101 is a great place 0:23:34.120000 --> 0:23:39.480000 to learn about regular expressions and also test your particular payloads 0:23:39.480000 --> 0:23:44.220000 against a regular expression being used you know most likely on the client 0:23:44.220000 --> 0:23:48.220000 side for filtering or validation if you will but more so filtering and 0:23:48.220000 --> 0:23:52.500000 of course sanitization but in this case nothing is being sanitized or 0:23:52.500000 --> 0:23:58.240000 stripped it's pretty much just you know preventing it's just preventing 0:23:58.240000 --> 0:24:02.520000 you from actually sending it to the web server for it to be reflected 0:24:02.520000 --> 0:24:08.660000 back so that is going to conclude the practical demonstration side of 0:24:08.660000 --> 0:24:16.020000 this video all right so that is how client side filtering works specifically 0:24:16.020000 --> 0:24:20.700000 with with JavaScript and as I said there's many other techniques that 0:24:20.700000 --> 0:24:25.900000 are implemented the bottom line as you were able to see is that you know 0:24:25.900000 --> 0:24:31.880000 it's very very simple to bypass primarily because the JavaScript filtering 0:24:31.880000 --> 0:24:37.920000 or the JavaScript code that is responsible for the filtering or even validation 0:24:37.920000 --> 0:24:45.720000 or even sanitization is included or is a resource that is locally accessible 0:24:45.720000 --> 0:24:49.940000 within your web browser or on the client side as a result it makes it 0:24:49.940000 --> 0:24:54.360000 easier to understand you know what exactly is happening with regards to 0:24:54.360000 --> 0:25:01.140000 the filtering so what is being blocked so on and and so forth so I would 0:25:01.140000 --> 0:25:06.180000 highly recommend that you take a look at you know rejects filtering because 0:25:06.180000 --> 0:25:11.020000 rejects filtering is not limited just to the client side it is a technique 0:25:11.020000 --> 0:25:16.080000 that also applies itself to the server side and if you get a better feel 0:25:16.080000 --> 0:25:20.940000 and understanding as to what are some of the common rejects patterns utilized 0:25:20.940000 --> 0:25:26.360000 let's say to block cross-site scripting attacks then you'll be able to 0:25:26.360000 --> 0:25:31.060000 pretty much identify or to find the correct cross-site scripting payload 0:25:31.060000 --> 0:25:35.860000 to use that will be able to bypass that particular pattern or evade it 0:25:35.860000 --> 0:25:40.100000 if you will with that being said that is going to conclude this video 0:25:40.100000 --> 0:25:44.000000 that brings us to the end of this video and in the next video we'll be 0:25:44.000000 --> 0:25:50.580000 talking about bypassing server side filtering or server side filters so