WEBVTT

0:00:09.620000 --> 0:00:17.460000
 So what you need to do now is go into
 your web proxy and you want to go

0:00:17.460000 --> 0:00:21.280000
 in here and we'll just choose a random
 user and we'll click view blog

0:00:21.280000 --> 0:00:25.900000
 entries. Now you can see that we have
 nothing in the URL and what I'll

0:00:25.900000 --> 0:00:34.040000
 do here is let me navigate into options
 and actually hold on intercept.

0:00:34.040000 --> 0:00:41.740000
 What we want to do is take a look at
 settings and what user interface.

0:00:41.740000 --> 0:00:45.740000
 So display the appearance font size.

0:00:45.740000 --> 0:00:47.660000
 Let me just increase that there.

0:00:47.660000 --> 0:00:51.100000
 That's going to change the overall
 font size which is not what I want

0:00:51.100000 --> 0:00:56.220000
 but if we go into proxy intercept we
 should have settings here but that's

0:00:56.220000 --> 0:00:56.880000
 the main settings.

0:00:56.880000 --> 0:01:01.300000
 If I go into message editor there we are.


0:01:01.300000 --> 0:01:04.560000
 I'll increase that slightly
 so you can see that there.

0:01:04.560000 --> 0:01:07.400000
 You can actually see the HTTP request.

0:01:07.400000 --> 0:01:11.700000
 In this case it is a post request
 which means it's sending data.

0:01:11.700000 --> 0:01:14.300000
 No parameters in the URL.

0:01:14.300000 --> 0:01:18.580000
 If we take a look at the cookie we
 just have a PHP session ID there.

0:01:18.580000 --> 0:01:24.960000
 However in the body of the HTTP request
 we can see that those parameters

0:01:24.960000 --> 0:01:29.500000
 are being sent. The point I'm making is
 it's still being sent in the request.

0:01:29.500000 --> 0:01:31.320000
 In this case a post request.

0:01:31.320000 --> 0:01:35.060000
 However it's being sent in the body which
 means it's not going to be visible

0:01:35.060000 --> 0:01:40.900000
 either in the URL as a parameter or
 the injection cannot be performed

0:01:40.900000 --> 0:01:43.440000
 manually by an application input.

0:01:43.440000 --> 0:01:47.000000
 Of course it's being done through a
 manual system where it shows you the

0:01:47.000000 --> 0:01:53.800000
 list of users that you can actually view
 the blog posts for but the point

0:01:53.800000 --> 0:01:57.120000
 I'm making is this is being sent
 in the body of the request.

0:01:57.120000 --> 0:02:01.880000
 If you take a look at the inspector
 to your right here you can see you

0:02:01.880000 --> 0:02:05.780000
 have the request body parameters where
 we have author John and then view

0:02:05.780000 --> 0:02:11.380000
 someone's blog. So obviously I'm assuming
 this is going to be the injectable

0:02:11.380000 --> 0:02:15.460000
 parameter. So what we do now is
 there's two things we can do.

0:02:15.460000 --> 0:02:18.580000
 We can do the testing by modifying
 requests as we send them or we can

0:02:18.580000 --> 0:02:20.600000
 send them to the repeater which I'll do.

0:02:20.600000 --> 0:02:24.620000
 However let's try and use the single
 quote there just to see what comes

0:02:24.620000 --> 0:02:28.240000
 up. So I'll forward that
 there and there we are.

0:02:28.240000 --> 0:02:32.800000
 So error based injection we can see
 it displays the MySQL error here and

0:02:32.800000 --> 0:02:37.040000
 it also displays the query and
 the query proves my point.

0:02:37.040000 --> 0:02:44.560000
 So in this case it's selecting all
 from the column blog stable.

0:02:44.560000 --> 0:02:49.780000
 Sorry it's selecting all from the table
 called blogs table where the blogger

0:02:49.780000 --> 0:02:57.580000
 name or the column or attribute like
 and here we have the world card and

0:02:57.580000 --> 0:03:03.900000
 it's ordered in this particular case
 by date descending limit 0 to 100.

0:03:03.900000 --> 0:03:06.360000
 So very simple query.

