WEBVTT

0:00:09.340000 --> 0:00:13.400000
 So the response here is, yeah, it takes
 us to the blank page and nothing

0:00:13.400000 --> 0:00:19.800000
 else. If we go to, if we change the
 four here to maybe a three, it will

0:00:19.800000 --> 0:00:22.400000
 pretty much give us the same thing here.

0:00:22.400000 --> 0:00:27.280000
 However, if we change the version to
 five, and I know that the backend

0:00:27.280000 --> 0:00:33.560000
 DBMS is MySQL version five and I hit
 send, you can see it takes us to

0:00:33.560000 --> 0:00:37.880000
 the blog post one and that confirms
 that MySQL version five is running

0:00:37.880000 --> 0:00:43.040000
 as the backend relational database management
 system, which is absolutely

0:00:43.040000 --> 0:00:48.460000
 fantastic. So this should give you an
 idea as to how, you know, the actual

0:00:48.460000 --> 0:00:54.760000
 methodology behind identifying an exploiting
 Boolean based blinds or rather

0:00:54.760000 --> 0:00:57.880000
 blind Boolean based SQL injection
 vulnerabilities.

0:00:57.880000 --> 0:01:00.220000
 As you can see, it's a
 very manual process.

0:01:00.220000 --> 0:01:04.240000
 And this is an example of a payload
 that I typically run when roughly

0:01:04.240000 --> 0:01:07.440000
 speaking, I know that I'm dealing
 with a MySQL database.

0:01:07.440000 --> 0:01:11.580000
 Of course, there's other ways you know,
 you can go about extracting this

0:01:11.580000 --> 0:01:18.200000
 information. Now, from this point on,
 it is, it is extremely wise to test

0:01:18.200000 --> 0:01:23.320000
 this vulnerability or to test the efficacy
 of your findings or the actual

0:01:23.320000 --> 0:01:27.620000
 SQL injection vulnerability
 with a tool like SQL map.

0:01:27.620000 --> 0:01:31.220000
 And the only thing you're doing here
 is just verifying whether what you've

0:01:31.220000 --> 0:01:35.060000
 identified is true, which is always something
 important to do, especially

0:01:35.060000 --> 0:01:37.060000
 in the case of blind SQL injection.

0:01:37.060000 --> 0:01:42.760000
 So I'm going to save the initial request
 here on my desktop as just request.

0:01:42.760000 --> 0:01:45.060000
 OK, and I'll hit save.

0:01:45.060000 --> 0:01:48.060000
 And I'm not going to open up a terminal.

0:01:48.060000 --> 0:01:52.720000
 And I'll navigate to the desktop
 and I'll say CD desktop.

0:01:52.720000 --> 0:01:57.780000
 And we can say SQL map, the request is
 the request file of the file containing

0:01:57.780000 --> 0:02:00.620000
 the request. In this case,
 it's just called request.

0:02:00.620000 --> 0:02:04.840000
 And the parameter we want
 to inject is post.

0:02:04.840000 --> 0:02:06.400000
 If I can confirm that.

0:02:06.400000 --> 0:02:08.060000
 Yes, that is correct.

0:02:08.060000 --> 0:02:12.140000
 And we just hit enter and SQL
 map will do the rest for us.

0:02:12.140000 --> 0:02:13.740000
 So there we are.

0:02:13.740000 --> 0:02:18.780000
 It's going to begin the testing and
 let's see if it confirms whether we

0:02:18.780000 --> 0:02:21.500000
 have Boolean based blind injection.

0:02:21.500000 --> 0:02:23.540000
 In this particular case, it confirms it.

0:02:23.540000 --> 0:02:27.760000
 It says the get parameter post appears
 to be and Boolean based.

0:02:27.760000 --> 0:02:31.460000
 So pay attention to the logical operator
 here, which is very important,

0:02:31.460000 --> 0:02:35.920000
 which is why I showed you it's important
 to only utilize and because you're

0:02:35.920000 --> 0:02:39.580000
 confirming the entire statement, including
 the actual parameter, the value

0:02:39.580000 --> 0:02:40.500000
 of the parameter.

0:02:40.500000 --> 0:02:44.700000
 So and Boolean based blind where
 or having clause injectable.

0:02:44.700000 --> 0:02:47.060000
 So it is injectable here.

0:02:47.060000 --> 0:02:50.940000
 So now going to say it looks like
 the backend DBMS is MySQL.

0:02:50.940000 --> 0:02:55.740000
 Do you want to skip the skip test payload
 specific for the database management

0:02:55.740000 --> 0:02:57.380000
 systems? Yes, we do.

0:02:57.380000 --> 0:03:00.780000
 So I'm just going to use the default
 option and do you want to include

