WEBVTT

0:00:03.660000 --> 0:00:06.140000
 Hello everyone and welcome.

0:00:06.140000 --> 0:00:10.360000
 In this video we're going to be taking
 a look at how to exploit, identify

0:00:10.360000 --> 0:00:16.940000
 and exploit a SQL injection
 vulnerability in GenX CMS.

0:00:16.940000 --> 0:00:21.040000
 So as you probably would have guessed,
 this is going to be a practical

0:00:21.040000 --> 0:00:24.500000
 demonstration. So there's
 nothing theoretical.

0:00:24.500000 --> 0:00:28.940000
 As we explored in the previous video,
 while we were taking a look at the

0:00:28.940000 --> 0:00:35.820000
 advanced SQL map usage, the video was
 quite a long one and while we covered

0:00:35.820000 --> 0:00:38.420000
 quite a bit, I wasn't able
 to cover everything.

0:00:38.420000 --> 0:00:43.140000
 And so this video sort of builds on
 that one by exploring a couple of

0:00:43.140000 --> 0:00:45.180000
 other techniques.

0:00:45.180000 --> 0:00:52.680000
 But more importantly, giving you another
 opportunity to test your video

0:00:52.680000 --> 0:00:59.520000
 is showing you how you can identify
 SQL injection vulnerabilities using

0:00:59.520000 --> 0:01:07.920000
 SQL map. And the key example here will
 essentially revolve around not

0:01:07.920000 --> 0:01:12.260000
 knowing whether a particular parameter
 is indeed injectable.

0:01:12.260000 --> 0:01:14.680000
 So that's the objective here.

0:01:14.680000 --> 0:01:24.740000
 So this is going to be practical, which
 below this video, this lab will

0:01:24.740000 --> 0:01:27.960000
 not provide you with access
 to a Kali Linux system.

0:01:27.960000 --> 0:01:32.820000
 So you'll need to use your own or any
 system that you have access to that

0:01:32.820000 --> 0:01:37.300000
 has a browser, burp suite or
 zap, and of course, SQL map.

0:01:37.300000 --> 0:01:41.300000
 Without further ado, I'm going to fire
 up my lab environment as well as

0:01:41.300000 --> 0:01:43.100000
 my Kali Linux system.

0:01:43.100000 --> 0:01:52.180000
 And I'll see you there
 in a couple of minutes.

0:01:52.180000 --> 0:01:53.160000
 So I'll start it up the lab.

0:01:53.160000 --> 0:01:59.540000
 So just as it'll work the same for you,
 when you start up the lab, you'll

0:01:59.540000 --> 0:02:04.200000
 be provided with access to a URL that
 again can be accessed on the internet.

0:02:04.200000 --> 0:02:07.960000
 So you can pretty much use
 any system you want.

0:02:07.960000 --> 0:02:14.020000
 And you can see that it's a Gen X CMS,
 which, you know, standard content

0:02:14.020000 --> 0:02:15.740000
 management system.

0:02:15.740000 --> 0:02:18.520000
 And we have the version right over here.

0:02:18.520000 --> 0:02:24.160000
 So in this particular demo, we're not
 going to rely on POCs or the fact

0:02:24.160000 --> 0:02:30.640000
 that the, you know, the SQL injection vulnerability
 has already been identified

0:02:30.640000 --> 0:02:31.860000
 and all discovered.

0:02:31.860000 --> 0:02:34.600000
 And we have something to work from.

0:02:34.600000 --> 0:02:39.220000
 What we're going to do is again, for
 the sake of brevity, some sort of

0:02:39.220000 --> 0:02:45.720000
 going to shorten the initial recon
 steps by sort of narrowing down the

0:02:45.720000 --> 0:02:49.440000
 application inputs that
 will be targeting.

0:02:49.440000 --> 0:02:54.540000
 And in this case, what we're going
 to do is we are going to target the

0:02:54.540000 --> 0:02:56.320000
 registration form.

0:02:56.320000 --> 0:03:00.360000
 So you just need to navigate
 to register dot PHP.

0:03:00.360000 --> 0:03:04.000000
 And let me make sure intercept
 is disabled for now.