0:03:06.360000 --> 0:03:11.760000
 This is the injectable point here because
 there's no other parameter within

0:03:11.760000 --> 0:03:13.900000
 this query. Right?

0:03:13.900000 --> 0:03:15.520000
 So what can we do here?

0:03:15.520000 --> 0:03:20.740000
 Well again we can just put in our simple
 or the same that we can just

0:03:20.740000 --> 0:03:26.320000
 put in the same SQL payload that
 we're using the Boolean one.

0:03:26.320000 --> 0:03:30.580000
 So I will just choose another one here
 and just submit that and I'll go

0:03:30.580000 --> 0:03:36.680000
 in here and we can now say one
 sorry or one equals one.

0:03:36.680000 --> 0:03:39.240000
 Use the comment there we
 may need to URL and code.

0:03:39.240000 --> 0:03:42.560000
 The better way of testing this is to
 send it to the repeater where we

0:03:42.560000 --> 0:03:45.980000
 can modify the requests and view the
 responses on the fly and also render

0:03:45.980000 --> 0:03:52.120000
 the responses. So I'll now send this and
 let's take a look at the response.

0:03:52.120000 --> 0:03:59.640000
 This particular case we have a lot
 so we're better off rendering it to

0:03:59.640000 --> 0:04:02.160000
 see what the response
 was and there we are.

0:04:02.160000 --> 0:04:07.680000
 So what this does is it displays
 the blog posts for all the users.

0:04:07.680000 --> 0:04:13.140000
 Now this is something that was possible
 beforehand because if I go into

0:04:13.140000 --> 0:04:17.780000
 Firefox actually let's just go back
 into ZAP here sorry into the burp

0:04:17.780000 --> 0:04:22.140000
 suite browser we can show all which
 will probably just display the same.

0:04:22.140000 --> 0:04:26.520000
 So this is not really a cool SQL injection
 but we have verified that SQL

0:04:26.520000 --> 0:04:28.060000
 injection is possible.

0:04:28.060000 --> 0:04:31.680000
 So this is still pretty cool in that
 we've been able to dump all of this

0:04:31.680000 --> 0:04:33.760000
 for all the users.

0:04:33.760000 --> 0:04:38.180000
 What we can probably do here because
 this is probably going to be blind

0:04:38.180000 --> 0:04:41.200000
 in most cases even though
 in this case it's not.

0:04:41.200000 --> 0:04:47.860000
 We can try and perform some blind SQL
 injection or we can try some union

0:04:47.860000 --> 0:04:55.680000
 payloads right. So what we'll do here
 is we'll get rid of this here and

0:04:55.680000 --> 0:05:01.240000
 we can try union payload like for example
 a union select and I'll show

0:05:01.240000 --> 0:05:03.960000
 you where you can find them they're
 still on that GitHub repo we can say

0:05:03.960000 --> 0:05:12.240000
 null null null null and let's use a
 comment and let's send that there.

0:05:12.240000 --> 0:05:14.820000
 Let's view the response let's
 see what that looks like.

0:05:14.820000 --> 0:05:19.280000
 So in this case it looks like that is
 working if we go back into Firefox

0:05:19.280000 --> 0:05:23.980000
 and take a look at some payloads here
 for union and we'll also talk about

0:05:23.980000 --> 0:05:29.220000
 time based injection which is still
 blind but I just want to show you

0:05:29.220000 --> 0:05:30.260000
 how this would work.

0:05:30.260000 --> 0:05:34.660000
 So these are these old tests to show
 you that it does indeed work.

0:05:34.660000 --> 0:05:43.140000
 So for example we can get it to let's see
 one that is potentially interesting

0:05:43.140000 --> 0:05:49.540000
 so we don't want sleep yet but that
 I know will cause the database to

0:05:49.540000 --> 0:05:54.400000
 crash but for example let's see I don't
 want anything sleep but yeah we

0:05:54.400000 --> 0:05:57.820000
 can try you know union select
 and this very large one here.

0:05:57.820000 --> 0:06:01.440000
 Just to see what happens again
 this is all about testing.