0:03:00.780000 --> 0:03:06.020000
 all tests for my SQL extending the provided
 level one and risk one values?

0:03:06.020000 --> 0:03:08.260000
 Yes, default option there.

0:03:08.260000 --> 0:03:12.440000
 And it's going to perform various
 tests now in this particular case.

0:03:12.440000 --> 0:03:14.480000
 We're going to let this run here.

0:03:14.480000 --> 0:03:18.520000
 So error based, it's going to go
 through some error based testing.

0:03:18.520000 --> 0:03:23.780000
 And then it's going to go through some
 blind time based SQL injection

0:03:23.780000 --> 0:03:25.440000
 testing as well.

0:03:25.440000 --> 0:03:29.960000
 So just going through all the error
 based payloads that, you know, for

0:03:29.960000 --> 0:03:33.960000
 the various versions of
 my SQL and there we are.

0:03:33.960000 --> 0:03:35.500000
 So I'm going to let this complete.

0:03:35.500000 --> 0:03:39.920000
 And once it's done, I want to, we're
 going to take a look at the results

0:03:39.920000 --> 0:03:46.260000
 and I'm going to show you how cool blind
 Boolean based SQL injection is.

0:03:46.260000 --> 0:03:50.140000
 All right, SQL map has done its magic
 and it looks like there's multiple

0:03:50.140000 --> 0:03:54.540000
 types or sub types of SQL injection vulnerabilities
 that affect that particular

0:03:54.540000 --> 0:03:58.700000
 parameter. In this particular case,
 you can see we have Boolean based

0:03:58.700000 --> 0:04:03.600000
 blind and the payload used was post equals
 one and, you know, just a logical

0:04:03.600000 --> 0:04:07.620000
 operation like five, seven, six, two
 equals five, seven, six, two, which

0:04:07.620000 --> 0:04:10.760000
 is the equivalent of what we
 did with one equals one.

0:04:10.760000 --> 0:04:15.140000
 Again, you can use any value you want
 here as long as it equates to true

0:04:15.140000 --> 0:04:19.740000
 or all is always true, then you should
 be good here and you're not limited

0:04:19.740000 --> 0:04:24.140000
 just to integers, but also characters
 as long as you concatenate them

0:04:24.140000 --> 0:04:26.180000
 with the single quotes.

0:04:26.180000 --> 0:04:29.940000
 And we also have time based blind, which
 is very interesting on the same

0:04:29.940000 --> 0:04:35.000000
 parameter. I will be exploring blind,
 blind based SQL injection in the

0:04:35.000000 --> 0:04:38.980000
 next video. And we also have union
 based SQL injection here, which you

0:04:38.980000 --> 0:04:41.040000
 can also test out.

0:04:41.040000 --> 0:04:42.740000
 But this is going to be blind.

0:04:42.740000 --> 0:04:47.800000
 And what we're looking for is something,
 is something that, you know,

0:04:47.800000 --> 0:04:51.720000
 will clearly verify what, you know,
 whatever is in the database or will

0:04:51.720000 --> 0:04:54.660000
 clearly verify injection as it were.

0:04:54.660000 --> 0:04:59.240000
 Now you can see that we're also able
 to verify that the info we were able

0:04:59.240000 --> 0:05:02.160000
 to infer through our manual
 testing was correct.

0:05:02.160000 --> 0:05:07.820000
 The version or the first character
 in the MySQL version is five, which

0:05:07.820000 --> 0:05:12.340000
 we were able to test now to show you
 something here that is really cool.

0:05:12.340000 --> 0:05:18.980000
 We can also say we can see that the
 versioning here has one, two, three,

0:05:18.980000 --> 0:05:22.880000
 four, five, and six characters
 in total, right?

0:05:22.880000 --> 0:05:28.120000
 So six decimal places, if you will, because
 we're now dealing with a number.

0:05:28.120000 --> 0:05:32.540000
 So we can actually check the sixth
 place here using that same payload

0:05:32.540000 --> 0:05:34.320000
 to see whether it's two.

0:05:34.320000 --> 0:05:38.000000
 And this will prove that the blind SQL
 injection vulnerability is indeed

0:05:38.000000 --> 0:05:40.240000
 working. So I'll go into the repeater.

0:05:40.240000 --> 0:05:43.380000
 And now we'll change this
 to the sixth here.

0:05:43.380000 --> 0:05:49.780000
 And we'll say in this particular case,
 the payload that we utilized here

0:05:49.780000 --> 0:05:53.380000
 is going to be equal to six.

0:05:53.380000 --> 0:05:55.520000
 So we'll just change the five to a six.

0:05:55.520000 --> 0:06:00.560000
 And if it's true, it should again display
 blog post with the ID of one.

