WEBVTT

0:00:11.480000 --> 0:00:15.600000
 And the other one of course is input
 validation and sanitization.

0:00:15.600000 --> 0:00:18.460000
 It's something that you need to be aware
 of when performing manual testing

0:00:18.460000 --> 0:00:22.180000
 and this involves reviewing the application's
 code or what is publicly

0:00:22.180000 --> 0:00:27.580000
 accessible and checking if proper input
 validation and sanitization techniques

0:00:27.580000 --> 0:00:28.740000
 are implemented.

0:00:28.740000 --> 0:00:32.860000
 So what you want to do is look for instances
 where user input is directly

0:00:32.860000 --> 0:00:37.260000
 concatenated into SQL queries without
 proper sanitization or prepared

0:00:37.260000 --> 0:00:41.620000
 statements and I'll show you an example
 of what good user input validation

0:00:41.620000 --> 0:00:44.200000
 looks like in the next video.

0:00:44.200000 --> 0:00:48.020000
 As for automated testing, this
 is fairly simple to understand.

0:00:48.020000 --> 0:00:53.460000
 You typically want to use tools like OASP
-ZAP, Burbsweet or SQL-Map, right?

0:00:53.460000 --> 0:00:57.800000
 Because in the case of OASP-ZAP and Burbsweet,
 because of their web proxies,

0:00:57.800000 --> 0:01:01.820000
 the process is semi-manual or semi
-automated depending on how you look

0:01:01.820000 --> 0:01:08.480000
 at it. You typically start using SQL
-Map when or after typically you have

0:01:08.480000 --> 0:01:12.460000
 identified that yes, an SQL injection
 vulnerability exists.

0:01:12.460000 --> 0:01:16.760000
 However, you may want to verify it a
 little bit more through the use of

0:01:16.760000 --> 0:01:20.240000
 additional payloads, but for some reason
 you just can't find a payload

0:01:20.240000 --> 0:01:24.500000
 that's working. SQL-Map is your
 friend at that point in time.

0:01:24.500000 --> 0:01:28.800000
 Now, that's not to say that SQL-Map cannot
 be used to identify or to tell

0:01:28.800000 --> 0:01:33.300000
 you yes, an SQL injection vulnerability
 exists, but what bounty hunters

0:01:33.300000 --> 0:01:37.340000
 and web app investors typically know
 that, okay, something's going on

0:01:37.340000 --> 0:01:42.140000
 here. I just need a tool like SQL-Map
 to generate a really cool payload

0:01:42.140000 --> 0:01:47.800000
 for me and test it and provide me with
 proof of verification that yes,

0:01:47.800000 --> 0:01:51.860000
 indeed, there is an SQL injection vulnerability
 that affects this particular

0:01:51.860000 --> 0:01:54.380000
 application input.

0:01:54.380000 --> 0:01:59.480000
 So when it comes down to the actual
 manual testing process, as I said,

0:01:59.480000 --> 0:02:03.420000
 you typically want to start off
 by using special characters.

0:02:03.420000 --> 0:02:07.000000
 So testing an application input for
 SQL injection will typically involve

0:02:07.000000 --> 0:02:10.780000
 trying to inject string terminators
 or string delimiters like a single

0:02:10.780000 --> 0:02:12.160000
 or double quote.

0:02:12.160000 --> 0:02:16.260000
 SQL commands like select
 union and other ones.

0:02:16.260000 --> 0:02:19.380000
 SQL comments, this is very,
 very, very important.

0:02:19.380000 --> 0:02:24.380000
 So you typically want to utilize the
 pound symbol or the double hyphen

0:02:24.380000 --> 0:02:25.360000
 to denote a comment.

0:02:25.360000 --> 0:02:29.880000
 This is typically after your SQL query
 because if there is another SQL

0:02:29.880000 --> 0:02:34.380000
 query after the injectable parameter,
 you need to ensure that that SQL

0:02:34.380000 --> 0:02:36.120000
 query is not executed as well.

0:02:36.120000 --> 0:02:38.080000
 And again, you may be
 a little bit confused.

0:02:38.080000 --> 0:02:41.940000
 Don't worry. I'll actually put all
 of this into context and everything

0:02:41.940000 --> 0:02:47.480000
 that we learned in the SQL fundamentals
 video into practice or into context.

0:02:47.480000 --> 0:02:51.500000
 Another important factor to consider
 when performing manual testing is

0:02:51.500000 --> 0:02:56.240000
 whether the injectable parameter or input
 is string based or integer based.