0:06:01.440000 --> 0:06:10.160000
 So we'll paste that in there so union
 select union all select and then

0:06:10.160000 --> 0:06:14.460000
 we use the we'll use the pound symbol
 cause that seems to be working in

0:06:14.460000 --> 0:06:18.340000
 this case and let's see what the response
 is here and in this case we

0:06:18.340000 --> 0:06:23.240000
 have an error so we've invoked an error
 of sorts if we take a look at

0:06:23.240000 --> 0:06:29.000000
 this here actually we can display that
 entire message there but you get

0:06:29.000000 --> 0:06:35.520000
 the idea if we go back and let's try
 and use this payload here so union

0:06:35.520000 --> 0:06:42.960000
 and select sorry union all select my
 bad and we go in here and let's just

0:06:42.960000 --> 0:06:45.540000
 replace that there.

0:06:45.540000 --> 0:06:49.960000
 Of course we can also test the double
 hyphen but I doubt that will work

0:06:49.960000 --> 0:06:55.840000
 so let's see what the response is like
 here so we still get an error.

0:06:55.840000 --> 0:07:01.260000
 If we take a look at the query select
 all from blog stable where blog

0:07:01.260000 --> 0:07:08.720000
 name is like blog and name like or similar
 to and we have the injection

0:07:08.720000 --> 0:07:13.300000
 there so union all select one to three
 what we can also do to sort of

0:07:13.300000 --> 0:07:20.860000
 verify this is this is selecting all
 so what we can do is try and perform

0:07:20.860000 --> 0:07:32.920000
 some tests where we can say union select
 all and we'll use sort of a similar

0:07:32.920000 --> 0:08:02.380000
 one so from blogs table where sorry
 where the blog and name is that's

0:08:02.380000 --> 0:08:07.920000
 the new and in here we could put sort
 of a match like for example admin

0:08:07.920000 --> 0:08:14.100000
 and then let's end that with a comment
 so we're just trying to combine

0:08:14.100000 --> 0:08:16.920000
 that so we're going to say union instead
 of all we're just going to say

0:08:16.920000 --> 0:08:22.360000
 union select so union as you know allows
 you to combine two select statements

0:08:22.360000 --> 0:08:28.020000
 so we'll send that over let's see what
 the response is like and there

0:08:28.020000 --> 0:08:32.360000
 we are so that actually works the reason
 that worked is firstly we have

0:08:32.360000 --> 0:08:37.060000
 the initial query right and what we're
 doing is we're just appending there

0:08:37.060000 --> 0:08:42.240000
 and we're saying union select from
 blog stable where the blogger name

0:08:42.240000 --> 0:08:47.020000
 is admin let's see if this works we'll
 go back in here and let's see some

0:08:47.020000 --> 0:08:52.780000
 other users like Bryce for example just
 to prove that this is indeed working

0:08:52.780000 --> 0:08:58.740000
 so and I'll explain what's going on
 if it's not clear already in this

0:08:58.740000 --> 0:09:04.100000
 particular case where the blogger name
 is equal to Bryce if we go back

0:09:04.100000 --> 0:09:11.520000
 in here we take a look at the query
 where the name is like in this case

0:09:11.520000 --> 0:09:16.660000
 there is no match because that's where
 we're making the injection but

0:09:16.660000 --> 0:09:20.980000
 if this was pointing or was equal to
 another username so for example I

0:09:20.980000 --> 0:09:26.480000
 can give you this this will probably
 be an error where we can say so admin

0:09:26.480000 --> 0:09:30.140000
 let's just try this this is very interesting
 to see what comes up here

0:09:30.140000 --> 0:09:36.820000
 so there we are that still brings us
 admin but not Bryce if I change this

0:09:36.820000 --> 0:09:43.780000
 to Bryce that'll just bring up Bryce
 actually doesn't bring up anything

0:09:43.780000 --> 0:09:48.800000
 there which is a very very interesting
 that may be being passed differently

0:09:48.800000 --> 0:09:54.800000
 but you get the idea so union select
 all from and the reason we're using

0:09:54.800000 --> 0:09:58.840000
 all is because the number of columns
 need to match now if there's another