0:06:00.560000 --> 0:06:02.320000
 So I'll hit send.

0:06:02.320000 --> 0:06:04.480000
 That's if I've got the placement correct.


0:06:04.480000 --> 0:06:06.200000
 There we are. Fantastic.

0:06:06.200000 --> 0:06:07.760000
 That proves that we are correct.

0:06:07.760000 --> 0:06:12.900000
 So again, we can test it with any other
 like one, two, three, four, and

0:06:12.900000 --> 0:06:14.580000
 five, which is one.

0:06:14.580000 --> 0:06:18.560000
 So let's try the fifth place,
 which is going to be one.

0:06:18.560000 --> 0:06:21.920000
 So I'll change this here from
 six to six to five to five.

0:06:21.920000 --> 0:06:24.460000
 And we can say, is that equal to six?

0:06:24.460000 --> 0:06:25.440000
 This will be false.

0:06:25.440000 --> 0:06:28.080000
 And then I'll change it to
 one to show that it's true.

0:06:28.080000 --> 0:06:31.340000
 So six, there we are false,
 the web application.

0:06:31.340000 --> 0:06:34.200000
 We have already identified that
 it responds in certain ways.

0:06:34.200000 --> 0:06:37.740000
 In this case, we know that if it's
 false, it'll take us to this blank

0:06:37.740000 --> 0:06:41.460000
 page. And we change this to a one, which
 we have been able to verify with

0:06:41.460000 --> 0:06:45.920000
 SQL map. In this particular case,
 it says that is also false.

0:06:45.920000 --> 0:06:47.840000
 Very interesting.

0:06:47.840000 --> 0:06:49.480000
 Let's check that again.

0:06:49.480000 --> 0:06:52.540000
 So one, two, three, four, five.

0:06:52.540000 --> 0:06:56.780000
 Yeah, that should be one,
 the fifth character there.

0:06:56.780000 --> 0:07:01.060000
 In this particular case, it may be referring
 to the fact that the fifth

0:07:01.060000 --> 0:07:05.000000
 is one. Yes, that should be correct.

0:07:05.000000 --> 0:07:07.220000
 So one, two, three, four,
 five, that is one.

0:07:07.220000 --> 0:07:10.420000
 Let's send that again.

0:07:10.420000 --> 0:07:19.780000
 If we say, let's change that to five
 and sorry, five and five six, change

0:07:19.780000 --> 0:07:27.760000
 that here, or actually six and
 five, that should verify it.

0:07:27.760000 --> 0:07:30.640000
 We just change it to six.

0:07:30.640000 --> 0:07:33.900000
 I just want to see something here, whether
 it's treating it as a single

0:07:33.900000 --> 0:07:36.700000
 integer. So we'll send that as 12.

0:07:36.700000 --> 0:07:40.520000
 If it counts the, yeah, so it only
 looks like in this case, if we just

0:07:40.520000 --> 0:07:42.760000
 say two, then that should be true.

0:07:42.760000 --> 0:07:45.780000
 Hold on. So that's false.

0:07:45.780000 --> 0:07:47.620000
 So one, two, three, four, five, six.

0:07:47.620000 --> 0:07:52.340000
 I'm not sure. So one, two, three, four,
 five, six, yeah, that should be

0:07:52.340000 --> 0:07:56.640000
 two. I'm not sure what's up
 with that particular query.

0:07:56.640000 --> 0:08:00.100000
 Let us just write it again.

0:08:00.100000 --> 0:08:01.520000
 So that's six, six.

0:08:01.520000 --> 0:08:07.420000
 And then that's equal to two, that should
 equate to true, but we can write

0:08:07.420000 --> 0:08:08.220000
 it again anyway.

0:08:08.220000 --> 0:08:15.680000
 So we can say and substring version.

0:08:15.680000 --> 0:08:22.360000
 And we're going to say the sixth,
 sixth character, sixth character.

0:08:22.360000 --> 0:08:27.920000
 And that's going to be equal to six.

0:08:27.920000 --> 0:08:32.100000
 All right, let's test this out.

0:08:32.100000 --> 0:08:35.440000
 All right, that looks like it's working.

0:08:35.440000 --> 0:08:36.820000
 So I'll send that again.

0:08:36.820000 --> 0:08:38.520000
 It looks like when we send there we are.

0:08:38.520000 --> 0:08:41.040000
 All right, so it just looks like there's
 an issue with the encoding and

0:08:41.040000 --> 0:08:46.440000
 we changed it. So if we change this
 to five and five, and we change this

0:08:46.440000 --> 0:08:53.580000
 to, sorry, not six, what
 we want is the two there.

0:08:53.580000 --> 0:08:58.420000
 So let's change this
 to two, actually one.