0:03:04.000000 --> 0:03:09.180000
 So we at enter. And you can see there
 we have a very simple registration

0:03:09.180000 --> 0:03:14.360000
 form, as well as the member login here,
 where we can specify a username,

0:03:14.360000 --> 0:03:19.620000
 password, and, you know, we can retuck
 the password, email address, etc.

0:03:19.620000 --> 0:03:23.500000
 So my username, I can go
 with Alexis password.

0:03:23.500000 --> 0:03:29.020000
 I'll just, you know, we just put
 in any random data, like so.

0:03:29.020000 --> 0:03:34.220000
 And then here, I'll just say, Alexis at
 test.com, I'll now turn on intercept.

0:03:34.220000 --> 0:03:40.040000
 And the key thing is that, you know,
 we don't know whether any of these

0:03:40.040000 --> 0:03:43.320000
 input fields are vulnerable
 to SQL injection.

0:03:43.320000 --> 0:03:48.020000
 And that's sort of the objective here
 is to see whether SQL map can actually

0:03:48.020000 --> 0:03:52.400000
 tell us which one is indeed vulnerable.

0:03:52.400000 --> 0:03:58.560000
 And obviously, if we go into, if we
 view the source here, let me just

0:03:58.560000 --> 0:04:02.700000
 for that there. One second.

0:04:02.700000 --> 0:04:05.100000
 So let me just take a step back here.

0:04:05.100000 --> 0:04:07.720000
 Oh boy, I think I forwarded that.

0:04:07.720000 --> 0:04:11.640000
 Let me know we didn't click on register.

0:04:11.640000 --> 0:04:18.860000
 But if I go in here, we can see that
 right over on the registration form.

0:04:18.860000 --> 0:04:25.020000
 Let's see the label username, the name
 is use ID, password one, password

0:04:25.020000 --> 0:04:26.780000
 to the email, etc.

0:04:26.780000 --> 0:04:31.260000
 So we'll be looking to test, you know,
 pretty much all of these, these

0:04:31.260000 --> 0:04:35.380000
 parameters. And I'm assuming this
 is sent, this is a post request.

0:04:35.380000 --> 0:04:37.900000
 So it's going to be sent in the body.

0:04:37.900000 --> 0:04:41.420000
 But the easiest way to verify
 this is just click on submit.

0:04:41.420000 --> 0:04:43.380000
 And here we have the interceptor request.


0:04:43.380000 --> 0:04:47.640000
 So registered or PHP looks like we have
 a cookie, though that's not really

0:04:47.640000 --> 0:04:50.780000
 related to an authenticated session.

0:04:50.780000 --> 0:04:55.460000
 And then yeah, in the body, we can see
 we have the use ID, Alexis, password,

0:04:55.460000 --> 0:05:02.020000
 etc. So what we are going to do is again,
 just to make, you know, to extend

0:05:02.020000 --> 0:05:05.560000
 on what I covered in the previous video
 is we're not going to utilize,

0:05:05.560000 --> 0:05:12.160000
 you know, the functionality afforded
 to us by SQL map that essentially

0:05:12.160000 --> 0:05:15.140000
 allows us to use a saved request.

0:05:15.140000 --> 0:05:22.640000
 What we are going to try and do is generate
 our own SQL map scan or write

0:05:22.640000 --> 0:05:30.600000
 our own SQL map scan that essentially
 removes or, you know, pretty much

0:05:30.600000 --> 0:05:34.380000
 demonstrates how you can do this manually
 if you if you will, even though

0:05:34.380000 --> 0:05:40.080000
 I know SQL map is automated or, you
 know, it's it's an automation tool.

0:05:40.080000 --> 0:05:42.700000
 So I'll copy the URL first.

0:05:42.700000 --> 0:05:44.380000
 So it's registered or PHP.

0:05:44.380000 --> 0:05:45.760000
 That's the end point.

0:05:45.760000 --> 0:05:49.100000
 I'll paste in that there
 in the URL field.

0:05:49.100000 --> 0:05:50.740000
 And then what do we need to do?

0:05:50.740000 --> 0:05:59.640000
 Well, if we analyze the request here,
 we can see that we have some data

