WEBVTT

0:00:03.560000 --> 0:00:08.640000
 Hello everyone and welcome to the
 filtering section of this course.

0:00:08.640000 --> 0:00:12.220000
 In this particular section we're going
 to be kicking off by getting a

0:00:12.220000 --> 0:00:15.720000
 formal introduction to input filtering.

0:00:15.720000 --> 0:00:20.460000
 So the idea here is to define it, to
 understand what it's all about in

0:00:20.460000 --> 0:00:25.220000
 terms of how it is implemented and more
 importantly why it is implemented.

0:00:25.220000 --> 0:00:29.980000
 And of course in this case it's pretty
 self-explanatory that input filtering

0:00:29.980000 --> 0:00:36.860000
 is not only used to ensure that data
 or information that is being input

0:00:36.860000 --> 0:00:42.480000
 into a web application is in a specific
 format but also to prevent the

0:00:42.480000 --> 0:00:50.000000
 inclusion of potentially malicious data
 that could be either interpreted

0:00:50.000000 --> 0:00:54.860000
 by the web server or reflected back
 and interpreted by the web browser

0:00:54.860000 --> 0:00:58.560000
 and consequently lead to a potential
 vulnerability or the exploitation

0:00:58.560000 --> 0:01:00.360000
 of vulnerability.

0:01:00.360000 --> 0:01:04.420000
 And in this specific case when we take
 a look at two of the most common

0:01:04.420000 --> 0:01:09.980000
 types of vulnerabilities that are caused
 by application input or rather

0:01:09.980000 --> 0:01:15.360000
 input we obviously come across cross
-site scripting, SQL injection, also

0:01:15.360000 --> 0:01:18.520000
 command injection among a couple.

0:01:18.520000 --> 0:01:22.980000
 So the point here is to get that formal
 introduction and then in the next

0:01:22.980000 --> 0:01:27.480000
 set of videos we'll be taking a look
 at client side filtering, server

0:01:27.480000 --> 0:01:31.400000
 side filtering and then we'll also
 take a look at a real world example

0:01:31.400000 --> 0:01:38.320000
 of how you can essentially bypass server
 side cross-site scripting filters

0:01:38.320000 --> 0:01:44.100000
 and again this will be done using a
 lab in a real world web application.

0:01:44.100000 --> 0:01:49.880000
 So in order to get started or the way
 I like starting off when explaining

0:01:49.880000 --> 0:01:55.280000
 or describing this particular technique
 and again this can be considered

0:01:55.280000 --> 0:02:02.460000
 a security measure is by giving you the
 formal introduction and then sort

0:02:02.460000 --> 0:02:05.220000
 of outlining what you're
 likely to encounter.

0:02:05.220000 --> 0:02:07.900000
 So firstly what is filtering?

0:02:07.900000 --> 0:02:13.020000
 Well, filtering in web application
 security refers to the practice of

0:02:13.020000 --> 0:02:18.040000
 inspecting and controlling data input
 and output in a web application

0:02:18.040000 --> 0:02:21.880000
 to prevent security vulnerabilities
 and protect against various types

0:02:21.880000 --> 0:02:26.700000
 of attacks. It is a common and standard
 practice to protect web applications

0:02:26.700000 --> 0:02:32.320000
 against malicious attacks with input filtering
 and output encoding controls.

0:02:32.320000 --> 0:02:37.260000
 So input filtering and essentially ensuring
 that whatever is being input

0:02:37.260000 --> 0:02:41.220000
 is being filtered or sanitized makes
 sense but you may be wondering to

0:02:41.220000 --> 0:02:46.460000
 yourself why does filtering also
 involve what is being output?

0:02:46.460000 --> 0:02:50.340000
 Well, we've already taken a look at
 an example of filtering if you would

0:02:50.340000 --> 0:02:54.860000
 believe it in the previous section, in
 the encoding section when we explored

0:02:54.860000 --> 0:03:00.080000
 HTML encoding. Now if you remember
 in that particular case what we're

0:03:00.080000 --> 0:03:04.040000
 done it will sort of not a very well
 put together web application but

0:03:04.040000 --> 0:03:10.620000
 we were utilizing PHP and we utilized
 the HTML and code function and in

0:03:10.620000 --> 0:03:14.280000
 that particular case and as I mentioned
 in the previous section as well