0:02:56.240000 --> 0:03:00.860000
 And one final thing to keep in mind or
 to take into consideration is that

0:03:00.860000 --> 0:03:03.880000
 you should always test one
 injection at a time.

0:03:03.880000 --> 0:03:08.180000
 Otherwise, you'll not be able to identify
 which injection injection vector

0:03:08.180000 --> 0:03:09.840000
 or payload is successful.

0:03:09.840000 --> 0:03:11.140000
 So again, don't rush.

0:03:11.140000 --> 0:03:13.720000
 Don't rush the process.

0:03:13.720000 --> 0:03:16.800000
 Be very meticulous with what you're
 doing and try and understand what's

0:03:16.800000 --> 0:03:19.020000
 going on and what payload you're using.

0:03:19.020000 --> 0:03:22.240000
 That's really what I'm going to be trying
 to do in this section as well

0:03:22.240000 --> 0:03:25.780000
 as the next section is to show you that
 you don't need to go crazy with

0:03:25.780000 --> 0:03:29.880000
 payloads. You just need to understand
 how the web application is working.

0:03:29.880000 --> 0:03:36.780000
 And you then use primarily error or blind
 based injection to try and learn

0:03:36.780000 --> 0:03:40.140000
 more about the database and more about
 the web application, how the query

0:03:40.140000 --> 0:03:44.240000
 works. Only after that, can you start
 trying different payloads to see

0:03:44.240000 --> 0:03:49.280000
 what the extent or the severity of the
 vulnerability from the perspective

0:03:49.280000 --> 0:03:56.120000
 of an attacker. So I've talked about
 integer and string based injection.

0:03:56.120000 --> 0:03:58.060000
 Now what do I mean when I say this?

0:03:58.060000 --> 0:04:00.300000
 This is something that is
 really not understood.

0:04:00.300000 --> 0:04:04.240000
 And if you understand this, I can almost
 guarantee that you'll be able

0:04:04.240000 --> 0:04:07.320000
 to look at any payload that's publicly
 available and you'll be able to

0:04:07.320000 --> 0:04:10.960000
 say, okay, that will work for
 integer based injection.

0:04:10.960000 --> 0:04:13.360000
 And this will work for
 string based injection.

0:04:13.360000 --> 0:04:14.500000
 It's really very simple.

0:04:14.500000 --> 0:04:19.300000
 So in the case of integer based parameter
 injection, in certain cases,

0:04:19.300000 --> 0:04:24.440000
 SQL queries will treat the injectable
 parameter as an integer depending

0:04:24.440000 --> 0:04:26.920000
 on the data on the actual data type.

0:04:26.920000 --> 0:04:30.980000
 So let's say you're browsing a site
 and you realize that within the URL,

0:04:30.980000 --> 0:04:35.920000
 there's a dynamic ID, right, as
 we already explored previously.

0:04:35.920000 --> 0:04:38.620000
 And this value could be
 set to whatever, right?

0:04:38.620000 --> 0:04:40.840000
 It could be set to one, regardless.

0:04:40.840000 --> 0:04:44.500000
 The point I'm trying to make is that
 this is the injectable parameter.

0:04:44.500000 --> 0:04:50.340000
 This is where you can inject your SQL
 code or your SQL query or payload.

0:04:50.340000 --> 0:04:54.080000
 In the backend, the query
 looks something like this.

0:04:54.080000 --> 0:04:57.560000
 Select all from users
 where the ID equals.

0:04:57.560000 --> 0:05:01.340000
 Now the key thing I want you to notice
 because this is numeric, because

0:05:01.340000 --> 0:05:06.340000
 the ID is numeric in value or in terms
 of its data type, it's an integer

0:05:06.340000 --> 0:05:08.960000
 and can only be an integer.

0:05:08.960000 --> 0:05:14.380000
 The SQL query also passes along or
 infers that same sentiment in that

0:05:14.380000 --> 0:05:19.980000
 instead of concatenating this injectable
 parameter or the value of the

0:05:19.980000 --> 0:05:24.040000
 ID in single or double quotes, it'll
 just pass it along, right?

0:05:24.040000 --> 0:05:28.660000
 Or you just need to, once the value
 is specified, this is passed along

0:05:28.660000 --> 0:05:32.940000
 by the web application and that is substituted
 with, you know, where you

0:05:32.940000 --> 0:05:34.560000
 have fuzz here, right?

0:05:34.560000 --> 0:05:41.100000
 So it would be select all from users where
 the ID equals one, not concatenated

0:05:41.100000 --> 0:05:47.560000
 or anything. So in such case, in this
 particular case, it is recommended