0:09:58.840000 --> 0:10:03.920000
 table that has three columns we can
 probably do that so select all from

0:10:03.920000 --> 0:10:12.620000
 I believe accounts where the blogger
 name where the actually we don't

0:10:12.620000 --> 0:10:16.720000
 actually need to specify where there
 so we'll just say all from accounts

0:10:16.720000 --> 0:10:21.940000
 let's see if that works if we get an
 error it'll still confirm what I'm

0:10:21.940000 --> 0:10:24.560000
 saying here so there we are the use
 select statements have a different

0:10:24.560000 --> 0:10:29.480000
 number of columns so let's try and verify
 this if we go back in here into

0:10:29.480000 --> 0:10:34.180000
 Firefox and I'll just say on the login
 form 1 equals 1 the reason I'm

0:10:34.180000 --> 0:10:44.960000
 doing that will be apparent shortly
 so I actually hold on let me just

0:10:44.960000 --> 0:10:51.120000
 log and we will just use that payload
 there so in this case that the name

0:10:51.120000 --> 0:11:02.140000
 of the table is select all from accounts
 where username is username and

0:11:02.140000 --> 0:11:06.200000
 password yes it's getting all so we
 just need to say whether his name

0:11:06.200000 --> 0:11:09.680000
 is admin or try and find a match there
 so just to show you that this can

0:11:09.680000 --> 0:11:21.060000
 work union select all from accounts
 where the username is equal to admin

0:11:21.060000 --> 0:11:28.580000
 trying to see if we can get that there
 the number of columns will match

0:11:28.580000 --> 0:11:41.980000
 and for some reason we have something
 very interesting going on here let's

0:11:41.980000 --> 0:11:46.180000
 try and URL and code that just to see
 whether that corrects the white

0:11:46.180000 --> 0:11:57.560000
 space issue okay yeah so that is working
 as expected however the used

0:11:57.560000 --> 0:12:00.840000
 select statements have a different number
 of columns which is interesting

0:12:00.840000 --> 0:12:15.660000
 because this one only has actually four
 columns so union select all from

0:12:15.660000 --> 0:12:21.780000
 or rather in this case this would be
 three yeah so that would not work

0:12:21.780000 --> 0:12:25.840000
 ideally but you get the idea you're
 able to combine the results of two

0:12:25.840000 --> 0:12:29.540000
 different tables in this case there they
 don't match the reason they don't

0:12:29.540000 --> 0:12:34.420000
 match is simple in this case if I listed
 or used this payload here this

0:12:34.420000 --> 0:12:40.780000
 is the user lookup you can see that
 there are three columns so using an

0:12:40.780000 --> 0:12:45.780000
 impastered signature and then I think
 for this one right over here if

0:12:45.780000 --> 0:12:54.160000
 we perform the actual injection or we
 try and view the blog entries here

0:12:54.160000 --> 0:12:58.880000
 I'm just going to go into the proxy and
 port that there and for that there

0:12:58.880000 --> 0:13:02.580000
 we go back in here you can see it's
 one two three but it looks like we

0:13:02.580000 --> 0:13:06.960000
 have the key display that should actually
 work so we go into the repeater

0:13:06.960000 --> 0:13:10.140000
 just going to try this one more time
 and then we have one of few other

0:13:10.140000 --> 0:13:14.120000
 examples like time-based that we'll
 test out as well but we're covering

0:13:14.120000 --> 0:13:22.180000
 a lot of stuff here so union select
 all from accounts where the username

0:13:22.180000 --> 0:13:27.680000
 equals admin we don't actually need
 to have that particular match there

0:13:27.680000 --> 0:13:36.600000
 so just from accounts and we'll send
 this let's see what there is I know

0:13:36.600000 --> 0:13:42.540000
 it's still gonna tell me that the columns
 don't match yeah so different

0:13:42.540000 --> 0:13:46.520000
 number of columns so if we could modify
 the initial one then that would

0:13:46.520000 --> 0:13:51.020000
 work as well but you get the idea so
 that's union-based injection at a

0:13:51.020000 --> 0:13:54.420000
 high level in this case there's no
 real good there's not really a good