0:03:14.280000 --> 0:03:20.780000
 when you're dealing with filters what
 you need to understand is that firstly

0:03:20.780000 --> 0:03:24.280000
 you need to understand what type of
 filter it is with regards to where

0:03:24.280000 --> 0:03:29.520000
 it falls. So is it a client side filter
 if so it's most likely implemented

0:03:29.520000 --> 0:03:34.600000
 or it most likely utilizes JavaScript.

0:03:34.600000 --> 0:03:39.600000
 Is it a server side filter and in both
 of those cases or in each of those

0:03:39.600000 --> 0:03:44.820000
 cases that will I don't like using the word
 drastically but it will drastically

0:03:44.820000 --> 0:03:50.520000
 change your approach in terms of how
 you'll be or the payloads you'll

0:03:50.520000 --> 0:03:55.680000
 be using. So the point is that in that
 example where we took a look at

0:03:55.680000 --> 0:04:01.300000
 the HTML encoding web application that
 we actually developed if you realized

0:04:01.300000 --> 0:04:06.500000
 during the video I actually made a couple
 of changes to highlight my point

0:04:06.500000 --> 0:04:11.060000
 whereby and my point in this particular
 case or in that particular case

0:04:11.060000 --> 0:04:18.040000
 was that once you send input into an application
 input on a web application

0:04:18.040000 --> 0:04:23.380000
 there may be a client side filter which
 is perfectly fine and there could

0:04:23.380000 --> 0:04:27.980000
 be a server side filter however the
 key thing to note is what is done

0:04:27.980000 --> 0:04:31.940000
 with that data. So in the case of cross
-site scripting vulnerabilities

0:04:31.940000 --> 0:04:36.940000
 and in the case of reflected cross-site
 scripting vulnerabilities we know

0:04:36.940000 --> 0:04:40.800000
 that regardless of where the filter falls
 whether it's in the client side

0:04:40.800000 --> 0:04:47.820000
 or on the server side if the web application
 input does not reflect back

0:04:47.820000 --> 0:04:52.260000
 what was input and does not reflect
 it in a way that can be interpreted

0:04:52.260000 --> 0:04:56.660000
 by your web browser then it doesn't
 matter whether you're able to bypass

0:04:56.660000 --> 0:05:01.320000
 a filter. So it's very important
 that you keep that in mind.

0:05:01.320000 --> 0:05:07.280000
 Now in the case of SQL injection vulnerabilities
 and if you've gone through

0:05:07.280000 --> 0:05:12.900000
 the SQL injection course you know that
 identifying application inputs

0:05:12.900000 --> 0:05:16.700000
 that are utilizing or that are interacting
 with the database is fairly

0:05:16.700000 --> 0:05:21.400000
 simple and in the case of SQL injection
 vulnerabilities finding them is

0:05:21.400000 --> 0:05:26.940000
 relatively simple given the nature
 of the vulnerability but what that

0:05:26.940000 --> 0:05:31.860000
 means is that you're more likely to
 be able to identify any potential

0:05:31.860000 --> 0:05:37.200000
 filtering in the case of SQL injection
 and furthermore bypass it because

0:05:37.200000 --> 0:05:42.120000
 in terms of the implementation it's fairly
 simple or you know it's fairly

0:05:42.120000 --> 0:05:46.980000
 well understood what goes on once you
 type in let's say a username and

0:05:46.980000 --> 0:05:54.000000
 password that really in that context
 is no input filtering or security

0:05:54.000000 --> 0:05:58.360000
 filtering from the client side and I'll
 explain why because you're just

0:05:58.360000 --> 0:06:01.660000
 sending a username and a password
 or an email and a password.

0:06:01.660000 --> 0:06:07.500000
 So in that particular case it's most
 likely that you will encounter the

0:06:07.500000 --> 0:06:12.680000
 filtering on the server side so that
 means that once the actual data or

0:06:12.680000 --> 0:06:17.780000
 credentials are received on the web
 server there is going to be a filter

0:06:17.780000 --> 0:06:21.840000
 that prevents you know the use of specific
 characters but the point is

0:06:21.840000 --> 0:06:28.920000
 that in that particular case the filtering
 is usually implemented on the

0:06:28.920000 --> 0:06:34.100000
 server side so the underlying point
 that I have here is that filtering