0:05:47.560000 --> 0:05:52.960000
 to utilize SQL queries or payloads
 that utilize logical operators.

0:05:52.960000 --> 0:05:57.420000
 And once that, in most cases, you really
 don't need to utilize a string

0:05:57.420000 --> 0:06:03.100000
 delimiter like a single quote before
 your actual SQL query or your SQL

0:06:03.100000 --> 0:06:06.920000
 payload. So you'll actually see that
 when you're exploring some public

0:06:06.920000 --> 0:06:09.960000
 payloads that are available or you're
 taking a look at some cheat sheets,

0:06:09.960000 --> 0:06:14.500000
 which I'll actually show you, you'll
 typically see that you have payloads

0:06:14.500000 --> 0:06:22.040000
 that look like this, where there is no
 inclusion of a single quote before

0:06:22.040000 --> 0:06:23.960000
 the actual payload.

0:06:23.960000 --> 0:06:27.880000
 And then you will see payloads like
 this, or you'll see payloads that

0:06:27.880000 --> 0:06:29.660000
 have that single quote.

0:06:29.660000 --> 0:06:34.180000
 And that when you see the single quote,
 just know that those are string

0:06:34.180000 --> 0:06:36.420000
 based injection payloads.

0:06:36.420000 --> 0:06:41.140000
 All right. So these are integer examples
 of integer based injection payloads,

0:06:41.140000 --> 0:06:45.500000
 where you can use and one, which, you
 know, will, you know, pretty much

0:06:45.500000 --> 0:06:49.400000
 tell you if there is an injection
 vulnerability and zero is false.

0:06:49.400000 --> 0:06:50.520000
 So you can run different checks.

0:06:50.520000 --> 0:06:52.460000
 You can also run mathematical operations.


0:06:52.460000 --> 0:06:58.180000
 So one times 56, for example, if it
 is vulnerable, it will return 56.

0:06:58.180000 --> 0:07:01.560000
 If it returns one, it means
 that is not vulnerable.

0:07:01.560000 --> 0:07:04.380000
 In the case of string based injection,
 this is something that you may

0:07:04.380000 --> 0:07:08.240000
 be a little bit more familiar with,
 given that you typically see this

0:07:08.240000 --> 0:07:09.940000
 with modern web applications.

0:07:09.940000 --> 0:07:14.240000
 So with string based parameter injection,
 in most cases, the SQL queries

0:07:14.240000 --> 0:07:16.460000
 will treat the injectable
 parameter string.

0:07:16.460000 --> 0:07:22.000000
 So again, going back to the same example,
 we have site.com user.php id

0:07:22.000000 --> 0:07:23.520000
 equals Alexis. All right.

0:07:23.520000 --> 0:07:26.300000
 So now the key thing to
 note is the data type.

0:07:26.300000 --> 0:07:31.080000
 So in the previous web application example,
 the data type was an integer.

0:07:31.080000 --> 0:07:32.660000
 You can obviously tell that.

0:07:32.660000 --> 0:07:37.380000
 In this case, it probably is a string
 because it is a string of characters.

0:07:37.380000 --> 0:07:39.740000
 So in this case, it's
 referring to a name.

0:07:39.740000 --> 0:07:44.160000
 It could be referring to a blog post,
 regardless of what the parameter

0:07:44.160000 --> 0:07:46.400000
 is, this is treated as a string.

0:07:46.400000 --> 0:07:50.740000
 Now, what that means is that the SQL
 queries is also most likely going

0:07:50.740000 --> 0:07:53.480000
 to be designed to treat it as a string.

0:07:53.480000 --> 0:07:54.620000
 So we have the query here.

0:07:54.620000 --> 0:07:59.560000
 So select all from users where the
 name equals fuzz and the SQL query

0:07:59.560000 --> 0:08:04.640000
 will have that encapsulated or this
 value encapsulated when it's passed

0:08:04.640000 --> 0:08:06.660000
 by the web application.

0:08:06.660000 --> 0:08:09.260000
 It'll be encapsulated by single quotes.

0:08:09.260000 --> 0:08:14.060000
 Now the reason why in when you talk
 about string based injection, the

0:08:14.060000 --> 0:08:19.240000
 payloads have a single quote before
 the actual payload of the SQL query

0:08:19.240000 --> 0:08:24.920000
 is to act as a string delimiter where
 you're essentially terminating this

0:08:24.920000 --> 0:08:31.420000
 particular, this particular parameter
 and you're starting a new SQL query

0:08:31.420000 --> 0:08:37.320000
 and then you end it typically either
 with the the terminator, the SQL