0:08:58.420000 --> 0:09:02.360000
 I'm not sure whether it's
 treating them as one.

0:09:02.360000 --> 0:09:03.980000
 We can actually try that.

0:09:03.980000 --> 0:09:06.240000
 So one, two, three, four.

0:09:06.240000 --> 0:09:08.880000
 So we say four is two.

0:09:08.880000 --> 0:09:18.260000
 Four is two. Again, you also have to
 factor in how it's treated by the

0:09:18.260000 --> 0:09:24.200000
 query here. We could also just say MySQL
 version, let's just confirm whether

0:09:24.200000 --> 0:09:25.380000
 the first one is correct.

0:09:25.380000 --> 0:09:29.820000
 So I'll say one one and
 change this to five.

0:09:29.820000 --> 0:09:31.660000
 First character.

0:09:31.660000 --> 0:09:33.260000
 Okay, so that is valid.

0:09:33.260000 --> 0:09:37.640000
 So it looks like we would need to convert
 this into ASCII or sorry, not

0:09:37.640000 --> 0:09:40.540000
 into ASCII into hex for it to process it.


0:09:40.540000 --> 0:09:43.880000
 But you get the idea the
 version is correct.

0:09:43.880000 --> 0:09:48.420000
 We were able to do that through blind
 SQL injection or blind Boolean based

0:09:48.420000 --> 0:09:54.980000
 SQL injection. Now with, as I said,
 you can perform the exploitation of

0:09:54.980000 --> 0:10:02.040000
 the vulnerability and exfiltration of
 data via SQL map, primarily because

0:10:02.040000 --> 0:10:04.100000
 it does it out of band.

0:10:04.100000 --> 0:10:09.100000
 But I can also show you that we were
 able to confirm a little bit more.

0:10:09.100000 --> 0:10:15.280000
 So if I go ahead and in this particular
 case, I can say DBS to list the

0:10:15.280000 --> 0:10:19.560000
 databases with SQL map to
 see what we have here.

0:10:19.560000 --> 0:10:22.480000
 You can see it's going to
 fetch the database names.

0:10:22.480000 --> 0:10:25.860000
 All right, so we have three database
 names, which again just proves that

0:10:25.860000 --> 0:10:30.440000
 the site is vulnerable to SQL injection
 on that post parameter is vulnerable

0:10:30.440000 --> 0:10:32.800000
 to blind SQL injection.

0:10:32.800000 --> 0:10:37.940000
 We can we know that the name of the target
 web application is Victor CMS.

0:10:37.940000 --> 0:10:44.440000
 So we can say now the database to
 target or to list out is Victor.

0:10:44.440000 --> 0:10:49.080000
 And we can say tables to list out
 the tables in the database Victor.

0:10:49.080000 --> 0:10:51.140000
 So fetching tables, there we are.

0:10:51.140000 --> 0:10:53.060000
 And we have a user's table here.

0:10:53.060000 --> 0:10:56.760000
 So we can now say the table is users.

0:10:56.760000 --> 0:10:58.660000
 And then we can say columns.

0:10:58.660000 --> 0:11:07.000000
 So we can list out the columns in that
 particular table called users.

0:11:07.000000 --> 0:11:13.080000
 And in this particular case, you can see
 that we have the following column.

0:11:13.080000 --> 0:11:19.660000
 So user email, user first name, user
 ID, user image, user last name, etc.

0:11:19.660000 --> 0:11:23.460000
 We can also just say dump
 to display it all.

0:11:23.460000 --> 0:11:28.240000
 So essentially that particular
 that particular table.

0:11:28.240000 --> 0:11:30.740000
 So you can see users contains
 the following info.

0:11:30.740000 --> 0:11:32.540000
 We have use ID random salt.

0:11:32.540000 --> 0:11:36.280000
 These are all columns, username,
 user role, user email.

0:11:36.280000 --> 0:11:42.040000
 And the reason I'm doing this is to show
 you that the blind Boolean basically,

0:11:42.040000 --> 0:11:44.080000
 SQL injection testing actually works.

0:11:44.080000 --> 0:11:53.500000
 So what we can do is we can try and
 confirm, you know, let's say the the

0:11:53.500000 --> 0:12:01.140000
 first, we can try and confirm the value
 of a particular character or particular

0:12:01.140000 --> 0:12:02.880000
 data within any of these columns.

0:12:02.880000 --> 0:12:07.820000
 So we could say, for example, and
 I can show you that payload here.

0:12:07.820000 --> 0:12:09.740000
 Let's just get rid of that here.

0:12:09.740000 --> 0:12:14.160000
 So I can say one and substring.

0:12:14.160000 --> 0:12:18.960000
 And in double brackets, what I'll
 put in here, we can say select.