0:05:59.640000 --> 0:06:02.480000
 in the body. So we need to copy this.

0:06:02.480000 --> 0:06:09.260000
 And this is essentially what you do
 if again, you are testing if you're

0:06:09.260000 --> 0:06:13.200000
 using SQL map to identify SQL injection
 vulnerabilities in a registration

0:06:13.200000 --> 0:06:15.800000
 form, it could be any
 website on the planet.

0:06:15.800000 --> 0:06:16.760000
 Right. So there we are.

0:06:16.760000 --> 0:06:26.680000
 We have, um, right over here, use ID,
 Alexis, and then, yeah, so we are

0:06:26.680000 --> 0:06:30.840000
 not going, we are not even going to
 specify a parameter to begin with,

0:06:30.840000 --> 0:06:33.900000
 but we could, however, let's skip that.

0:06:33.900000 --> 0:06:39.380000
 And then I'm going to say,
 threads, let's speed it up.

0:06:39.380000 --> 0:06:41.160000
 So three hit enter.

0:06:41.160000 --> 0:06:44.540000
 And it's going to tell us that the post
 parameter token appears to hold

0:06:44.540000 --> 0:06:46.040000
 an anti CSRF token.

0:06:46.040000 --> 0:06:48.620000
 Do you want to automatically update it?

0:06:48.620000 --> 0:06:51.140000
 No, we don't. Okay.

0:06:51.140000 --> 0:06:53.120000
 So we've not declared cookies.

0:06:53.120000 --> 0:06:55.380000
 While the server wants to set its own.

0:06:55.380000 --> 0:06:56.660000
 Yes, that's fine.

0:06:56.660000 --> 0:06:59.940000
 So SQL map can get its own
 cookie and use that.

0:06:59.940000 --> 0:07:06.340000
 Let's see. So we can see right over
 here, it's saying that the target

0:07:06.340000 --> 0:07:07.780000
 URL is not stable.

0:07:07.780000 --> 0:07:10.880000
 That's fine. We can just
 hit enter to continue.

0:07:10.880000 --> 0:07:16.280000
 And now it's going to test each of those
 parameters within the data within

0:07:16.280000 --> 0:07:21.560000
 the data that's sent in
 the body of the request.

0:07:21.560000 --> 0:07:25.600000
 So as you can see, it's starting
 off with the user ID parameter.

0:07:25.600000 --> 0:07:29.860000
 So it's saying it looks like
 the backend DBMS is MySQL.

0:07:29.860000 --> 0:07:34.260000
 Do you want to skip test payloads
 for for other DBMSs?

0:07:34.260000 --> 0:07:36.200000
 We'll go with the default, which is yes.

0:07:36.200000 --> 0:07:41.540000
 For the remaining tests, do you want to
 include all tests for MySQL extending

0:07:41.540000 --> 0:07:42.940000
 the provided level?

0:07:42.940000 --> 0:07:45.640000
 No. So we'll say no, we don't need that.

0:07:45.640000 --> 0:07:51.660000
 But we could of course include or use
 levels or specify a level and risk

0:07:51.660000 --> 0:07:54.780000
 option if we don't find
 anything like this.

0:07:54.780000 --> 0:07:57.340000
 So let's see what we find.

0:07:57.340000 --> 0:08:00.500000
 So I'm just going to wait
 for this to complete.

0:08:00.500000 --> 0:08:04.960000
 All right. So it's asking us whether
 we want to retry to find proper union

0:08:04.960000 --> 0:08:09.880000
 columns. I'm just going to hit
 the default, which is no.

0:08:09.880000 --> 0:08:14.400000
 And we're just going with sort of the
 defaults as you, you know, if you

0:08:14.400000 --> 0:08:19.300000
 will, nothing too crazy, just keeping
 keeping it nice and simple.

0:08:19.300000 --> 0:08:24.960000
 So we are, you know, based on what I've
 seen here, it looks like the post

0:08:24.960000 --> 0:08:29.740000
 parameter use idea, use idea
 appears to be injectable.

0:08:29.740000 --> 0:08:31.720000
 So you can see it is vulnerable.