0:08:37.320000 --> 0:08:41.620000
 terminator, which is a semi colon or
 you can end it with a comment to

0:08:41.620000 --> 0:08:46.340000
 infer or to say that, hey, after anything
 after this, I don't want executed.

0:08:46.340000 --> 0:08:50.840000
 So in these cases, it's recommended
 to utilize special SQL characters

0:08:50.840000 --> 0:08:54.840000
 or delimiters like the single quote
 to delimit string literal.

0:08:54.840000 --> 0:08:59.500000
 So, you know, single quote, you can
 also use double quote or rather you

0:08:59.500000 --> 0:09:04.160000
 can use a single single quote, a double
 single quote, a single double

0:09:04.160000 --> 0:09:06.420000
 quote and a double double quote.

0:09:06.420000 --> 0:09:09.200000
 So if that may be a bit confusing, but
 you know, there's a single quote

0:09:09.200000 --> 0:09:12.560000
 and a double quote, just
 variations of both.

0:09:12.560000 --> 0:09:17.380000
 Now the single quote is really important,
 especially when you're talking

0:09:17.380000 --> 0:09:19.240000
 about string based injection.

0:09:19.240000 --> 0:09:20.500000
 Why is it important?

0:09:20.500000 --> 0:09:23.440000
 Right? This is typically known
 as the single quote exploit.

0:09:23.440000 --> 0:09:28.420000
 So SQL injection vulnerabilities often
 arise when user supplied input

0:09:28.420000 --> 0:09:33.020000
 is not properly validated, sanitized
 or handled within the application

0:09:33.020000 --> 0:09:37.880000
 code. One common technique used in
 SQL injection attacks or in testing

0:09:37.880000 --> 0:09:42.080000
 is the process of exploiting
 the single quote character.

0:09:42.080000 --> 0:09:46.440000
 In the structured query language or
 in SQL, the single quote is used to

0:09:46.440000 --> 0:09:48.420000
 delimit string literals.

0:09:48.420000 --> 0:09:49.280000
 What does this mean?

0:09:49.280000 --> 0:09:53.460000
 It means when a user input is directly
 incorporated into an SQL query

0:09:53.460000 --> 0:09:57.760000
 without proper handling, an attacker
 can inject a single quote character

0:09:57.760000 --> 0:10:02.740000
 as part of the input, which can disrupt
 the intended query structure and

0:10:02.740000 --> 0:10:08.080000
 allow for the injection of malicious
 SQL code after the single quote.

0:10:08.080000 --> 0:10:11.980000
 So you'll actually see this in practice,
 but this is an example of what

0:10:11.980000 --> 0:10:16.060000
 it looks like. So for example, consider
 a login form where the username

0:10:16.060000 --> 0:10:20.320000
 and password inputs are concatenated
 into an SQL query without proper

0:10:20.320000 --> 0:10:25.600000
 validation. So it's treating it as a
 string regardless of where the value

0:10:25.600000 --> 0:10:29.460000
 is coming from. In this case, it's
 coming from the username field and

0:10:29.460000 --> 0:10:30.680000
 the password field.

0:10:30.680000 --> 0:10:32.620000
 This is what the query looks like.

0:10:32.620000 --> 0:10:36.380000
 So select all from users where the username
 equals two and then, you know,

0:10:36.380000 --> 0:10:40.680000
 the username is put in here and password
 equals two and a password is

0:10:40.680000 --> 0:10:42.120000
 substituted in here.

0:10:42.120000 --> 0:10:46.140000
 Now if the application does not handle
 the single quote character in the

0:10:46.140000 --> 0:10:50.980000
 input correctly and allows for that
 injection, an attacker can inject

0:10:50.980000 --> 0:10:56.000000
 a single quote to terminate the string
 literal into, you know, for both

0:10:56.000000 --> 0:11:01.200000
 the username and password parameters
 and add their own SQL code after

0:11:01.200000 --> 0:11:06.260000
 that. So here's an example of an attack
 payload we can use where we start

0:11:06.260000 --> 0:11:10.280000
 off by putting in the single quote
 that will essentially terminate the

0:11:10.280000 --> 0:11:12.280000
 string literal for either
 username or password.

0:11:12.280000 --> 0:11:16.340000
 And then we use a logical operator
 like or and we provide an operation

0:11:16.340000 --> 0:11:18.200000
 that's always going to be true.

0:11:18.200000 --> 0:11:23.400000
 And then we can, we need to always end
 our own query with either the SQL