0:06:34.100000 --> 0:06:38.860000
 is a critical aspect of security because
 it helps ensure that data entering

0:06:38.860000 --> 0:06:43.480000
 and leaving the web application is
 safe valid and free from malicious

0:06:43.480000 --> 0:06:46.160000
 content or potential exploits.

0:06:46.160000 --> 0:06:50.420000
 Web application inputs are often targeted
 by web app pen testers to assess

0:06:50.420000 --> 0:06:55.280000
 the effectiveness of security measures and
 to discover potential vulnerabilities.

0:06:55.280000 --> 0:07:00.060000
 So that begs the question what is input
 filtering now you know in the

0:07:00.060000 --> 0:07:04.000000
 context of a web app pen test
 or web app pen testing.

0:07:04.000000 --> 0:07:10.000000
 Well input filtering as a process involves
 validating and or sanitizing

0:07:10.000000 --> 0:07:16.140000
 data that is received by the web application
 from users or external sources.

0:07:16.140000 --> 0:07:21.760000
 Input filtering helps prevent security
 vulnerabilities like SQL injection,

0:07:21.760000 --> 0:07:26.280000
 cross-site scripting and even you know
 command injection and some common

0:07:26.280000 --> 0:07:30.900000
 techniques for input filtering include
 data validation, input validation

0:07:30.900000 --> 0:07:36.060000
 and input sanitization among many others
 that will be exploring right

0:07:36.060000 --> 0:07:41.100000
 now. So what is data validation or
 you know where does this fall with

0:07:41.100000 --> 0:07:42.900000
 regards to input filtering.

0:07:42.900000 --> 0:07:47.380000
 Data validation as the name suggests
 is pretty self-explanatory.

0:07:47.380000 --> 0:07:52.480000
 Data validation checks whether the
 incoming data conforms to expected

0:07:52.480000 --> 0:07:54.860000
 formats and constraints.

0:07:54.860000 --> 0:08:00.900000
 For example it ensures that email addresses
 follow a valid format or that

0:08:00.900000 --> 0:08:04.380000
 numeric fields contain only numbers.

0:08:04.380000 --> 0:08:09.140000
 Invalid or unexpected data should
 be rejected or sanitized.

0:08:09.140000 --> 0:08:13.440000
 Alright so data validation is frequently
 implemented not as a security

0:08:13.440000 --> 0:08:17.840000
 measure but just for that validation.

0:08:17.840000 --> 0:08:22.000000
 So a good example is a login form where
 you know a username and a password

0:08:22.000000 --> 0:08:27.480000
 input field. In that case it's always
 wide wise on the client side to

0:08:27.480000 --> 0:08:32.600000
 implement these validation checks to
 ensure that someone only enters a

0:08:32.600000 --> 0:08:36.960000
 valid email or enters a valid email
 and when I say valid what I mean by

0:08:36.960000 --> 0:08:41.860000
 that is that it follows the typical
 format of an email address.

0:08:41.860000 --> 0:08:45.860000
 So you know Alexis at iene.com.

0:08:45.860000 --> 0:08:50.700000
 The point is that the actual JavaScript
 function that will perform that

0:08:50.700000 --> 0:08:54.700000
 check will just ensure with you know
 rejects or something like that that

0:08:54.700000 --> 0:09:04.560000
 the string input contains the symbol
 at and you know the characters.com

0:09:04.560000 --> 0:09:07.180000
 for example.net.org etc.

0:09:07.180000 --> 0:09:11.160000
 But that's just an example it's not really
 to prevent any security vulnerability

0:09:11.160000 --> 0:09:13.120000
 because that's not enough.

0:09:13.120000 --> 0:09:16.120000
 This is where you now
 have input validation.

0:09:16.120000 --> 0:09:21.160000
 So input validation goes a step further
 by not only checking data formats

0:09:21.160000 --> 0:09:26.680000
 but also assessing data for
 potential security threats.

0:09:26.680000 --> 0:09:30.500000
 It detects and rejects input that could
 be used for attacks you know like

0:09:30.500000 --> 0:09:33.620000
 SQL injection payloads
 or malicious scripts.

0:09:33.620000 --> 0:09:35.240000
 You then have input sanitization.