0:13:54.420000 --> 0:13:58.520000
 example I can use to showcase that
 I'm just going to disable the proxy

0:13:58.520000 --> 0:14:03.520000
 and there's a couple of others that
 I wanted to try out in that being

0:14:03.520000 --> 0:14:10.940000
 time-based so we can try out the time
-based option using the same using

0:14:10.940000 --> 0:14:16.860000
 the same exercise here so I'll just
 say admin view blog entries and the

0:14:16.860000 --> 0:14:22.820000
 injection point is here so one thing
 that we want to do is we can't really

0:14:22.820000 --> 0:14:27.440000
 monitor the response time so I'll just
 do that again view blog entries

0:14:27.440000 --> 0:14:30.220000
 and we'll send this to the repeater
 because this is the only place we

0:14:30.220000 --> 0:14:34.160000
 will be able to monitor this so this
 is where we can take a look at some

0:14:34.160000 --> 0:14:39.400000
 of those time-based payloads so a good
 example of this is this option

0:14:39.400000 --> 0:14:44.860000
 here or sleep however in the case of
 motility given how it's set up this

0:14:44.860000 --> 0:14:49.780000
 might cause an issue but what we can
 do is I'll just go back into my proxy

0:14:49.780000 --> 0:14:54.340000
 here and we'll just disable intercept
 there if we go into the injection

0:14:54.340000 --> 0:15:00.540000
 and blind SQL injection via timing
 we can use user info as an example

0:15:00.540000 --> 0:15:04.480000
 and actually what I'll do is I'll go
 into the repeater and clear out these

0:15:04.480000 --> 0:15:09.840000
 previous ones here that we had sent
 and now in the proxy we'll just turn

0:15:09.840000 --> 0:15:15.700000
 on intercept and I'll just send in some
 test data here and this is injected

0:15:15.700000 --> 0:15:21.780000
 also via the URL but we'll just do
 it with we'll just do it with burp

0:15:21.780000 --> 0:15:26.080000
 so we'll go into the repeater and we
 know that the username is injectable

0:15:26.080000 --> 0:15:31.260000
 here so we can put one of these payloads
 sorry right over here so you

0:15:31.260000 --> 0:15:37.900000
 know for example single quote or sleep
 for five seconds so this will tell

0:15:37.900000 --> 0:15:42.800000
 it to sleep for five seconds and I've
 sort of explained this here where

0:15:42.800000 --> 0:15:46.640000
 we can specify a delay on this website
 I'm just using it to give you guidance

0:15:46.640000 --> 0:15:51.180000
 here in case it's not clear but these
 two options you can specify a delay

0:15:51.180000 --> 0:15:56.340000
 so in that using the delay option the
 value is formatted as follows and

0:15:56.340000 --> 0:16:01.860000
 you typically use it so to specify time
 delay use the delay argument followed

0:16:01.860000 --> 0:16:07.460000
 by the time to wait time to sleep the
 delay time can be 24 hours this

0:16:07.460000 --> 0:16:12.620000
 delays the execution so I usually prefer
 that not the sleep option so

0:16:12.620000 --> 0:16:18.780000
 the one we can test here that I'm sure
 will probably work we can also

0:16:18.780000 --> 0:16:26.240000
 use the benchmark option but yeah we can
 try the one or pg sleep but that's

0:16:26.240000 --> 0:16:31.300000
 obviously not going to work in this
 case we're dealing with MySQL let

0:16:31.300000 --> 0:16:38.200000
 us try this one here wait for delay
 so five seconds this will need a web

0:16:38.200000 --> 0:16:43.100000
 proxy will require a bit of testing
 so we will just put it in here as

0:16:43.100000 --> 0:16:48.900000
 it is so wait for delay and we'll use
 the pound symbol there so let's

0:16:48.900000 --> 0:16:53.480000
 send it and I want you to pay attention
 to the response time so 14 492

0:16:53.480000 --> 0:16:58.420000
 milliseconds five seconds is 5 000 milliseconds
 so in this case this payload

0:16:58.420000 --> 0:17:05.100000
 is not working so using that time-based
 injection if this was blind we