0:11:23.400000 --> 0:11:28.460000
 delimiter or the comment, the comments
 characters here or the comment

0:11:28.460000 --> 0:11:33.760000
 symbols, which can either be a double
 hyphen or the hash or pound symbol.

0:11:33.760000 --> 0:11:39.280000
 So the modified query would then become
 the following after the injection.

0:11:39.280000 --> 0:11:43.620000
 So it would be select all from users
 where the username equals two, you

0:11:43.620000 --> 0:11:48.900000
 have the, you know, the actual string literal
 there, but that's been terminated.

0:11:48.900000 --> 0:11:54.540000
 And what comes after is our own logical
 operation or our own SQL query,

0:11:54.540000 --> 0:11:58.680000
 which is a logical operation where
 we're saying you can execute this.

0:11:58.680000 --> 0:12:02.900000
 However, if this is not successful,
 you can also execute this.

0:12:02.900000 --> 0:12:05.020000
 And in this case, this is
 always going to be true.

0:12:05.020000 --> 0:12:09.920000
 And because it's always going to be true,
 what will happen in this particular

0:12:09.920000 --> 0:12:14.440000
 case, it will actually dump or will allow
 us to bypass the authentication

0:12:14.440000 --> 0:12:19.080000
 because the result of this entire
 query is going to be true.

0:12:19.080000 --> 0:12:22.980000
 And that's what the web application
 is looking for, typically speaking.

0:12:22.980000 --> 0:12:26.540000
 Now certain web applications will look
 for a bit more confirmation, but

0:12:26.540000 --> 0:12:31.260000
 in this, in the case of this query,
 what happens is the web application

0:12:31.260000 --> 0:12:33.300000
 receives your input, right?

0:12:33.300000 --> 0:12:34.740000
 So username and password.

0:12:34.740000 --> 0:12:38.740000
 And then it knows that if it wants to
 verify this information, it needs

0:12:38.740000 --> 0:12:40.420000
 to interact with the database.

0:12:40.420000 --> 0:12:45.040000
 So in order to interact with the database,
 it utilizes SQL or the structured

0:12:45.040000 --> 0:12:48.880000
 query language. In order to do that,
 it needs to send the database an

0:12:48.880000 --> 0:12:54.000000
 SQL query. In this case, all the web
 application is asking for is, can

0:12:54.000000 --> 0:12:59.160000
 you tell me if this username exists,
 and if so, is there password correct

0:12:59.160000 --> 0:13:03.600000
 based on what you have in the
 users or the accounts table?

0:13:03.600000 --> 0:13:08.320000
 So in this particular case,
 the table is called users.

0:13:08.320000 --> 0:13:09.520000
 So the query is very simple.

0:13:09.520000 --> 0:13:12.980000
 So select all. So we're telling the web
 application is telling the database.

0:13:12.980000 --> 0:13:18.400000
 So for all the records within the users
 table, can you tell me or can

0:13:18.400000 --> 0:13:24.440000
 you confirm whether this username exists
 and that's a logical operator.

0:13:24.440000 --> 0:13:28.260000
 Can you confirm that this password
 exists for that particular record?

0:13:28.260000 --> 0:13:34.540000
 Now, what we're doing here is we are
 utilizing the single quote right

0:13:34.540000 --> 0:13:37.160000
 over here. We're essentially using it.

0:13:37.160000 --> 0:13:38.240000
 So we're delimiting it.

0:13:38.240000 --> 0:13:42.420000
 If we go back to the description, you
 were terminating the string literal.

0:13:42.420000 --> 0:13:48.280000
 All right. And we're saying, okay, you,
 you can run this first one, but

0:13:48.280000 --> 0:13:51.320000
 that doesn't matter because you
 also have a second option here.

0:13:51.320000 --> 0:13:55.760000
 So it's remember, this is an we're using
 or here instead of and or means

0:13:55.760000 --> 0:13:58.260000
 that you can execute either one.

0:13:58.260000 --> 0:14:01.980000
 And all that the web application is
 looking for is, you know, true or

0:14:01.980000 --> 0:14:06.880000
 false. In this particular case, you
 know, we're terminating the string

0:14:06.880000 --> 0:14:11.560000
 literal and we're saying, okay, can you perform
 this operation as an alternative?

0:14:11.560000 --> 0:14:14.400000
 In this case, the operation
 is always going to be true.

0:14:14.400000 --> 0:14:19.760000
 And we use a the SQL delimiter here
 to terminate the SQL query and say

0:14:19.760000 --> 0:14:21.080000
 nothing after this.