0:12:18.960000 --> 0:12:24.600000
 And we will select the column user
 email, all right, and I'll show you

0:12:24.600000 --> 0:12:25.620000
 I'll explain what's going on.

0:12:25.620000 --> 0:12:36.680000
 So I can say select user email from
 the table called the table called

0:12:36.680000 --> 0:12:43.260000
 users. All right, so select the column
 user email from the table called

0:12:43.260000 --> 0:12:52.660000
 users. And then we say where we can say
 maybe, let's say username, username

0:12:52.660000 --> 0:12:57.400000
 on sorry, user underscore name, I believe
 is the correct format for that

0:12:57.400000 --> 0:12:58.200000
 particular column.

0:12:58.200000 --> 0:13:05.240000
 Yes, so username is equal to, and
 let's see a value that exists.

0:13:05.240000 --> 0:13:07.200000
 I just want to show you
 that this does work.

0:13:07.200000 --> 0:13:11.340000
 So username admin, so we can
 use admin as an example.

0:13:11.340000 --> 0:13:16.400000
 So we can say where username equals,
 and we'll put this in single quotes

0:13:16.400000 --> 0:13:22.400000
 here, his name equals admin, we'll close
 this and say, let's do something

0:13:22.400000 --> 0:13:24.120000
 a bit more intense.

0:13:24.120000 --> 0:13:29.600000
 So we can say the second
 character is a D, right?

0:13:29.600000 --> 0:13:34.980000
 So we can say admin, let's use
 the second character here.

0:13:34.980000 --> 0:13:41.840000
 So two and two, close that bracket
 and we'll say, can you please tell

0:13:41.840000 --> 0:13:48.220000
 us if the second character in this particular
 that matches the username

0:13:48.220000 --> 0:13:52.920000
 admin, in this particular case,
 we're checking the user email.

0:13:52.920000 --> 0:13:54.380000
 So my apologies.

0:13:54.380000 --> 0:13:59.120000
 So in this case, the user email is
 just admin at admin, which we don't

0:13:59.120000 --> 0:14:03.160000
 know. So we're essentially trying to
 see whether the second character

0:14:03.160000 --> 0:14:09.620000
 in the email that matches the user admin
 is greater than, let's say, a,

0:14:09.620000 --> 0:14:12.760000
 which we know it is, we
 can say greater than C.

0:14:12.760000 --> 0:14:17.240000
 And it should be true, because
 D is greater than C.

0:14:17.240000 --> 0:14:19.460000
 All right, so let's try
 that type of operation.

0:14:19.460000 --> 0:14:25.040000
 So we'll say is greater than, sorry, let
 me just put a space there, because

0:14:25.040000 --> 0:14:27.320000
 I want you to treat it correctly.

0:14:27.320000 --> 0:14:32.980000
 So C, and then we'll add a comment and
 let us encode this particular payload.

0:14:32.980000 --> 0:14:39.740000
 So control you. If it's true, it should
 take us to this, to the blog post

0:14:39.740000 --> 0:14:44.760000
 with the ID one or the first
 blog post, or let's end.

0:14:44.760000 --> 0:14:48.500000
 And in this case, it looks
 like it is false.

0:14:48.500000 --> 0:14:52.300000
 So let me check or recheck my query here.


0:14:52.300000 --> 0:14:55.880000
 So one and substring.

0:14:55.880000 --> 0:15:02.160000
 Yeah, that looks like it is correct.

0:15:02.160000 --> 0:15:12.700000
 Select user email from the table users
 where username is equal to admin.

0:15:12.700000 --> 0:15:21.380000
 And the second character is should
 be greater than C, which it is.

0:15:21.380000 --> 0:15:29.720000
 And what we'll do here is, I think what
 we can do is I'm just trying to

0:15:29.720000 --> 0:15:31.080000
 find any formatting issues.

0:15:31.080000 --> 0:15:34.540000
 Let's try and give these
 a bit of space here.

0:15:34.540000 --> 0:15:39.580000
 So my bad, let me just unencode that
 again here, and we'll give a little

0:15:39.580000 --> 0:15:44.000000
 bit of spacing here, because there
 may be a formatting issue there.

0:15:44.000000 --> 0:15:49.620000
 There we are. And we'll say, control
 you hit send if true, which it is

0:15:49.620000 --> 0:15:55.860000
 true. Then that should take us to
 the blog post with an ID of one.

0:15:55.860000 --> 0:15:58.500000
 But in this case, it looks
 like it's still fault.

0:15:58.500000 --> 0:16:01.360000
 It's still false.

0:16:01.360000 --> 0:16:07.820000
 I say sub string and change it from, you
 know, substring to just substring.

0:16:07.820000 --> 0:16:10.540000
 Or the short form and hit send.