0:17:05.100000 --> 0:17:09.300000
 would be able to obviously tell whether
 it was indeed working right so

0:17:09.300000 --> 0:17:19.220000
 what we want to do is again same thing
 in here let's see wait for in this

0:17:19.220000 --> 0:17:23.480000
 particular case that doesn't seem like
 it was specified correctly here

0:17:23.480000 --> 0:17:30.460000
 that's interesting so PHP username
 equal to and for some reason let me

0:17:30.460000 --> 0:17:41.960000
 just reverse that here let us try a
 URL and code this okay and let us

0:17:41.960000 --> 0:17:47.720000
 send that there same thing for 80 milliseconds
 nothing changed all right

0:17:47.720000 --> 0:17:52.640000
 so it looks like this payload does not
 work so maybe we can try modifying

0:17:52.640000 --> 0:17:59.760000
 it a little bit so one thing we can try
 modifying here is the escape characters

0:17:59.760000 --> 0:18:05.360000
 I know we don't need these here so we
 can just say wait for delay let's

0:18:05.360000 --> 0:18:12.660000
 send that over so this was even faster
 and we will just say wait for delay

0:18:12.660000 --> 0:18:18.660000
 and we will essentially URL and code
 it there let's send this over same

0:18:18.660000 --> 0:18:23.200000
 thing so in this case we will need
 to try a different payload and now

0:18:23.200000 --> 0:18:27.660000
 you can start to see how useful this
 is the sleep option will work but

0:18:27.660000 --> 0:18:32.640000
 it will cause a crash as you will see
 here so I'll actually do it just

0:18:32.640000 --> 0:18:37.420000
 to show you that it does indeed work
 and we'll go back into the repeater

0:18:37.420000 --> 0:18:45.480000
 and right over here just going to paste
 in our payload so or sleep so

0:18:45.480000 --> 0:18:50.460000
 that's using the or operator there and
 that should work so that's going

0:18:50.460000 --> 0:18:55.480000
 to take actually looks like it injected
 successfully that's very interesting

0:18:55.480000 --> 0:19:00.800000
 let me go ahead here and send this again
 to the repeater and we'll send

0:19:00.800000 --> 0:19:06.060000
 it again this time because sometimes
 that happens so or sleep for five

0:19:06.060000 --> 0:19:14.560000
 seconds and let's send that over in
 this case five fifteen milliseconds

0:19:14.560000 --> 0:19:20.320000
 that doesn't seem to work and the get
 request seems to change even though

0:19:20.320000 --> 0:19:26.480000
 it's get here so what we can try and
 do here is let's try and perform

0:19:26.480000 --> 0:19:32.620000
 the injection here okay not within
 the repeater so we'll say or sleep

0:19:32.620000 --> 0:19:44.980000
 five seconds and we can just send that
 over and in this case it looks

0:19:44.980000 --> 0:19:49.880000
 like it was sent over without any issues
 so let me just turn off the intercept

0:19:49.880000 --> 0:19:58.780000
 here and it will do the same thing
 so or sleep five seconds and we'll

0:19:58.780000 --> 0:20:02.460000
 view the account details all right so
 now it's working it looks like that

0:20:02.460000 --> 0:20:08.780000
 needs to be yeah so that's not passed
 by the URL is being passed server

0:20:08.780000 --> 0:20:12.400000
 side and it's taking longer than five
 seconds the reason that is the case

0:20:12.400000 --> 0:20:17.680000
 is because it's waiting until the next
 select statement so the point is

0:20:17.680000 --> 0:20:22.180000
 we change this to something like a Lexus
 that would still not work what

0:20:22.180000 --> 0:20:27.360000
 we would need to do is let's see if
 we can access this via same thing

0:20:27.360000 --> 0:20:32.320000
 user lookup via Firefox another session
 that should work so now we check

0:20:32.320000 --> 0:20:37.840000
 back here once we make another check
 here so I'll say test and test that

0:20:37.840000 --> 0:20:45.880000
 should work then so I go back in here
 that made the select statement so

0:20:45.880000 --> 0:20:52.100000
 it's still sleeping however if I tried
 to go home or that still work or