0:14:21.080000 --> 0:14:23.380000
 Now you don't need to use the semicolon.

0:14:23.380000 --> 0:14:28.000000
 You can also use a comment, the comment
 symbol, which is power the hash

0:14:28.000000 --> 0:14:32.500000
 or pound symbol, or you can use
 the double, the double hyphen.

0:14:32.500000 --> 0:14:37.980000
 And what that means is anything after
 this right over here is not going

0:14:37.980000 --> 0:14:42.700000
 to be executed. So in essence, the SQL
 query is executed by the database

0:14:42.700000 --> 0:14:44.860000
 and it responds with true.

0:14:44.860000 --> 0:14:47.340000
 The web application was just waiting
 for that confirmation.

0:14:47.340000 --> 0:14:49.700000
 And if it's true, it just logs you in.

0:14:49.700000 --> 0:14:54.860000
 So in this example, the single quote
 is injected before the payload, which

0:14:54.860000 --> 0:14:57.480000
 is single quote, or one equals one.

0:14:57.480000 --> 0:15:01.240000
 The purpose of the injected single quote
 is to close the string literal

0:15:01.240000 --> 0:15:04.840000
 that encompasses the
 username input field.

0:15:04.840000 --> 0:15:11.820000
 Then the attackers injected SQL code,
 which is or one one equals one causes

0:15:11.820000 --> 0:15:16.840000
 the condition one equals one to evaluate
 to true, effectively bypassing

0:15:16.840000 --> 0:15:18.420000
 the authentication mechanism.

0:15:18.420000 --> 0:15:19.700000
 This is very common.

0:15:19.700000 --> 0:15:23.360000
 All right. So I know we're covering
 quite a lot, but we'll put all of

0:15:23.360000 --> 0:15:26.600000
 this into context in the next video
 and we actually going through it in

0:15:26.600000 --> 0:15:31.000000
 a lab. Now, the final thing that's
 very important when performing SQL

0:15:31.000000 --> 0:15:35.240000
 injection vulnerability identification
 is database fingerprinting.

0:15:35.240000 --> 0:15:40.000000
 All right. So every DBMS or database
 management system, every relational

0:15:40.000000 --> 0:15:45.300000
 database management system will respond
 to incorrect or erroneous SQL

0:15:45.300000 --> 0:15:47.320000
 queries with different error messages.

0:15:47.320000 --> 0:15:51.780000
 And when you're performing identification
 or error based SQL injection,

0:15:51.780000 --> 0:15:54.520000
 this is typically what you'll
 be looking for to begin with.

0:15:54.520000 --> 0:15:59.140000
 You're trying to verify whether an
 injection vulnerability exists.

0:15:59.140000 --> 0:16:02.720000
 And when you use something like a single
 quote alone, because that will

0:16:02.720000 --> 0:16:08.060000
 interfere with the SQL query, if it is,
 if one is indeed tied to the application

0:16:08.060000 --> 0:16:11.200000
 input you're testing,
 different databases.

0:16:11.200000 --> 0:16:15.240000
 Or in this case, relational database
 management systems will respond in

0:16:15.240000 --> 0:16:16.280000
 their own unique way.

0:16:16.280000 --> 0:16:17.760000
 Now, why is this important?

0:16:17.760000 --> 0:16:22.220000
 This is important because it'll tell
 you firstly what database is running

0:16:22.220000 --> 0:16:24.720000
 or what database is being used.

0:16:24.720000 --> 0:16:28.340000
 Right. So in this case, a typical error
 from Microsoft SQL database server

0:16:28.340000 --> 0:16:32.500000
 will look like this incorrect syntax
 near and then the query snippet will

0:16:32.500000 --> 0:16:35.620000
 be added as a suffix to that.

0:16:35.620000 --> 0:16:39.100000
 Whereas a typical MySQL error
 will look something like this.

0:16:39.100000 --> 0:16:44.060000
 And the reason I'm saying this is because
 in certain cases, the SQL queries

0:16:44.060000 --> 0:16:46.640000
 or payloads you can use will be.

0:16:46.640000 --> 0:16:49.780000
 Will be dependent on the
 database that is running.

0:16:49.780000 --> 0:16:53.800000
 So there's no huge changes with regards
 to the actual SQL syntax, but

0:16:53.800000 --> 0:16:57.660000
 other features regarding the
 database will be unique.

0:16:57.660000 --> 0:17:00.840000
 So this is very important
 information to identify.

0:17:00.840000 --> 0:17:04.680000
 So, you know, typical MySQL error
 will look something like this.