0:08:31.720000 --> 0:08:33.620000
 Do we want to test the others?

0:08:33.620000 --> 0:08:37.080000
 This is very important because if you
 found one, you probably want to

0:08:37.080000 --> 0:08:39.080000
 explore that a little bit more.

0:08:39.080000 --> 0:08:42.300000
 Or you can tell SQL map to
 test the other parameters.

0:08:42.300000 --> 0:08:45.920000
 I'm just going to go with the default,
 which is no, although that's something

0:08:45.920000 --> 0:08:47.880000
 you could do. So there we are.

0:08:47.880000 --> 0:08:54.020000
 It looks like SQL map identified,
 the following injection points.

0:08:54.020000 --> 0:08:56.360000
 And these are the vulnerabilities
 we're able to find.

0:08:56.360000 --> 0:09:02.600000
 So we have the parameter use
 ID post type is error based.

0:09:02.600000 --> 0:09:03.420000
 And we have a payload.

0:09:03.420000 --> 0:09:05.740000
 We can use to test this out.

0:09:05.740000 --> 0:09:09.160000
 We also have time based blind.

0:09:09.160000 --> 0:09:14.140000
 So at this point, what we can now do,
 and by the way, we can also see

0:09:14.140000 --> 0:09:17.880000
 the web application technology here,
 we can also, you know, perform some

0:09:17.880000 --> 0:09:22.120000
 banner grabbing, if you will, to try
 and identify the version of MySQL.

0:09:22.120000 --> 0:09:24.560000
 But that's really not what
 we're interested in.

0:09:24.560000 --> 0:09:29.080000
 What we can do now is we set
 the threads right over here.

0:09:29.080000 --> 0:09:33.740000
 Let's see. At this point, we could specify
 the technique we want to use.

0:09:33.740000 --> 0:09:37.840000
 So error based, if we wanted to, but
 what I'll do is just say DBS and

0:09:37.840000 --> 0:09:39.640000
 let's see what we're able to get.

0:09:39.640000 --> 0:09:42.420000
 And before I do that, I'm
 just going to say batch.

0:09:42.420000 --> 0:09:46.720000
 So we can avoid, you know, those prompts.


0:09:46.720000 --> 0:09:47.920000
 And there we are.

0:09:47.920000 --> 0:09:50.760000
 So yeah, SQL injection successful.

0:09:50.760000 --> 0:09:53.760000
 And we have four databases.

0:09:53.760000 --> 0:09:57.340000
 We have the performance schema, information
 schema, and MySQL, the only

0:09:57.340000 --> 0:10:01.680000
 one that has, you know, data related
 to the CMS is just app.

0:10:01.680000 --> 0:10:08.640000
 So we can now say, right over here, the
 database we want to interact with

0:10:08.640000 --> 0:10:13.360000
 is app. And then we can list out the
 tables and all to say batch again

0:10:13.360000 --> 0:10:23.120000
 here, like so. And let's see what tables
 we have in the database app,

0:10:23.120000 --> 0:10:24.960000
 or the app database, if you will.

0:10:24.960000 --> 0:10:30.140000
 So we have options, user, cat, menus,
 posts, post parameters and user

0:10:30.140000 --> 0:10:36.440000
 details. So again, if we wanted to,
 let's say, specify the table now as

0:10:36.440000 --> 0:10:40.560000
 user, see whether we have anything
 juicy in there, we can do that.

0:10:40.560000 --> 0:10:43.940000
 And then we can say dump,
 and I'll say batch.

0:10:43.940000 --> 0:10:48.260000
 And I'll just zoom out so that the data,
 if we have any user data, it's

0:10:48.260000 --> 0:10:51.180000
 actually displayed correctly.

0:10:51.180000 --> 0:10:53.660000
 So we'll give this a few seconds.

0:10:53.660000 --> 0:10:55.800000
 There we are. Looks like
 we're getting something.

0:10:55.800000 --> 0:11:00.060000
 We have an email password or pass.

0:11:00.060000 --> 0:11:03.000000
 And it's getting, it looks
 like we have zero one.

0:11:03.000000 --> 0:11:04.180000
 Okay. All right.