0:16:10.540000 --> 0:16:14.180000
 That still looks like it's false.

0:16:14.180000 --> 0:16:20.900000
 Let us unencode this.

0:16:20.900000 --> 0:16:27.440000
 I just want to see so one and
 substring that is correct.

0:16:27.440000 --> 0:16:32.440000
 We may have an issue where I need to
 utilize or change this to uppercase

0:16:32.440000 --> 0:16:36.200000
 in certain cases, substring.

0:16:36.200000 --> 0:16:38.500000
 And then we say select.

0:16:38.500000 --> 0:16:42.120000
 Let's change that to uppercase.

0:16:42.120000 --> 0:16:45.320000
 User email from the table users.

0:16:45.320000 --> 0:16:46.620000
 Let's change this to uppercase.

0:16:46.620000 --> 0:16:54.680000
 So from user, where the username is
 equal to, in this particular case,

0:16:54.680000 --> 0:16:58.120000
 we need to specify the, you know, the
 absolute value, which in this case

0:16:58.120000 --> 0:17:00.600000
 is admin, which we know exists.

0:17:00.600000 --> 0:17:07.360000
 And then to, to, let's get rid of the
 spaces that may be causing an issue.

0:17:07.360000 --> 0:17:11.240000
 And yeah, we would need
 to check the value.

0:17:11.240000 --> 0:17:14.460000
 And we'd say that is greater than C.

0:17:14.460000 --> 0:17:16.800000
 And we could probably change
 this to uppercase.

0:17:16.800000 --> 0:17:18.100000
 Just want to see what will happen.

0:17:18.100000 --> 0:17:33.440000
 And we'll say locase C just want
 to see what happens there.

0:17:33.440000 --> 0:17:37.120000
 That is still false.

0:17:37.120000 --> 0:17:46.520000
 And let's see. Let's change this to an A.


0:17:46.520000 --> 0:17:52.000000
 Okay, still false.

0:17:52.000000 --> 0:17:55.020000
 We may want to actually hold on.

0:17:55.020000 --> 0:17:58.660000
 Let's unencode this here.

0:17:58.660000 --> 0:18:03.680000
 Just undo that. And let's try and
 use a different comment here.

0:18:03.680000 --> 0:18:05.780000
 Given what we're trying to do.

0:18:05.780000 --> 0:18:08.800000
 So I will just encode this here.

0:18:08.800000 --> 0:18:13.820000
 So control and code or control
 you send this over.

0:18:13.820000 --> 0:18:17.480000
 Okay. Let's just verify.

0:18:17.480000 --> 0:18:29.240000
 So select user email from users where
 the user name we may need to change

0:18:29.240000 --> 0:18:33.560000
 this. If I just say we may be getting
 an issue cause of that, but we could

0:18:33.560000 --> 0:18:40.100000
 just say user name, send that over.

0:18:40.100000 --> 0:18:46.300000
 We'll change this to a C, send that over.


0:18:46.300000 --> 0:18:50.460000
 Second character.

0:18:50.460000 --> 0:18:53.420000
 Let's try this here.

0:18:53.420000 --> 0:19:04.600000
 Want to just make sure that
 this is indeed working.

0:19:04.600000 --> 0:19:11.980000
 And greater than C, hit send still false.


0:19:11.980000 --> 0:19:14.740000
 And I found my mistake.

0:19:14.740000 --> 0:19:19.320000
 This is why it should always
 verify table names.

0:19:19.320000 --> 0:19:23.360000
 I had specified the user as the table
 name, whereas it was users.

0:19:23.360000 --> 0:19:29.400000
 Let's send this particular
 case user name.

0:19:29.400000 --> 0:19:32.120000
 Let's change this here.

0:19:32.120000 --> 0:19:35.060000
 Back to user email.

0:19:35.060000 --> 0:19:40.840000
 So and sub string select user email
 from users where user name.

0:19:40.840000 --> 0:19:43.220000
 Let me verify the table name.

0:19:43.220000 --> 0:19:45.700000
 User name. User email.

0:19:45.700000 --> 0:19:49.780000
 Yeah, that is correct.

0:19:49.780000 --> 0:19:56.660000
 Um, plus user name is equal to admin.

0:19:56.660000 --> 0:20:04.840000
 And we matching that.

0:20:04.840000 --> 0:20:09.240000
 So first position is greater
 than C, which would be false.

0:20:09.240000 --> 0:20:14.480000
 So we can change this to less than C,
 which would be true and would take

0:20:14.480000 --> 0:20:15.460000
 us there hopefully.

0:20:15.460000 --> 0:20:18.240000
 So let's hit send.

0:20:18.240000 --> 0:20:19.320000
 And there we are.