0:17:04.680000 --> 0:17:07.160000
 You'll typically see the following
 text to begin with.

0:17:07.160000 --> 0:17:10.380000
 So you have an error in your SQL syntax.

0:17:10.380000 --> 0:17:14.380000
 Can you check the manual that corresponds
 to your MySQL server version

0:17:14.380000 --> 0:17:18.740000
 for the right syntax to use and then
 the query snippet will be added as

0:17:18.740000 --> 0:17:22.620000
 a suffix after that telling
 you where you went wrong.

0:17:22.620000 --> 0:17:27.280000
 And I've listed within these slides
 some common SQL injection payloads.

0:17:27.280000 --> 0:17:30.880000
 And, you know, you can obviously tell
 that these are primarily string

0:17:30.880000 --> 0:17:35.160000
 based SQL injection payloads.

0:17:35.160000 --> 0:17:37.320000
 You also have some integer based ones.

0:17:37.320000 --> 0:17:41.000000
 But again, it's all about identifying
 whether you're dealing with whether

0:17:41.000000 --> 0:17:44.640000
 the parameter is being treated
 as a string or an integer.

0:17:44.640000 --> 0:17:49.020000
 And this is something that I actually
 showed you in the SQL fundamentals

0:17:49.020000 --> 0:17:52.360000
 video where we were writing
 our own SQL queries.

0:17:52.360000 --> 0:17:57.140000
 You saw that when I was running select
 all from WordPress users where

0:17:57.140000 --> 0:18:01.800000
 ID equals to one, I was
 putting one alone.

0:18:01.800000 --> 0:18:03.860000
 So that means that would
 be treated as an integer.

0:18:03.860000 --> 0:18:08.300000
 Or I was also encapsulating
 it in single quotes.

0:18:08.300000 --> 0:18:10.400000
 And that means it's treated as a string.

0:18:10.400000 --> 0:18:17.680000
 So always be cognizant of how the actual
 SQL query used by the web application

0:18:17.680000 --> 0:18:21.980000
 to interact with the database is constructed
 and how the injectable parameters

0:18:21.980000 --> 0:18:26.800000
 are treated or are handled
 within that query.

0:18:26.800000 --> 0:18:31.260000
 And over here, I've also listed some
 database specific SQLite payloads

0:18:31.260000 --> 0:18:36.420000
 for MySQL, Microsoft SQL database
 server or a postgreSQL SQLite.

0:18:36.420000 --> 0:18:38.500000
 What will typically work?

0:18:38.500000 --> 0:18:41.700000
 And I would highly recommend if you're
 doing, you know, for example, the

0:18:41.700000 --> 0:18:45.360000
 using this particular payload where you
 are able to bypass authentication

0:18:45.360000 --> 0:18:50.240000
 or set the response of the query to true.


0:18:50.240000 --> 0:18:55.700000
 Regardless of what it does, the what
 works at the end is typically the

0:18:55.700000 --> 0:19:01.260000
 pound or the hash symbol here, which
 denotes a comment for access for

0:19:01.260000 --> 0:19:01.880000
 the access database.

0:19:01.880000 --> 0:19:05.360000
 You is recommended to
 use null characters.

0:19:05.360000 --> 0:19:10.020000
 Now to end this video, because I know
 I've been going for quite a while,

0:19:10.020000 --> 0:19:16.120000
 one of the tools that I like utilizing
 that ties back to the OASP top

0:19:16.120000 --> 0:19:19.300000
 10, but really the OASP security testing
 guide, which I've highlighted

0:19:19.300000 --> 0:19:23.920000
 in other cases. The courses is the
 OASP testing checklist, right?

0:19:23.920000 --> 0:19:27.680000
 The testing checklist is a checklist that
 is very useful for web application

0:19:27.680000 --> 0:19:33.280000
 penetration testers, developers, people
 who work in web application security.

0:19:33.280000 --> 0:19:36.600000
 Anyone who is doing any sort of security
 assessment on a web application

0:19:36.600000 --> 0:19:38.500000
 should use this spreadsheet.

0:19:38.500000 --> 0:19:41.360000
 And I've listed the GitHub
 repo to that spreadsheet.

0:19:41.360000 --> 0:19:42.300000
 It's completely free.

0:19:42.300000 --> 0:19:44.460000
 It has no viruses, no macros.

0:19:44.460000 --> 0:19:45.460000
 I've checked it myself.

0:19:45.460000 --> 0:19:49.320000
 It's official. It provides you or it sorts
 out vulnerabilities into different

0:19:49.320000 --> 0:19:51.840000
 categories based on their type.