0:11:04.180000 --> 0:11:07.280000
 So admin, we get the password,
 what appears to be a password.

0:11:07.280000 --> 0:11:14.020000
 Then funnily enough, the, I should have
 disabled this, because we don't

0:11:14.020000 --> 0:11:15.920000
 want to crack anything.

0:11:15.920000 --> 0:11:17.000000
 But there we go.

0:11:17.000000 --> 0:11:21.760000
 We can see right over here
 that the cracking failed.

0:11:21.760000 --> 0:11:24.760000
 You know, you can see
 that right over here.

0:11:24.760000 --> 0:11:28.760000
 Sorry. It asks us whether we
 want to crack the hashes.

0:11:28.760000 --> 0:11:39.020000
 And because I specified the default
 SQL map word list, which is fine,

0:11:39.020000 --> 0:11:40.560000
 but we weren't able to find anything.

0:11:40.560000 --> 0:11:47.040000
 The bottom line is we have admin, you
 know, within the user table, we

0:11:47.040000 --> 0:11:50.940000
 have two rows or two users admin and
 Alexis, it looks like it actually

0:11:50.940000 --> 0:11:56.640000
 saved. It has that user, even though
 we didn't complete the registration.

0:11:56.640000 --> 0:11:58.680000
 Very interesting.

0:11:58.680000 --> 0:12:02.280000
 And yeah, we can see activation
 is probably still pending.

0:12:02.280000 --> 0:12:04.080000
 But there you go.

0:12:04.080000 --> 0:12:07.100000
 You can, of course, you
 know, take this here.

0:12:07.100000 --> 0:12:12.080000
 And if I say hash identifier, this should
 tell us what we're dealing with.

0:12:12.080000 --> 0:12:17.300000
 So right over here, probably
 empty, MD five.

0:12:17.300000 --> 0:12:31.060000
 If I now say, let me navigate to my
 desktop and I'll just say, one of

0:12:31.060000 --> 0:12:38.500000
 them at least, and then we say john,
 not specify a hash format.

0:12:38.500000 --> 0:12:44.860000
 But there we are, Leah looks
 like it's Lm over here.

0:12:44.860000 --> 0:12:51.520000
 So we can say MD four, most
 likely MD four in this case.

0:12:51.520000 --> 0:12:59.020000
 Yeah. So bottom line is, you know,
 you can then take it to its logical

0:12:59.020000 --> 0:13:02.620000
 conclusion. And we're able to dump that.

0:13:02.620000 --> 0:13:06.440000
 So I just wanted to show you that again,
 you don't need to rely on the

0:13:06.440000 --> 0:13:12.380000
 intercepted request, you know, that we
 that we used in the previous video

0:13:12.380000 --> 0:13:16.460000
 can actually just by analyzing your interactions
 with the web application

0:13:16.460000 --> 0:13:22.060000
 craft your own scan with SQL map and specify
 the data, you can then specify

0:13:22.060000 --> 0:13:24.800000
 the parameter you want to inject.

0:13:24.800000 --> 0:13:30.780000
 So for example, you know, if I go back
 to one of the earlier scans here,

0:13:30.780000 --> 0:13:35.240000
 we'll just get rid of that there we
 can then specify the payload, let's

0:13:35.240000 --> 0:13:40.380000
 say if we wanted to do, sorry, the parameter
 we wanted to test is, let's

0:13:40.380000 --> 0:13:46.520000
 say, also two, we can try email as
 an example, although that's really

0:13:46.520000 --> 0:13:47.780000
 not that useful.

0:13:47.780000 --> 0:13:51.920000
 But you know, we can say payload email,
 and it would test for that.

0:13:51.920000 --> 0:13:53.500000
 So we can hit enter.

0:13:53.500000 --> 0:13:56.820000
 And let me just zoom in here.

0:13:56.820000 --> 0:13:59.340000
 So you guys can see that
 a little bit better.

0:13:59.340000 --> 0:14:03.240000
 So there we go. Just proceed.

0:14:03.240000 --> 0:14:08.880000
 No, we might have something here,
 but let's just continue and see.