0:20:52.100000 --> 0:20:57.240000
 that's still tied here so yeah that's
 still tied to this particular session

0:20:57.240000 --> 0:21:02.500000
 so we go back into Firefox so you know
 sort of using another user here

0:21:02.500000 --> 0:21:08.940000
 and I hit again actually we're using
 a different one so blind SQL user

0:21:08.940000 --> 0:21:15.100000
 info there we are perform this here
 there we go if we go back in here

0:21:15.100000 --> 0:21:19.620000
 that should be good so view the account
 details yeah so I think it's caused

0:21:19.620000 --> 0:21:23.100000
 an issue with this particular session
 even though I know that intercept

0:21:23.100000 --> 0:21:27.100000
 is set but there we are we know it's
 working because for this particular

0:21:27.100000 --> 0:21:32.400000
 select it is obviously taken more than
 five seconds but it has been executed

0:21:32.400000 --> 0:21:37.380000
 successfully we can also try a few
 others and then we'll wrap up this

0:21:37.380000 --> 0:21:42.780000
 session here what we can do is the
 other payload that you can try and

0:21:42.780000 --> 0:21:49.840000
 run is the ability to run a benchmark
 so the one specifically I wanted

0:21:49.840000 --> 0:22:00.320000
 to show you here was this one right
 over here let's see let's try and

0:22:00.320000 --> 0:22:10.920000
 run we can run a benchmark that usually
 takes time and that will prove

0:22:10.920000 --> 0:22:17.020000
 it definitively almost so we can run
 this one here and we'll just go back

0:22:17.020000 --> 0:22:22.620000
 in here and this for some reason is
 still loading I think if we were to

0:22:22.620000 --> 0:22:30.160000
 duplicate that and sort of clear our
 cookies no cookies here let's see

0:22:30.160000 --> 0:22:37.660000
 cookies in use let's remove all of
 them done and let's refresh this up

0:22:37.660000 --> 0:22:41.700000
 there we are so now it's working so
 yeah it's tied to each unique select

0:22:41.700000 --> 0:22:45.480000
 request which is why the time delay we
 know it's working but in this case

0:22:45.480000 --> 0:22:52.120000
 we'll just try it again injection via
 timing and user info and we'll just

0:22:52.120000 --> 0:22:56.680000
 paste in that payload that I just copied
 over and this will take a few

0:22:56.680000 --> 0:23:04.600000
 seconds hold on that order by one sleep
 benchmark that should work although

0:23:04.600000 --> 0:23:10.600000
 the reason why it may not be working
 is fairly simple the reason it may

0:23:10.600000 --> 0:23:14.340000
 not be working is because of the fact
 we need we may need to play around

0:23:14.340000 --> 0:23:19.260000
 with the URL so I'll just say test and
 we'll put it in here what we just

0:23:19.260000 --> 0:23:26.480000
 copied and just want to go back in
 here put the single quote there and

0:23:26.480000 --> 0:23:34.780000
 then we would need to URL encode this
 and then we hit forward and yeah

0:23:34.780000 --> 0:23:37.960000
 so in this case that doesn't look like
 it's working sort of by one sleep

0:23:37.960000 --> 0:23:41.400000
 five benchmark the benchmark should work
 in and of itself I'm just trying

0:23:41.400000 --> 0:23:46.900000
 to find that original one here without
 the sleep option yeah so there

0:23:46.900000 --> 0:23:52.000000
 we are the or benchmark option this
 should work so if we go back in here

0:23:52.000000 --> 0:23:57.460000
 and I'll just make another request
 there we are and I'll paste this in

0:23:57.460000 --> 0:24:11.840000
 here so or and then we put in the that
 there you can see that took a while

0:24:11.840000 --> 0:24:19.640000
 just going to make another request
 here send this to the repeat I just

0:24:19.640000 --> 0:24:25.580000
 want to verify just to see what happens
 so we send the typical request

0:24:25.580000 --> 0:24:31.280000
 the responses are around 500 milliseconds
 and then in here we can say

0:24:31.280000 --> 0:24:36.920000
 put that in there so we can increase
 this to something like you know let's