0:09:35.240000 --> 0:09:41.900000
 This is pretty much the most common
 type of input filtering technique

0:09:41.900000 --> 0:09:47.080000
 that you'll come across or you know
 input filtering methodology.

0:09:47.080000 --> 0:09:51.740000
 And input sanitization essentially
 involves cleaning or escaping input

0:09:51.740000 --> 0:09:56.740000
 data to remove or neutralize potentially
 dangerous characters or content.

0:09:56.740000 --> 0:10:01.820000
 A good example of this is converting special
 characters to the HTML entities

0:10:01.820000 --> 0:10:07.700000
 as we saw already in the
 HTML encoding video.

0:10:07.700000 --> 0:10:11.980000
 And this is very very useful because
 it can prevent cross-site scripting

0:10:11.980000 --> 0:10:15.600000
 attacks by rendering malicious
 scripts harmless.

0:10:15.600000 --> 0:10:19.320000
 And that's very common in the case
 of reflected cross-site scripting.

0:10:19.320000 --> 0:10:24.120000
 Now in terms of you know what I wouldn't
 I wouldn't call these particular

0:10:24.120000 --> 0:10:28.660000
 techniques input filtering techniques
 but more so techniques that are

0:10:28.660000 --> 0:10:34.400000
 implemented to prevent you know specific
 input or specific data from being

0:10:34.400000 --> 0:10:37.340000
 sent to the actual web server.

0:10:37.340000 --> 0:10:40.500000
 And examples of these are the you
 know content security policy.

0:10:40.500000 --> 0:10:45.480000
 This is a security feature that controls
 which sources of content are

0:10:45.480000 --> 0:10:47.760000
 allowed to be loaded by a web page.

0:10:47.760000 --> 0:10:51.580000
 And it helps prevent cross-site scripting
 attacks by specifying which

0:10:51.580000 --> 0:10:56.480000
 domains are permitted sources for script
 styles, images and other resources.

0:10:56.480000 --> 0:11:00.420000
 You then have you know your
 standard CSRF protection.

0:11:00.420000 --> 0:11:04.120000
 So filtering mechanisms can be used to
 implement CSRF protection ensuring

0:11:04.120000 --> 0:11:09.760000
 that incoming requests have valid anti
-CSRF tokens to prevent attackers

0:11:09.760000 --> 0:11:14.580000
 from tricking users into performing
 actions that they did not intend.

0:11:14.580000 --> 0:11:18.340000
 And then of course you have web
 application firewall rules.

0:11:18.340000 --> 0:11:22.180000
 So web application firewalls are security
 appliances or services that

0:11:22.180000 --> 0:11:26.760000
 filter incoming HTTP requests
 to a web application.

0:11:26.760000 --> 0:11:30.300000
 And they use predefined rules and heuristics
 to detect and block malicious

0:11:30.300000 --> 0:11:35.040000
 traffic. So you can see that there's
 many techniques that are used when

0:11:35.040000 --> 0:11:39.480000
 it comes down to input filtering specifically
 in the context of securing

0:11:39.480000 --> 0:11:45.320000
 a web application you know from all vulnerabilities
 or attacks that relate

0:11:45.320000 --> 0:11:47.700000
 to you know input.

0:11:47.700000 --> 0:11:53.520000
 And what we'll be exploring within
 this section is going to be pretty

0:11:53.520000 --> 0:11:59.620000
 much sanitization or the process of
 performing some form of validation.

0:11:59.620000 --> 0:12:06.100000
 Now as we proceed one technique that
 you might run across and this is

0:12:06.100000 --> 0:12:11.260000
 not really a technique but what I would
 call a sub technique is regular

0:12:11.260000 --> 0:12:12.720000
 expression filtering.

0:12:12.720000 --> 0:12:17.400000
 Alright so regular expressions or rejects
 I'm sure you have some experience

0:12:17.400000 --> 0:12:22.440000
 with them can be used to filter and validate
 data against complex patterns.

0:12:22.440000 --> 0:12:25.780000
 However improper rejects usage can
 introduce security vulnerabilities

0:12:25.780000 --> 0:12:31.060000
 so careful crafting and testing of
 rejects patterns are necessary.

0:12:31.060000 --> 0:12:35.760000
 So the reason rejects is being used
 quite a lot or has been used quite