0:14:08.880000 --> 0:14:11.300000
 Do we want to extend?

0:14:11.300000 --> 0:14:14.540000
 No, I don't want to extend that.

0:14:14.540000 --> 0:14:18.500000
 So I'm doubting, I doubt that, you
 know, some of the other parameters

0:14:18.500000 --> 0:14:23.720000
 included in the body of the request
 when registering one account will

0:14:23.720000 --> 0:14:30.780000
 be vulnerable. Yeah, it looks like looks
 like it is injectable, but we'll

0:14:30.780000 --> 0:14:37.380000
 do with the current level or the level and
 risk being set to one, respectively.

0:14:37.380000 --> 0:14:43.040000
 I'm wondering whether we'll, you know,
 we'll actually get a payload or

0:14:43.040000 --> 0:14:45.420000
 a confirmation of the vulnerability.

0:14:45.420000 --> 0:14:49.040000
 So I'll just wait for this to complete.

0:14:49.040000 --> 0:14:51.400000
 And looks like it's almost done.

0:14:51.400000 --> 0:14:55.460000
 It's testing union based payloads.

0:14:55.460000 --> 0:14:59.800000
 So I'll just get back to
 you when this is done.

0:14:59.800000 --> 0:15:02.520000
 All right, so it's done.

0:15:02.520000 --> 0:15:08.940000
 And it looks like the email parameter
 is indeed vulnerable to Boolean

0:15:08.940000 --> 0:15:14.520000
 based blind error based and time based,
 which is quite interesting.

0:15:14.520000 --> 0:15:21.400000
 And I'll explain a little bit about
 for now, let's just verify that this

0:15:21.400000 --> 0:15:25.820000
 again will keep the parameters email.

0:15:25.820000 --> 0:15:28.820000
 Let's use DBS here.

0:15:28.820000 --> 0:15:34.940000
 There we are. So yeah, looks
 like it is indeed successful.

0:15:34.940000 --> 0:15:40.340000
 And the reason this is sort of important
 is because of the following.

0:15:40.340000 --> 0:15:50.300000
 So if we go back to the web app here,
 we can see that open up a new tab

0:15:50.300000 --> 0:15:57.680000
 here and also search, exploit, genix,
 okay, and 003 registered of PHP

0:15:57.680000 --> 0:16:03.800000
 SQL injection. So why didn't I start
 off by telling you that or showing

0:16:03.800000 --> 0:16:10.260000
 you that there is indeed an existing,
 you know, POC, you know, for the

0:16:10.260000 --> 0:16:12.260000
 SQL injection vulnerability?

0:16:12.260000 --> 0:16:14.720000
 Well, you'll see why in a few seconds.

0:16:14.720000 --> 0:16:18.260000
 So what I'm going to do is I'm just
 going to catch this and because I

0:16:18.260000 --> 0:16:23.920000
 really don't need it locally,
 exploit DB exploits PHP.

0:16:23.920000 --> 0:16:26.440000
 And that is web apps.

0:16:26.440000 --> 0:16:30.860000
 What we're looking for is three,
 this one right over here.

0:16:30.860000 --> 0:16:34.000000
 So I'll just copy it because
 I'm a bit lazy right now.

0:16:34.000000 --> 0:16:36.180000
 And we'll paste that in here.

0:16:36.180000 --> 0:16:41.320000
 Okay, so let's actually verify what this,
 you know, what we found against

0:16:41.320000 --> 0:16:48.300000
 this POC. So there we are, POC, genix,
 CMS registered or PHP email, SQL

0:16:48.300000 --> 0:16:50.040000
 injection vulnerability.

0:16:50.040000 --> 0:16:53.320000
 So looks like we weren't
 the one to find this.

0:16:53.320000 --> 0:16:56.100000
 There's one for use ID.

0:16:56.100000 --> 0:16:58.660000
 But none of the other parameters.

0:16:58.660000 --> 0:16:59.840000
 So quite interesting.

0:16:59.840000 --> 0:17:00.720000
 And here's the truth.

0:17:00.720000 --> 0:17:03.260000
 This is the first time I'm seeing this.