0:24:36.920000 --> 0:24:42.880000
 increase that number just to see this
 change and let's put in this found

0:24:42.880000 --> 0:24:50.500000
 symbol there in this case that was actually
 faster let's send this back

0:24:50.500000 --> 0:24:56.820000
 here and let's try and URL encode this
 so URL encode this actually might

0:24:56.820000 --> 0:25:04.300000
 be more applicable to the blind injection
 there so the one that we had

0:25:04.300000 --> 0:25:07.300000
 actually previously run let's actually
 try that out so I'm just going

0:25:07.300000 --> 0:25:13.540000
 to go in here and even though we'll
 be covering time-based there is I

0:25:13.540000 --> 0:25:17.980000
 know that this does indeed work it's
 just the correct exercise so view

0:25:17.980000 --> 0:25:23.800000
 someone's blog I know that that particular
 payload should indeed work

0:25:23.800000 --> 0:25:28.500000
 so we'll just say intercept view the
 blog entry is there and we'll send

0:25:28.500000 --> 0:25:33.160000
 this to the repeater in the repeater
 we will just see what the response

0:25:33.160000 --> 0:25:38.540000
 time is like so what we were expecting
 pretty much and here we have quite

0:25:38.540000 --> 0:25:44.020000
 a large one could we selected everything
 and in this particular case all

0:25:44.020000 --> 0:25:48.340000
 we need to do is just add the single
 quotes there and let's try it without

0:25:48.340000 --> 0:25:53.460000
 this so I'm just going to copy this
 in case I require it there we are

0:25:53.460000 --> 0:25:58.060000
 because this usually changes the request
 sometimes or the order that took

0:25:58.060000 --> 0:26:07.260000
 a bit of time let's add fantastic so
 this actually shows the time-based

0:26:07.260000 --> 0:26:11.240000
 injection in that we've performed a
 calculation is not limited to just

0:26:11.240000 --> 0:26:16.840000
 delays or sleep times but actually this
 is taking quite a while benchmark

0:26:16.840000 --> 0:26:22.600000
 that was quite a large benchmark so
 we'll see what how long this takes

0:26:22.600000 --> 0:26:30.900000
 there we are so 20,953 milliseconds
 let's try reduce this to maybe we

0:26:30.900000 --> 0:26:36.560000
 will just reduce it by 1 0 there or actually
 hold on we'll just say change

0:26:36.560000 --> 0:26:41.920000
 this to something like 50 1 2 3 3 there
 we are let's send that so that's

0:26:41.920000 --> 0:26:48.520000
 the original one was 20 or fit pretty
 much 21 000 milliseconds in this

0:26:48.520000 --> 0:26:55.060000
 particular case looks like now that is
 not working um let's increase that

0:26:55.060000 --> 0:26:59.760000
 by quite a margin there we may also
 have an issue with the cookies but

0:26:59.760000 --> 0:27:03.360000
 yeah that seems to be working so this confirms
 that the injection is successful

0:27:03.360000 --> 0:27:07.300000
 even though the output is not really
 tied to the payload or vice versa

0:27:07.300000 --> 0:27:12.680000
 so yeah that is how to identify SQL
 injection vulnerabilities manually

0:27:12.680000 --> 0:27:19.780000
 and that concludes the practical demonstration
 side of this video all

0:27:19.780000 --> 0:27:24.660000
 right so that was a quite a lot of manual
 testing hopefully you've learned

0:27:24.660000 --> 0:27:29.320000
 a lot I really like using OAS Motility
 now that we've taken a look at

0:27:29.320000 --> 0:27:32.860000
 how to identify these vulnerabilities
 manually and this will come in handy

0:27:32.860000 --> 0:27:38.020000
 when we'll be exploring these vulnerabilities
 in real-world web applications

0:27:38.020000 --> 0:27:45.660000
 and now I want to turn our attention
 to how we can semi automate this

0:27:45.660000 --> 0:27:51.580000
 process with a tool or a proxy like OAS
 PZAP so that's what we'll be doing

0:27:51.580000 --> 0:27:56.100000
 in the next video so with that being
 said I'll be seeing you in the next