0:20:19.320000 --> 0:20:22.720000
 All right. So it took a little bit of
 testing, which is one of the qualms

0:20:22.720000 --> 0:20:26.620000
 of blind, uh, boolean, basically,
 cool injection.

0:20:26.620000 --> 0:20:27.460000
 But there we are.

0:20:27.460000 --> 0:20:30.300000
 We can see. So what I did is, because
 I remember they changed this to

0:20:30.300000 --> 0:20:33.580000
 the first character, which
 in this case was an A.

0:20:33.580000 --> 0:20:37.700000
 So that's why when we are saying greater
 than C, it would obviously be

0:20:37.700000 --> 0:20:41.700000
 false. And that's why it was giving
 us that same blank page, which we

0:20:41.700000 --> 0:20:46.400000
 know the web application responds to
 whenever there's a false, whenever

0:20:46.400000 --> 0:20:50.800000
 there's a false response or whenever
 the query returns a false response,

0:20:50.800000 --> 0:20:53.600000
 as it were, we can also
 play around with this.

0:20:53.600000 --> 0:20:57.680000
 So we can say our first, second,
 third, fourth, fifth.

0:20:57.680000 --> 0:21:02.820000
 All right. So fifth, we can
 say is greater than M.

0:21:02.820000 --> 0:21:10.600000
 So we'll say the fifth character right
 over here is greater than M.

0:21:10.600000 --> 0:21:15.280000
 Let's see. There we are.

0:21:15.280000 --> 0:21:22.020000
 And fantastic. If we save did greater
 than N, you'll see it will take

0:21:22.020000 --> 0:21:23.660000
 us to the false page.

0:21:23.660000 --> 0:21:26.480000
 Actually, that was correct.

0:21:26.480000 --> 0:21:30.040000
 Fifth place greater than N admin.

0:21:30.040000 --> 0:21:33.880000
 That's very weird.

0:21:33.880000 --> 0:21:38.180000
 Let's try. Is it greater than O?

0:21:38.180000 --> 0:21:41.140000
 Yeah, there we are.

0:21:41.140000 --> 0:21:43.220000
 Okay. So it counted that there.

0:21:43.220000 --> 0:21:45.020000
 But there you go.

0:21:45.020000 --> 0:21:47.840000
 You can see that that evaluates to false.


0:21:47.840000 --> 0:21:51.120000
 So based on this, the reason why I'm
 showing you this is you can sort

0:21:51.120000 --> 0:21:56.580000
 of identify, or you can utilize blind,
 Boolean-based SQL injection to

0:21:56.580000 --> 0:22:01.560000
 identify data manually, character by
 character, just by performing these

0:22:01.560000 --> 0:22:05.840000
 logical tests. So in this case, the
 reason why I did it with SQL map is

0:22:05.840000 --> 0:22:08.300000
 just to verify that what
 I'm showing you is true.

0:22:08.300000 --> 0:22:13.140000
 Now, in this particular case, what
 we can do is again, change this to

0:22:13.140000 --> 0:22:14.140000
 another username.

0:22:14.140000 --> 0:22:19.120000
 So for example, you know, we could change
 it to Victor, and we could do

0:22:19.120000 --> 0:22:23.340000
 the same thing. So it'll just
 do that as a final test here.

0:22:23.340000 --> 0:22:29.960000
 So select user email from users where
 the username is equal to Victor.

0:22:29.960000 --> 0:22:32.660000
 And I'll make sure that
 it is case sensitive.

0:22:32.660000 --> 0:22:38.720000
 So Victor, we make sure that his username
 is actually correct here.

0:22:38.720000 --> 0:22:43.000000
 The reason why I want to make sure is
 because this is formatted in ASCII.

0:22:43.000000 --> 0:22:45.280000
 So I'm just going to dump it again.

0:22:45.280000 --> 0:22:48.960000
 So that is displayed in
 my terminal correctly.

0:22:48.960000 --> 0:22:52.460000
 So username, Victor, yes, that's up.

0:22:52.460000 --> 0:22:58.900000
 Okay. So Victor's email is, you know,
 we have second characters I.

0:22:58.900000 --> 0:23:05.880000
 So that we can say greater than H,
 for example, because I comes after

0:23:05.880000 --> 0:23:10.780000
 H. So in here, we would
 say first and second.

0:23:10.780000 --> 0:23:12.740000
 So let's change that here.

0:23:12.740000 --> 0:23:18.240000
 So Victor second greater than H.

0:23:18.240000 --> 0:23:20.960000
 And let's send that over.

0:23:20.960000 --> 0:23:40.660000
 And there we are, we said greater
 than J or greater than J.

0:23:40.660000 --> 0:23:43.160000
 That would be false and it would
 take us to the blank page.