0:17:03.260000 --> 0:17:05.360000
 I don't know how to prove that to you.

0:17:05.360000 --> 0:17:11.940000
 But again, I did not know that email
 was indeed vulnerable to injection.

0:17:11.940000 --> 0:17:14.180000
 And we can see right over here.

0:17:14.180000 --> 0:17:17.200000
 This is the post request here.

0:17:17.200000 --> 0:17:22.620000
 And it gives us the payload that we
 can use, you know, for a POC, which

0:17:22.620000 --> 0:17:29.920000
 in this case, if we take a look at our
 SQL Mac payloads here, that's probably,

0:17:29.920000 --> 0:17:31.600000
 let's go back here.

0:17:31.600000 --> 0:17:38.680000
 That is from concatenate
 information schema.

0:17:38.680000 --> 0:17:42.060000
 Yeah, that's very interesting.

0:17:42.060000 --> 0:17:46.400000
 It's not telling me what
 payload exactly that is.

0:17:46.400000 --> 0:17:52.640000
 Just a second. This is probably
 error based if I'm not mistaken.

0:17:52.640000 --> 0:18:07.140000
 So let's just see right
 over here, register.

0:18:07.140000 --> 0:18:10.940000
 Interesting. So this payload
 and select here.

0:18:10.940000 --> 0:18:23.000000
 So that's very. Now the time based blind,
 I believe is the one being referenced

0:18:23.000000 --> 0:18:28.180000
 in the POC. Anyway, we, you know, we're
 also able to verify with SQL map

0:18:28.180000 --> 0:18:31.220000
 what other techniques we can use.

0:18:31.220000 --> 0:18:34.860000
 And then of course, as I mentioned
 in the previous video, feel free to

0:18:34.860000 --> 0:18:39.520000
 leverage or specify the technique
 if you want to be specific.

0:18:39.520000 --> 0:18:43.440000
 And yeah, so that brings us to the
 end of the practical demonstration

0:18:43.440000 --> 0:18:46.180000
 section of this video.

0:18:46.180000 --> 0:18:51.560000
 All right, so that was another example
 of, you know, how to leverage SQL

0:18:51.560000 --> 0:18:57.320000
 map. Again, nothing, nothing to advance
 to what you might consider as

0:18:57.320000 --> 0:19:04.700000
 being advanced. But again, the idea
 is to slowly, you know, show you how

0:19:04.700000 --> 0:19:07.920000
 you can use SQL map, again, regardless
 as to whether you're using it to

0:19:07.920000 --> 0:19:11.980000
 identify vulnerabilities, you know,
 SQL injection vulnerabilities.

0:19:11.980000 --> 0:19:18.760000
 And then obviously how to fine tune your
 SQL map scans, you know, to test

0:19:18.760000 --> 0:19:23.060000
 for specific SQL injection vulnerabilities
 or to test specific parameters.

0:19:23.060000 --> 0:19:29.680000
 And also, another important reason
 or one of the reasons why I wanted

0:19:29.680000 --> 0:19:35.600000
 to, to have this demo or to present
 this was again, to show you that,

0:19:35.600000 --> 0:19:40.980000
 you know, it's never good thing to be
 reliant on things like the request,

0:19:40.980000 --> 0:19:46.520000
 the interceptor request, you actually
 should, it's extremely easy to craft

0:19:46.520000 --> 0:19:52.460000
 your own scan based on, you know, the,
 the, the type of application input

0:19:52.460000 --> 0:19:56.760000
 you're testing. In this case, it was
 a registration form, fairly simple.

0:19:56.760000 --> 0:19:59.880000
 And you can see the other thing I wanted
 to show you is that SQL map is

0:19:59.880000 --> 0:20:05.600000
 really, really powerful in that it'll
 handle stuff like cookies for you.

0:20:05.600000 --> 0:20:07.320000
 So you don't have to worry about that.

0:20:07.320000 --> 0:20:10.980000
 You know, as well as other HTTP headers.

0:20:10.980000 --> 0:20:13.520000
 But with that being said, that's
 going to be it for this video.

0:20:13.520000 --> 0:20:16.340000
 And I will be seeing you
 in the next video.