0:19:51.840000 --> 0:19:55.780000
 And this is not really tied to the OASP
 top 10, because you can see that

0:19:55.780000 --> 0:19:59.700000
 this is under data validation testing,
 which would make sense.

0:19:59.700000 --> 0:20:05.640000
 But under this, we have testing for
 SQL injection, where really all that

0:20:05.640000 --> 0:20:09.080000
 you're required to do is identify
 SQL injection points.

0:20:09.080000 --> 0:20:13.560000
 And then after you've identified SQL injection
 vulnerability, you're supposed

0:20:13.560000 --> 0:20:16.900000
 to assess the severity of the injection
 and the level of access that can

0:20:16.900000 --> 0:20:18.320000
 be achieved through it.

0:20:18.320000 --> 0:20:21.860000
 And the tools to use are either BERB
 Suite or ZAP, SQL map and no SQL

0:20:21.860000 --> 0:20:25.440000
 map for no SQL databases,
 which I'll also highlight.

0:20:25.440000 --> 0:20:28.780000
 I always use this as a reference when
 I'm performing my tests, because

0:20:28.780000 --> 0:20:33.040000
 it allows me to perform
 comprehensive testing.

0:20:33.040000 --> 0:20:35.180000
 And it really is very useful.

0:20:35.180000 --> 0:20:39.540000
 And I've also added some SQL
 injection resources here.

0:20:39.540000 --> 0:20:43.160000
 So this is a full, the following is a list
 of useful open source repositories,

0:20:43.160000 --> 0:20:47.500000
 tools and documentation that will provide
 you with information and payloads

0:20:47.500000 --> 0:20:51.740000
 that can be used for different types and subtypes
 of SQL injection vulnerabilities.

0:20:51.740000 --> 0:20:53.340000
 So I have some cheat sheets.

0:20:53.340000 --> 0:20:57.640000
 The first one is a GitHub repo with
 a huge collection of different types

0:20:57.640000 --> 0:20:59.620000
 of SQL injection payloads.

0:20:59.620000 --> 0:21:01.680000
 I definitely recommend that
 you take a look at that.

0:21:01.680000 --> 0:21:03.480000
 We'll be exploring it in the next video.

0:21:03.480000 --> 0:21:07.500000
 There's also one that was set up by BERB
 Suite or by PortSwiger, the parent

0:21:07.500000 --> 0:21:11.660000
 company of BERB Suite, that is not as
 comprehensive, but sort of explains

0:21:11.660000 --> 0:21:13.460000
 things really well.

0:21:13.460000 --> 0:21:16.960000
 And then you obviously have the OASP
 Web Security Testing Guide, where

0:21:16.960000 --> 0:21:20.720000
 you can take a look at that and
 specifically SQL injection.

0:21:20.720000 --> 0:21:24.700000
 And it'll provide you with a security
 testing guide or how you can go

0:21:24.700000 --> 0:21:27.800000
 about identifying and exploiting the
 vulnerabilities when performing an

0:21:27.800000 --> 0:21:32.080000
 assessment. It's sort of a best practice
 or a methodology to work behind.

0:21:32.080000 --> 0:21:36.340000
 In the case of this video, I've essentially
 broken it all down or it's

0:21:36.340000 --> 0:21:40.580000
 based heavily on the OASP Web
 Security Testing Guide.

0:21:40.580000 --> 0:21:43.200000
 I'm just going to put it into practice
 and show you what it looks like

0:21:43.200000 --> 0:21:45.800000
 within this entire section.

0:21:45.800000 --> 0:21:48.360000
 So that's quite a mouthful.

0:21:48.360000 --> 0:21:51.120000
 We've covered quite a lot, but I'm
 really happy that I've gone through

0:21:51.120000 --> 0:21:54.160000
 this before we actually
 did any exploitation.

0:21:54.160000 --> 0:21:57.960000
 So now that we have this out of the
 way, you'll be excited to know that

0:21:57.960000 --> 0:22:01.100000
 we're now getting started with
 the actual exploitation phase.

0:22:01.100000 --> 0:22:04.840000
 So if you take a look at one lab already,
 we'll be fundamentals of the

0:22:04.840000 --> 0:22:08.260000
 structured query language, but now
 in the next video, we'll be taking

0:22:08.260000 --> 0:22:12.980000
 a look at and it'll be fully practical
 how to manually find or identify

0:22:12.980000 --> 0:22:15.020000
 SQL injection vulnerabilities.

0:22:15.020000 --> 0:22:18.760000
 So with that being said, I'll be
 seeing you in the next video.