0:12:35.760000 --> 0:12:46.140000
 a lot is because any input is sanitized
 that you know meets a particular

0:12:46.140000 --> 0:12:47.180000
 set of criteria.

0:12:47.180000 --> 0:12:52.300000
 Now the issue with rejects input filtering
 is obviously if you don't write

0:12:52.300000 --> 0:13:00.060000
 a proper rejects pattern or a rejects
 filter if you will then you are

0:13:00.060000 --> 0:13:04.680000
 more susceptible or you are
 still susceptible to attack.

0:13:04.680000 --> 0:13:08.760000
 So from the attacker's perspective
 what you're really trying to do is

0:13:08.760000 --> 0:13:14.600000
 identify firstly you are we dealing with
 server side filtering or sanitization

0:13:14.600000 --> 0:13:19.260000
 or are we dealing with server side filtering
 and sanitization and a lot

0:13:19.260000 --> 0:13:23.860000
 of that can be given away by the type
 of vulnerability you're trying to

0:13:23.860000 --> 0:13:25.060000
 identify or exploit.

0:13:25.060000 --> 0:13:31.420000
 So in the case of SQL injection vulnerabilities
 it is most likely going

0:13:31.420000 --> 0:13:34.880000
 to be the case that you're dealing
 with server side filtering.

0:13:34.880000 --> 0:13:41.080000
 In the case of cross side scripting
 attacks or vulnerabilities you are

0:13:41.080000 --> 0:13:45.380000
 split in the middle so 50-50 again
 depending on other web application

0:13:45.380000 --> 0:13:50.380000
 was developed so you either will have
 client side filtering or server

0:13:50.380000 --> 0:13:54.140000
 side filtering but usually
 it's a combination of both.

0:13:54.140000 --> 0:13:57.380000
 Now the reason for this is
 very simple to understand.

0:13:57.380000 --> 0:14:03.280000
 Number one remember that if you are
 utilizing or your web application

0:14:03.280000 --> 0:14:09.000000
 is utilizing client side filtering via
 JavaScript through the use of regular

0:14:09.000000 --> 0:14:12.900000
 expression to filter for let's say
 script tags or something like that

0:14:12.900000 --> 0:14:17.360000
 the problem with that and the problem
 with using that form of filtering

0:14:17.360000 --> 0:14:21.320000
 alone is that anyone has
 access to that resource.

0:14:21.320000 --> 0:14:25.900000
 So when I load the HTML page that JavaScript
 code is also loaded on my

0:14:25.900000 --> 0:14:29.880000
 browser. So if I just check the source
 code I'll be able to reverse engineer

0:14:29.880000 --> 0:14:34.800000
 your rejects filtering to get an understanding
 as to where the loopholes

0:14:34.800000 --> 0:14:39.700000
 lie and based on the actual filter
 itself I can bypass it.

0:14:39.700000 --> 0:14:44.260000
 So that's why client side input filtering
 is no longer used anymore or

0:14:44.260000 --> 0:14:48.000000
 if it is used it is combined
 with server side filtering.

0:14:48.000000 --> 0:14:52.080000
 So what you'll typically see today even
 in the case of cross side scripting

0:14:52.080000 --> 0:14:58.860000
 attacks or is implemented on the server
 side similar to what we did with

0:14:58.860000 --> 0:15:03.980000
 or the example we took a look at when
 we are performing HTML encoding.

0:15:03.980000 --> 0:15:07.160000
 So with that being said that brings
 us to the end of the introduction

0:15:07.160000 --> 0:15:09.300000
 to input filtering video.

0:15:09.300000 --> 0:15:12.660000
 Now that we have gotten that out of
 the way we can turn our attention

0:15:12.660000 --> 0:15:17.980000
 to client side filtering and we'll
 be utilizing a live lab to do that

0:15:17.980000 --> 0:15:22.080000
 and this will sort of set the stage for
 the final video within this section

0:15:22.080000 --> 0:15:27.440000
 where we'll be taking a look at how
 to bypass an actual filter or server

0:15:27.440000 --> 0:15:30.760000
 side filtering in a real
 world web application.

0:15:30.760000 --> 0:15:33.820000
 So with that being said that is going
 to be it for this video and I'll

0:15:33.820000 --> 0:15:35.820000
 be seeing you in the next video.