0:23:43.160000 --> 0:23:46.840000
 So you should now have an understanding
 as to how cool this is because

0:23:46.840000 --> 0:23:52.980000
 again, I've used a, you know, obviously
 a query that would obviously infer

0:23:52.980000 --> 0:23:57.500000
 that I know a lot about the databases
 and the tables and the column names.

0:23:57.500000 --> 0:24:01.180000
 But I was just using it to show you
 that once you've identified a blind

0:24:01.180000 --> 0:24:06.840000
 SQL injection vulnerability, blind Boolean,
 basically, injection vulnerability,

0:24:06.840000 --> 0:24:10.140000
 you can utilize or you can perform
 this type of manual testing if you

0:24:10.140000 --> 0:24:15.540000
 don't want to utilize something like
 SQL map, you know, of course, for

0:24:15.540000 --> 0:24:17.500000
 the exploitation of the vulnerability.

0:24:17.500000 --> 0:24:20.300000
 But this shows you how you can do it
 manually with regards to extracting

0:24:20.300000 --> 0:24:25.140000
 information. So what I was, what I was
 pretty much saying is, you know,

0:24:25.140000 --> 0:24:28.960000
 I can say, you know, for the first position,
 in this case, I'm checking

0:24:28.960000 --> 0:24:36.340000
 the email. I can say, is it is
 the email less than Z, right?

0:24:36.340000 --> 0:24:41.420000
 So the first character within the email,
 is it less than Z or anything

0:24:41.420000 --> 0:24:43.600000
 lower than Z? Yes.

0:24:43.600000 --> 0:24:46.360000
 Okay. So I have to sort
 of narrow it down.

0:24:46.360000 --> 0:24:58.340000
 So I can say, is it lower than is it
 lower than W to see whether it's

0:24:58.340000 --> 0:24:59.780000
 Victor or starts with the V?

0:24:59.780000 --> 0:25:00.860000
 Okay. So there we are.

0:25:00.860000 --> 0:25:05.140000
 We can already see it coincidentally,
 Victor is the one who wrote this

0:25:05.140000 --> 0:25:09.960000
 blog post. So we know that
 it's lower than V.

0:25:09.960000 --> 0:25:14.800000
 Is it greater than you?

0:25:14.800000 --> 0:25:18.220000
 So just showing you how you'd
 go about doing this.

0:25:18.220000 --> 0:25:22.320000
 So we know that now it falls between
 you and W, which means the first

0:25:22.320000 --> 0:25:27.480000
 character of his email
 is starts with the V.

0:25:27.480000 --> 0:25:29.680000
 And then we know we can just
 keep on going as that.

0:25:29.680000 --> 0:25:31.600000
 It's a very long manual process.

0:25:31.600000 --> 0:25:35.240000
 But just wanted to show you that you
 can go ahead and take a look at the

0:25:35.240000 --> 0:25:39.940000
 other SQL injection vulnerabilities
 or subtypes as you if you want to

0:25:39.940000 --> 0:25:43.620000
 call them that. And that is going to
 conclude the practical demonstration

0:25:43.620000 --> 0:25:45.620000
 side of this video.

0:25:45.620000 --> 0:25:52.620000
 All right. So now you've gotten a first
 hand look and practical experience

0:25:52.620000 --> 0:25:59.280000
 with regards to how to identify and exploit
 blind Boolean based SQL injection

0:25:59.280000 --> 0:26:00.800000
 vulnerabilities.

0:26:00.800000 --> 0:26:02.720000
 The lab is really, really cool.

0:26:02.720000 --> 0:26:08.680000
 And as you can see, it is quite interesting
 to see what you can do with

0:26:08.680000 --> 0:26:09.720000
 various payloads.

0:26:09.720000 --> 0:26:13.320000
 And I said, once you've gotten a grasp
 as to how the application responds

0:26:13.320000 --> 0:26:19.600000
 to either true or false or responses
 from the databases that either true

0:26:19.600000 --> 0:26:26.100000
 or false, you'll be able to easily understand
 or determine whether your

0:26:26.100000 --> 0:26:30.420000
 payload was successfully injected
 or not based on what we're done.

0:26:30.420000 --> 0:26:34.100000
 And I wanted to keep it as manual
 and as raw as possible.

0:26:34.100000 --> 0:26:38.540000
 So you can see what I typically do,
 the common issues you run into like

0:26:38.540000 --> 0:26:43.240000
 providing incorrect table
 names, so on and so forth.

0:26:43.240000 --> 0:26:45.980000
 So hopefully that was valuable to you.

0:26:45.980000 --> 0:26:51.500000
 We're now going to turn our attention
 to time based SQL injection.

0:26:51.500000 --> 0:26:54.380000
 So that's what we'll be exploring
 in the next video.