WEBVTT

0:00:12.520000 --> 0:00:16.320000
 Exploiting error-based SQL
 injection vulnerabilities.

0:00:16.320000 --> 0:00:21.240000
 So here we are, the first exploitation
 section of this course, even though

0:00:21.240000 --> 0:00:23.240000
 we've already covered that
 in the previous section.

0:00:23.240000 --> 0:00:28.780000
 But we're going to be starting off by
 taking a look at in-band SQL injection

0:00:28.780000 --> 0:00:30.480000
 vulnerabilities.

0:00:30.480000 --> 0:00:34.300000
 And the first video within this section
 is going to be focused on the

0:00:34.300000 --> 0:00:38.140000
 first subtype of in-band SQL
 injection vulnerabilities.

0:00:38.140000 --> 0:00:41.500000
 And that is error-based SQL
 injection vulnerabilities.

0:00:41.500000 --> 0:00:45.560000
 Now we've already taken a look at how
 to identify and exploit error-based

0:00:45.560000 --> 0:00:48.520000
 SQL injection vulnerabilities
 in the previous section.

0:00:48.520000 --> 0:00:53.460000
 But that was of course more so focused
 on the methodologies and the processes

0:00:53.460000 --> 0:00:59.180000
 behind that. And how to do it manually
 or how to identify SQL injection

0:00:59.180000 --> 0:01:00.600000
 vulnerabilities manually.

0:01:00.600000 --> 0:01:05.240000
 Now to go about exploiting them manually
 and both through the use of a

0:01:05.240000 --> 0:01:09.780000
 web proxies, whether it
 be BIRPSWET or OASPZAP.

0:01:09.780000 --> 0:01:13.560000
 So we're now going to turn our attention
 to a much more realistic approach

0:01:13.560000 --> 0:01:17.260000
 where we will be focusing on
 real world web applications.

0:01:17.260000 --> 0:01:19.740000
 And that's what we'll be
 doing in this video.

0:01:19.740000 --> 0:01:25.780000
 However, before we do that, we need to go
 through some theoretical explanations

0:01:25.780000 --> 0:01:31.200000
 or demonstrations so that I can highlight
 firstly where we are with regards

0:01:31.200000 --> 0:01:35.400000
 to the SQL injection vulnerabilities
 types and subtypes.

0:01:35.400000 --> 0:01:39.380000
 And I'll introduce you once again to error
-based SQL injection vulnerabilities

0:01:39.380000 --> 0:01:44.760000
 and sort of outline a general identification
 and exploitation methodology

0:01:44.760000 --> 0:01:50.380000
 that you can follow tailored towards error
-based SQL injection vulnerabilities.

0:01:50.380000 --> 0:01:54.880000
 So to begin with, we'll revisit or
 we are going to revisit as you can

0:01:54.880000 --> 0:02:01.000000
 see here the SQL injection types and
 subtypes hierarchy tree that I had

0:02:01.000000 --> 0:02:05.160000
 introduced to you or that I had shown
 you early on in this course where

0:02:05.160000 --> 0:02:10.520000
 we essentially have the SQL injection
 vulnerabilities tree that defines

0:02:10.520000 --> 0:02:15.260000
 the various types and subtypes of SQL
 injection vulnerabilities and I've

0:02:15.260000 --> 0:02:16.700000
 already introduced you to them.

0:02:16.700000 --> 0:02:18.640000
 So we're starting off with
 in-band SQL injection.

0:02:18.640000 --> 0:02:20.600000
 So that's this section.

0:02:20.600000 --> 0:02:23.960000
 And to begin with, in this video, we're
 taking a look at error-based SQL

0:02:23.960000 --> 0:02:28.060000
 injection. In the next video, we'll take
 a look at union-based SQL injection

0:02:28.060000 --> 0:02:32.480000
 and then in the next section, we'll
 take a look at blind SQL injection

0:02:32.480000 --> 0:02:37.620000
 subtypes. So Boolean
-based and time-based.

0:02:37.620000 --> 0:02:40.180000
 And as I mentioned earlier in this course,
 we're not going to be exploring

0:02:40.180000 --> 0:02:44.400000
 out of band SQL injection, even though
 we'll be exploring maybe a little

0:02:44.400000 --> 0:02:48.080000
 bit of this in this video
 and this demonstration.

0:02:48.080000 --> 0:02:51.680000
 So this video will have a live
 lab associated with it.

0:02:51.680000 --> 0:02:55.940000
 We'll get to the practical section at
 the end of the slides and the main

0:02:55.940000 --> 0:03:02.460000
 differentiating factor between the exploitation
 sections of this course

0:03:02.460000 --> 0:03:05.720000
 and the actual section where we are focused
 on finding SQL injection vulnerabilities

0:03:05.720000 --> 0:03:10.640000
 is that we will be utilizing a real
-world web application as opposed to

0:03:10.640000 --> 0:03:12.480000
 something like OASP-MOTILIDAY.

0:03:12.480000 --> 0:03:16.880000
 So this will sort of give you a real feel
 as to how you'd go about identifying

0:03:16.880000 --> 0:03:20.660000
 and exploiting in this case an error
-based SQL injection vulnerability

0:03:20.660000 --> 0:03:24.940000
 in the wild. So with that being said, this
 is where we are sort of highlighted

0:03:24.940000 --> 0:03:27.880000
 it here. So you can see where we are
 at this point and we'll be following

0:03:27.880000 --> 0:03:29.480000
 this methodology.

0:03:29.480000 --> 0:03:32.920000
 So we're taking a look at
 error-based SQL injection.

0:03:32.920000 --> 0:03:36.220000
 Now, of course, before we take a look
 at one of the subtypes, which in

0:03:36.220000 --> 0:03:39.480000
 this case is error-based SQL injection,
 we need to get an understanding

0:03:39.480000 --> 0:03:43.920000
 of the primary type or category under
 which error-based SQL injection

0:03:43.920000 --> 0:03:46.660000
 falls and that is in-band SQL injection.

0:03:46.660000 --> 0:03:50.260000
 So I've already gone through this,
 but I thought it's important to go

0:03:50.260000 --> 0:03:54.800000
 through it again so that we don't skip
 over anything or in case you've

0:03:54.800000 --> 0:03:57.280000
 forgotten this might be a good refresher.


0:03:57.280000 --> 0:03:59.820000
 So what is in-band SQL injection?

0:03:59.820000 --> 0:04:03.960000
 Well, in-band SQL injection is the most
 common type of SQL injection attack

0:04:03.960000 --> 0:04:08.140000
 and it occurs when an attacker utilizes
 the same communication channel

0:04:08.140000 --> 0:04:11.760000
 to send the attack and receive
 the results, right?

0:04:11.760000 --> 0:04:15.440000
 Or the actual results of their
 SQL query that they injected.

0:04:15.440000 --> 0:04:18.940000
 In other words, what this means is that
 the attacker injects the malicious

0:04:18.940000 --> 0:04:21.080000
 SQL code or query or payload.

0:04:21.080000 --> 0:04:23.160000
 Again, I use those terms interchangeably.


0:04:23.160000 --> 0:04:28.060000
 So the attacker injects malicious SQL
 code into the web application and

0:04:28.060000 --> 0:04:33.020000
 then receives the results of the SQL
 code that was injected through the

0:04:33.020000 --> 0:04:35.460000
 same channel that was used
 to submit the code.

0:04:35.460000 --> 0:04:38.260000
 This will typically be the
 web application itself.

0:04:38.260000 --> 0:04:42.760000
 So when we talk about in-band, the key
 thing to take note of is that the

0:04:42.760000 --> 0:04:46.580000
 injection and the return of the results
 is done through the same communication

0:04:46.580000 --> 0:04:50.240000
 channel. And when I refer to the communication
 channel, I'm typically

0:04:50.240000 --> 0:04:51.780000
 referring to the web application.

0:04:51.780000 --> 0:04:56.520000
 So if you're on a particular web page
 or a page on the web application

0:04:56.520000 --> 0:05:01.840000
 and you find an application input and
 you essentially inject your SQL

0:05:01.840000 --> 0:05:07.980000
 query in there, the whole idea behind
 in-band SQL injection is that the

0:05:07.980000 --> 0:05:12.380000
 results of the SQL query that you injected
 will be returned on that page.

0:05:12.380000 --> 0:05:16.500000
 So in the case of error-based injection,
 we would, for example, use the

0:05:16.500000 --> 0:05:22.320000
 single quote exploit where we put a
 single quote to sort of invoke an

0:05:22.320000 --> 0:05:28.860000
 error. So if executed by the database,
 the result of that execution will

0:05:28.860000 --> 0:05:32.380000
 essentially prompt the web application
 to tell you that, hey, you have

0:05:32.380000 --> 0:05:37.000000
 an issue with your SQL query and that
 sort of confirms the fact that an

0:05:37.000000 --> 0:05:40.300000
 error-based SQL injection
 vulnerability exists.

0:05:40.300000 --> 0:05:44.900000
 Now, in-band SQL injection attacks are
 quite dangerous, obviously, because

0:05:44.900000 --> 0:05:50.660000
 not only because of how they operate
 in that you're utilizing a single

0:05:50.660000 --> 0:05:55.540000
 communication channel, but you can also
 very easily use it to steal sensitive

0:05:55.540000 --> 0:05:59.820000
 information, modify or delete data, or
 take over an entire web application

0:05:59.820000 --> 0:06:01.680000
 or even the entire server.

0:06:01.680000 --> 0:06:05.600000
 And we'll talk about how to gain access
 to data that is stored in the

0:06:05.600000 --> 0:06:09.700000
 database by leveraging, even in this
 case, an error-based SQL injection

0:06:09.700000 --> 0:06:13.820000
 vulnerability. So sort of going over
 the diagram that, again, I had used

0:06:13.820000 --> 0:06:19.180000
 in the intersections of this course, I
 want to use the in-band SQL injection

0:06:19.180000 --> 0:06:23.740000
 diagram here. So again, we have the
 attacker or the pen test or the bug

0:06:23.740000 --> 0:06:27.640000
 bounty hunter, which is typically going
 to be you and you are performing

0:06:27.640000 --> 0:06:31.440000
 a security assessment on a web application
 and you're connecting to it.

0:06:31.440000 --> 0:06:32.960000
 So we're going to be able to do
 it via the internet, right?

0:06:32.960000 --> 0:06:36.480000
 Now pay attention to these directional
 arrows and where they're going

0:06:36.480000 --> 0:06:38.040000
 and where they're coming from.

0:06:38.040000 --> 0:06:42.080000
 So during an in-band SQL injection
 attack, the penetration tester will

0:06:42.080000 --> 0:06:45.940000
 find a way to ask the web application
 for desired information.

0:06:45.940000 --> 0:06:50.840000
 So in this case, we threw an HTTP request
 or firstly, we find an application

0:06:50.840000 --> 0:06:56.920000
 input that will interact with the
 database based on its nature.

0:06:56.920000 --> 0:07:00.700000
 Secondly, there shouldn't
 be any input validation.

0:07:00.700000 --> 0:07:04.920000
 And so what we do is we find that injectable
 application input or a parameter

0:07:04.920000 --> 0:07:11.340000
 that is injectable and we inject our
 SQL query or payload or your code.

0:07:11.340000 --> 0:07:15.980000
 And in this case, the example I've
 used here is SQL query to list user

0:07:15.980000 --> 0:07:17.600000
 accounts, right?

0:07:17.600000 --> 0:07:19.280000
 Within a particular table.

0:07:19.280000 --> 0:07:20.780000
 So we send that over.

0:07:20.780000 --> 0:07:22.660000
 It's injected successfully.

0:07:22.660000 --> 0:07:27.200000
 The web server treats it as regular data
 because there's no input validation

0:07:27.200000 --> 0:07:32.020000
 and makes essentially a request or an
 SQL query to the database saying,

0:07:32.020000 --> 0:07:36.700000
 Hey, can you verify whether this information
 exists again using a legitimate

0:07:36.700000 --> 0:07:39.540000
 query and then the appended
 injected queries.

0:07:39.540000 --> 0:07:44.640000
 What is executed by the database by virtue
 of your injection as we explored

0:07:44.640000 --> 0:07:49.840000
 in the previous section as well as the
 SQL, a primary or fundamental section

0:07:49.840000 --> 0:07:53.760000
 of this course. So the database doesn't
 know what is legitimate and what

0:07:53.760000 --> 0:07:56.400000
 is not. It's been given
 an SQL query to execute.

0:07:56.400000 --> 0:08:03.400000
 And if it's syntactically valid, then
 it will essentially process the

0:08:03.400000 --> 0:08:05.540000
 SQL query and return the data.

0:08:05.540000 --> 0:08:09.900000
 The web application receives the data
 and will display the results on

0:08:09.900000 --> 0:08:14.280000
 typically the page where the
 injection was performed.

0:08:14.280000 --> 0:08:19.040000
 So in this case, you can see the injected
 SQL query was asking to list

0:08:19.040000 --> 0:08:20.660000
 user accounts from a particular table.

0:08:20.660000 --> 0:08:23.300000
 That is all done successfully.

0:08:23.300000 --> 0:08:26.620000
 And the web application returns with
 the results from the database, which

0:08:26.620000 --> 0:08:30.200000
 in this case are the user accounts and
 the examples here are admin, John

0:08:30.200000 --> 0:08:34.420000
 and Mike. So that brings us to error
 based SQL injection, right?

0:08:34.420000 --> 0:08:38.920000
 So error based SQL injection is a technique
 used by attackers to exploit

0:08:38.920000 --> 0:08:42.080000
 SQL injection vulnerabilities in
 web applications, obviously.

0:08:42.080000 --> 0:08:47.360000
 And it relies on intentionally causing
 database errors and using the error

0:08:47.360000 --> 0:08:51.960000
 messages returned by the database to extract
 information or gain unauthorized

0:08:51.960000 --> 0:08:54.720000
 access to the applications database.

0:08:54.720000 --> 0:08:57.900000
 So the error message, the reason we
 do this is because the error message

0:08:57.900000 --> 0:09:02.540000
 can contain valuable information about
 the database schema or the contents

0:09:02.540000 --> 0:09:06.860000
 of the database itself, as we'll see
 shortly, which the attacker can then

0:09:06.860000 --> 0:09:09.140000
 use to further exploit the vulnerability.


0:09:09.140000 --> 0:09:10.800000
 That's something we'll explore as well.

0:09:10.800000 --> 0:09:14.480000
 So the process of identifying error
 based SQL injection vulnerabilities

0:09:14.480000 --> 0:09:18.720000
 will involve testing the web application
 in order to determine if it is

0:09:18.720000 --> 0:09:20.840000
 susceptible to this type of attack.

0:09:20.840000 --> 0:09:25.300000
 And we explored the process of identifying
 error based SQL injection vulnerabilities.

0:09:25.300000 --> 0:09:29.580000
 So the key thing here, going back to
 in band and how this relates to error

0:09:29.580000 --> 0:09:33.300000
 based is that when we talk about error
 based SQL injection vulnerabilities

0:09:33.300000 --> 0:09:37.120000
 or the exploitation of error based
 SQL injection vulnerabilities, this

0:09:37.120000 --> 0:09:42.200000
 is an in band SQL injection attack
 or vulnerability, which means that

0:09:42.200000 --> 0:09:47.660000
 we're using that functionality, that
 in band functionality to essentially

0:09:47.660000 --> 0:09:54.180000
 inject a particular special character
 or payload or an SQL code or query

0:09:54.180000 --> 0:09:57.000000
 that will invoke an error, right?

0:09:57.000000 --> 0:10:01.000000
 And the objective here is that the web
 application will return that error

0:10:01.000000 --> 0:10:04.800000
 and that error typically contains useful
 information about the backend

0:10:04.800000 --> 0:10:05.820000
 database, right?

0:10:05.820000 --> 0:10:09.980000
 So how do you go about identifying and
 exploiting an error based SQL injection

0:10:09.980000 --> 0:10:11.540000
 vulnerability in the wild?

0:10:11.540000 --> 0:10:15.000000
 Well, there's a really cool methodology
 that I put together that I think

0:10:15.000000 --> 0:10:16.100000
 works really well.

0:10:16.100000 --> 0:10:21.100000
 So number one, you need to identify
 an application input that doesn't

0:10:21.100000 --> 0:10:25.060000
 have any input validation and one that
 interacts with the database by

0:10:25.060000 --> 0:10:28.280000
 the nature of how it works, right?

0:10:28.280000 --> 0:10:29.900000
 And we talked about that
 in the previous section.

0:10:29.900000 --> 0:10:32.620000
 A good example of this is a login form.

0:10:32.620000 --> 0:10:37.000000
 So what you're supposed to do is identify
 the injectable application input

0:10:37.000000 --> 0:10:40.780000
 or in this case, the vulnerable parameter,
 the parameter that's vulnerable

0:10:40.780000 --> 0:10:42.780000
 to injection, right?

0:10:42.780000 --> 0:10:46.760000
 And this involves finding a parameter in
 the web application that is vulnerable

0:10:46.760000 --> 0:10:53.140000
 to SQL injection, typically through the
 user input fields, URL parameters

0:10:53.140000 --> 0:10:58.540000
 or form inputs. What you do next
 is to inject malicious SQL code.

0:10:58.540000 --> 0:11:02.440000
 So you need to craft a payload that includes
 SQL statements that are designed

0:11:02.440000 --> 0:11:04.920000
 to trigger a database error.

0:11:04.920000 --> 0:11:09.480000
 This can involve appending invalid SQL syntax
 like a single quote or manipulating

0:11:09.480000 --> 0:11:11.480000
 existing queries.

0:11:11.480000 --> 0:11:15.120000
 And we can talk a little bit about that
 when we are exploring union based

0:11:15.120000 --> 0:11:16.520000
 SQL injection, right?

0:11:16.520000 --> 0:11:20.200000
 The third step is to observe
 the error messages, right?

0:11:20.200000 --> 0:11:23.740000
 So your job here is to submit the payload
 or inject the payload to the

0:11:23.740000 --> 0:11:27.340000
 vulnerable parameter and then observe
 the error message returned by the

0:11:27.340000 --> 0:11:31.220000
 database. And because it's an in band
 SQL injection vulnerability, it's

0:11:31.220000 --> 0:11:36.480000
 going to do that via the same page
 typically that you injected the SQL

0:11:36.480000 --> 0:11:41.560000
 query into or, you know, the same page
 that has the injectable parameter

0:11:41.560000 --> 0:11:45.600000
 or has the application input that
 is vulnerable to SQL injection.

0:11:45.600000 --> 0:11:49.640000
 And the key thing we're looking for
 here is useful information about the

0:11:49.640000 --> 0:11:53.940000
 backend database, which can also delve
 into, you know, enumeration of

0:11:53.940000 --> 0:11:57.880000
 data within the database, and that can
 be facilitated through tools like

0:11:57.880000 --> 0:12:01.600000
 SQL map, which will actually be exploring
 in this video in the practical

0:12:01.600000 --> 0:12:06.820000
 side. Once you've done that, you
 can choose to extract data.

0:12:06.820000 --> 0:12:09.780000
 Now, this is typically not
 needed in a bug bounty.

0:12:09.780000 --> 0:12:12.800000
 When you're doing bug bounty hunting
 or in a standard web application

0:12:12.800000 --> 0:12:16.220000
 pen test, however, it may be requested.

0:12:16.220000 --> 0:12:19.340000
 So when you're proof of concept, as
 long as you prove that an injection

0:12:19.340000 --> 0:12:22.100000
 vulnerability exists,
 that's pretty much it.

0:12:22.100000 --> 0:12:26.320000
 But you may be asked to go a step further
 to essentially prove the severity

0:12:26.320000 --> 0:12:28.520000
 of the SQL injection vulnerability.

0:12:28.520000 --> 0:12:32.080000
 Essentially, what companies will ask
 you to do is to, is they'll say,

0:12:32.080000 --> 0:12:36.100000
 okay, once you've identified the SQL
 injection vulnerability, can you

0:12:36.100000 --> 0:12:41.060000
 please show us what data you can access
 via or by leveraging that SQL

0:12:41.060000 --> 0:12:42.420000
 injection vulnerability.

0:12:42.420000 --> 0:12:46.940000
 So your job here at this point is to modify
 the payload to extract specific

0:12:46.940000 --> 0:12:50.300000
 information from the database by
 leveraging the error messages.

0:12:50.300000 --> 0:12:55.260000
 So this can include retrieving usenames,
 passwords, or the sensitive data

0:12:55.260000 --> 0:12:59.020000
 that's stored in the database, and I've
 already sort of explained that.

0:12:59.020000 --> 0:13:02.380000
 And then, of course, you know, that
 ties into the final one, which is

0:13:02.380000 --> 0:13:06.360000
 exploiting the information gathered
 through the error base SQL injection

0:13:06.360000 --> 0:13:09.780000
 vulnerability or attack to further
 exploit the application.

0:13:09.780000 --> 0:13:14.240000
 So, you know, a good example of this
 is when you perform the extraction

0:13:14.240000 --> 0:13:19.640000
 of data, you may choose to dump the users,
 the users or the accounts table,

0:13:19.640000 --> 0:13:25.060000
 for example, within the database and
 get access to user accounts on that

0:13:25.060000 --> 0:13:26.180000
 web application.

0:13:26.180000 --> 0:13:29.320000
 And, you know, in some cases, the passwords
 may be unencrypted or they

0:13:29.320000 --> 0:13:33.840000
 may be encrypted using a weak hashing
 algorithm like MD 5 that can easily

0:13:33.840000 --> 0:13:38.400000
 be cracked. The point is you use the
 data within the database to further

0:13:38.400000 --> 0:13:42.580000
 your access or your exploitation of
 the web application as a whole.

0:13:42.580000 --> 0:13:45.880000
 So imagine if you gain access to the admin
 credentials for the web application

0:13:45.880000 --> 0:13:49.560000
 and you log in as the actual
 admin of the website.

0:13:49.560000 --> 0:13:53.580000
 Well, you now pretty much own the website
 and from that point on, you

0:13:53.580000 --> 0:13:59.500000
 can, you know, you can increase your
 scope of the attack much further.

0:13:59.500000 --> 0:14:03.540000
 And, of course, I'm going to use the
 diagram here to sort of illustrate

0:14:03.540000 --> 0:14:05.580000
 error base SQL injection.

0:14:05.580000 --> 0:14:10.380000
 So the, you know, using the previous example
 as a guide, we have the attacker,

0:14:10.380000 --> 0:14:13.980000
 which is you, and we have the web application,
 which consists of the web

0:14:13.980000 --> 0:14:15.420000
 server and the database.

0:14:15.420000 --> 0:14:19.520000
 And the point is you want to find the
 application input that is vulnerable

0:14:19.520000 --> 0:14:22.340000
 to injection or you're performing
 your testing.

0:14:22.340000 --> 0:14:27.720000
 You, you know, you inject a SQL payload
 that will trigger an error, right?

0:14:27.720000 --> 0:14:29.120000
 And that is sent over.

0:14:29.120000 --> 0:14:32.700000
 The web application does not have any
 input validation, which means the

0:14:32.700000 --> 0:14:34.380000
 request is sent to the database.

0:14:34.380000 --> 0:14:39.200000
 The database sees the SQL query and
 obviously identifies the error.

0:14:39.200000 --> 0:14:42.720000
 And it says, hey, it responds to the web
 application by saying, hey, there's

0:14:42.720000 --> 0:14:46.860000
 an error here. And the web application
 will typically return that error

0:14:46.860000 --> 0:14:51.980000
 telling you, depending on the DBMS
 being used, whether it's MySQL or a

0:14:51.980000 --> 0:14:55.200000
 database. Or something like postgreSQL,
 as we explored in the previous

0:14:55.200000 --> 0:15:01.140000
 section, specific DBMS will have their
 own error messages that, you know,

0:15:01.140000 --> 0:15:05.180000
 will tell you what database
 is, what DBMS is being used.

0:15:05.180000 --> 0:15:10.180000
 So, for example, is it MySQL postgreSQL,
 Microsoft SQL database server,

0:15:10.180000 --> 0:15:14.980000
 etc. And that firstly confirms that
 the injection vulnerability exists.

0:15:14.980000 --> 0:15:16.380000
 And you can then use that.

0:15:16.380000 --> 0:15:21.280000
 You can use error based injection to
 identify or learn more about the

0:15:21.280000 --> 0:15:27.880000
 backend database and even extract data
 and, you know, essentially follow

0:15:27.880000 --> 0:15:31.380000
 through with your attack or the exploitation
 of the vulnerability.

0:15:31.380000 --> 0:15:33.380000
 So that brings us to the actual demo.

0:15:33.380000 --> 0:15:38.080000
 So as I said, in this video has a
 lab environment attached to it.

0:15:38.080000 --> 0:15:41.600000
 Now, this lab environment will provide
 you with access to a real world

0:15:41.600000 --> 0:15:43.160000
 web application.

0:15:43.160000 --> 0:15:46.040000
 And you will require your
 own calilinic system.

0:15:46.040000 --> 0:15:50.020000
 So this lab does not provide you with
 a calilinic system, which means

0:15:50.020000 --> 0:15:51.080000
 you need to have yours.

0:15:51.080000 --> 0:15:55.160000
 I'll be walking you through how to set
 up or how to install tools if they

0:15:55.160000 --> 0:15:57.300000
 are required, but just keep that in mind.


0:15:57.300000 --> 0:16:01.580000
 So you can choose to go through this
 video after you've gone through the

0:16:01.580000 --> 0:16:05.120000
 lab or you can choose to go through
 the walkthrough section after you've

0:16:05.120000 --> 0:16:08.280000
 gone through the lab yourself, or you
 can go through it with me or watch

0:16:08.280000 --> 0:16:10.700000
 the video first and then
 go through it after.

0:16:10.700000 --> 0:16:15.160000
 Whatever the case, the final point I'll
 say here is that you don't need

0:16:15.160000 --> 0:16:17.820000
 to follow my exploitation methodology.

0:16:17.820000 --> 0:16:21.060000
 I'm just going to go through it as
 I typically would when identifying

0:16:21.060000 --> 0:16:24.560000
 an exploiting error based SQL
 injection vulnerabilities.

0:16:24.560000 --> 0:16:28.200000
 With that being said, let me switch
 over into my own calilinic VM.

0:16:28.200000 --> 0:16:31.460000
 And once you start up the lab, just
 copy the URL and you should be able

0:16:31.460000 --> 0:16:32.580000
 to access it via the internet.

0:16:32.580000 --> 0:16:36.540000
 So let me switch over and
 we can get started.

0:16:36.540000 --> 0:16:42.640000
 All right. So I am back within my own
 calilinic VM and I've copied the

0:16:42.640000 --> 0:16:46.740000
 URL that the lab has provided me with
 and we're going to be utilizing

0:16:46.740000 --> 0:16:49.660000
 a web proxy like Burbsweet.

0:16:49.660000 --> 0:16:50.960000
 You can use OASPZAP.

0:16:50.960000 --> 0:16:52.500000
 It's pretty much the same.

0:16:52.500000 --> 0:16:55.940000
 We're not going to be using any specific
 features within them like the

0:16:55.940000 --> 0:17:00.920000
 OASPZAP fuzzer or the payloads, but let's
 start Burp up here and I'm going

0:17:00.920000 --> 0:17:04.600000
 to utilize the Burp browser just so
 that I don't have to, you know, go

0:17:04.600000 --> 0:17:09.240000
 through the process of configuring my
 proxy within Firefox or my personal

0:17:09.240000 --> 0:17:13.580000
 browser here. So I'm going to
 proxy and open the browser.

0:17:13.580000 --> 0:17:16.860000
 And once this opens up, I'll
 just paste in the link here.

0:17:16.860000 --> 0:17:20.320000
 There we are. So you'll get
 a similar sort of a URL.

0:17:20.320000 --> 0:17:24.140000
 Yours will be different, but I'll
 just disable intercept for now.

0:17:24.140000 --> 0:17:26.000000
 And the web application is going to load.


0:17:26.000000 --> 0:17:28.000000
 And here is the one.

0:17:28.000000 --> 0:17:31.700000
 This is the web application that we need
 to that we're going to be targeting.

0:17:31.700000 --> 0:17:36.640000
 So this web application is vulnerable
 to different types of SQL injection

0:17:36.640000 --> 0:17:40.640000
 vulnerabilities, but the primary
 one is error based, right?

0:17:40.640000 --> 0:17:45.420000
 And the first thing as you remember
 is we need to identify application

0:17:45.420000 --> 0:17:47.640000
 inputs. Now we'll do this manually.

0:17:47.640000 --> 0:17:49.280000
 And again, I'm using my own methodology.

0:17:49.280000 --> 0:17:52.540000
 Hopefully you're able to
 learn by following along.

0:17:52.540000 --> 0:17:57.220000
 And hopefully my screen is zoomed in
 to the extent or to a degree where

0:17:57.220000 --> 0:17:59.180000
 you can see everything, but there we are.


0:17:59.180000 --> 0:18:03.740000
 You can see that we have a search bar
 here, which is always a great starting

0:18:03.740000 --> 0:18:08.340000
 point. We don't really know much
 about the web application.

0:18:08.340000 --> 0:18:13.420000
 If we view the web, the source here,
 we can see that just by taking a

0:18:13.420000 --> 0:18:18.000000
 look at it, if we just explore it a
 little bit here, it looks like it

0:18:18.000000 --> 0:18:20.360000
 is a PHP based web application.

0:18:20.360000 --> 0:18:23.820000
 So there's a good chance that it's running
 on Linux typically, although

0:18:23.820000 --> 0:18:33.480000
 we still need to perform a little
 bit more enumeration.

0:18:33.480000 --> 0:18:37.980000
 So we're trying to identify more about
 the actual web application and

0:18:37.980000 --> 0:18:42.500000
 the web server. So in this case, if
 we try and find the robots.txt file,

0:18:42.500000 --> 0:18:47.100000
 we agree with this default Apache banner,
 which tells us that we are running

0:18:47.100000 --> 0:18:52.320000
 on Linux. So we know that it's
 Linux is the underlying server.

0:18:52.320000 --> 0:18:55.120000
 Apache is the web server technology.

0:18:55.120000 --> 0:18:57.420000
 And in terms of Linux, it's
 running on Ubuntu server.

0:18:57.420000 --> 0:19:00.500000
 And we know the server side
 programming language is PHP.

0:19:00.500000 --> 0:19:04.860000
 So there's a good chance that we're dealing
 with an open source relational

0:19:04.860000 --> 0:19:11.300000
 database or RDBMS or DBMS, like
 MySQL or MariaDB or PostgreSQL.

0:19:11.300000 --> 0:19:13.460000
 We still don't know that, right?

0:19:13.460000 --> 0:19:18.420000
 So we'll go back here and we have another
 application input, so login,

0:19:18.420000 --> 0:19:20.500000
 which looks quite interesting.

0:19:20.500000 --> 0:19:23.280000
 And we also have the search
 functionality here.

0:19:23.280000 --> 0:19:25.280000
 So let's go back home and
 test the first one.

0:19:25.280000 --> 0:19:30.420000
 So we'll test each one and I'll just
 go into burp here and I'll turn on

0:19:30.420000 --> 0:19:35.240000
 intercept. And I will just go ahead and
 perform and just search for something

0:19:35.240000 --> 0:19:38.240000
 random like test and
 I'll click on search.

0:19:38.240000 --> 0:19:42.420000
 All right. So within the HTTP requests
 that is intercepted by burp, we

0:19:42.420000 --> 0:19:44.920000
 can see that no parameters
 are passed in the URL.

0:19:44.920000 --> 0:19:50.840000
 However, they are passed as the or
 in the body of the actual request.

0:19:50.840000 --> 0:19:55.220000
 So we can see in this case, the parameter
 is words pre format and we have

0:19:55.220000 --> 0:19:57.800000
 the value of the parameter,
 which is test.

0:19:57.800000 --> 0:20:00.180000
 All right. So what's the
 first thing we can do?

0:20:00.180000 --> 0:20:04.520000
 The first thing we can do is obviously
 try utilizing the single quote

0:20:04.520000 --> 0:20:07.540000
 here to see whether we
 can invoke an error.

0:20:07.540000 --> 0:20:09.280000
 So I'm going to forward that.

0:20:09.280000 --> 0:20:13.120000
 And if we go back to the web application,
 you can see it tells us immediately

0:20:13.120000 --> 0:20:17.740000
 based on how the web application is designed
 that we have a database error.

0:20:17.740000 --> 0:20:22.420000
 And if we take a look at the text here,
 it tells us or it gives us one

0:20:22.420000 --> 0:20:27.060000
 of these unique banners or banners
 unique to a particular DBMS.

0:20:27.060000 --> 0:20:30.080000
 So you have an error in your SQL syntax.

0:20:30.080000 --> 0:20:34.140000
 Check the manual that corresponds
 to your MySQL server version.

0:20:34.140000 --> 0:20:38.400000
 So just based on this, we know we're
 dealing with a MySQL database.

0:20:38.400000 --> 0:20:44.040000
 Now, it also displays where we are having
 an issue with the syntax, right?

0:20:44.040000 --> 0:20:49.360000
 And in this case, it doesn't display
 the entire SQL query, just what comes

0:20:49.360000 --> 0:20:54.600000
 after the single quote when we essentially
 terminate the string literal.

0:20:54.600000 --> 0:21:00.220000
 So we can see that after that, it says
 in Boolean mode, order by name.

0:21:00.220000 --> 0:21:06.040000
 So it looks like a typical search query
 that is searching for specific

0:21:06.040000 --> 0:21:11.120000
 posts or specific pages that have
 been stored within the database.

0:21:11.120000 --> 0:21:14.400000
 And it's trying to order
 them by their name.

0:21:14.400000 --> 0:21:20.080000
 All right, we don't know much or anything
 about the table or the columns

0:21:20.080000 --> 0:21:23.440000
 that are being referenced here, because
 we can't see the first part of

0:21:23.440000 --> 0:21:24.860000
 the SQL query. Right.

0:21:24.860000 --> 0:21:26.300000
 Now, what does this tell us?

0:21:26.300000 --> 0:21:31.720000
 Well, firstly, we've identified this
 site is vulnerable to error based

0:21:31.720000 --> 0:21:35.800000
 SQL injection. And we've done that through
 the use of very simple payload.

0:21:35.800000 --> 0:21:39.320000
 Now, you could have done this manually,
 or you could have fuzzed this

0:21:39.320000 --> 0:21:44.460000
 with something like, you
 know, the OSB zap fuzzer.

0:21:44.460000 --> 0:21:48.660000
 All right, which you can also do with,
 you can also do this with burp

0:21:48.660000 --> 0:21:53.000000
 suite. So again, I can also show you
 that, which is perfectly fine.

0:21:53.000000 --> 0:21:55.580000
 We also have the login right over here.

0:21:55.580000 --> 0:21:59.140000
 So I'm just going to disable intercept
 shortly, and we can test this out.

0:21:59.140000 --> 0:22:03.520000
 So what I'm going to do is turn on intercept
 now, and I'll just pass in.

0:22:03.520000 --> 0:22:07.800000
 Some test parameters, sort of test and
 password, and I'll hit login here,

0:22:07.800000 --> 0:22:11.260000
 and you can see it's passed
 in the body of the request.

0:22:11.260000 --> 0:22:14.280000
 In this case, it's a post request,
 which makes sense.

0:22:14.280000 --> 0:22:16.640000
 And nothing is passed in the URL, right?

0:22:16.640000 --> 0:22:19.800000
 So no parameters in the URL,
 which is perfectly fine.

0:22:19.800000 --> 0:22:23.280000
 So what we can do is we can send
 this to the repeater here.

0:22:23.280000 --> 0:22:28.280000
 And, you know, we can play around with
 this and see whether any of these

0:22:28.280000 --> 0:22:29.920000
 fields is vulnerable to SQL injection.

0:22:29.920000 --> 0:22:32.560000
 So I can, you know, change
 that to a single quote.

0:22:32.560000 --> 0:22:34.620000
 We don't need any URL encoding.

0:22:34.620000 --> 0:22:38.100000
 So let's send. We take a look
 at the response here.

0:22:38.100000 --> 0:22:41.140000
 And, you know, we look at this here.

0:22:41.140000 --> 0:22:45.260000
 It says we can't see anything that looks
 interesting, any error message,

0:22:45.260000 --> 0:22:48.400000
 but it says the use name you
 entered cannot be found.

0:22:48.400000 --> 0:22:51.420000
 We can also try and render this
 to see what it looks like.

0:22:51.420000 --> 0:22:55.120000
 There we are. So it looks like it doesn't
 look like this particular form

0:22:55.120000 --> 0:22:59.580000
 is vulnerable. However, we can still
 put it through extensive tests by

0:22:59.580000 --> 0:23:04.880000
 utilizing the, for example, in this
 particular case, we can send it to

0:23:04.880000 --> 0:23:09.620000
 the intruder. If we go into the intruder,
 we can utilize this sort of

0:23:09.620000 --> 0:23:14.940000
 the fuzzer, the OS or rather the burpsweet
 equivalent of the OS per zap

0:23:14.940000 --> 0:23:19.220000
 fuzzer. And I've already covered this
 functionality and how to use all

0:23:19.220000 --> 0:23:23.920000
 of these modules within burpsweet and
 OS per zap respectively in its own

0:23:23.920000 --> 0:23:25.220000
 course, which is the web proxy.

0:23:25.220000 --> 0:23:28.480000
 So again, I highly recommend
 that you go through it.

0:23:28.480000 --> 0:23:33.000000
 So what we want to do is test both of
 these payload positions, which have

0:23:33.000000 --> 0:23:38.340000
 already been added automatically for
 us for SQL injection vulnerabilities.

0:23:38.340000 --> 0:23:42.540000
 So we can leave it as is and we can
 go into payloads and we can load a

0:23:42.540000 --> 0:23:44.040000
 custom payload list.

0:23:44.040000 --> 0:23:48.620000
 So remember in the previous section,
 we generated or we generated a custom

0:23:48.620000 --> 0:23:52.980000
 SQL injection payload list and we can
 load that in here, which has, you

0:23:52.980000 --> 0:23:55.280000
 know, the set of SQL injection.

0:23:55.280000 --> 0:23:59.520000
 Payloads are very small list, but we'll
 go ahead and we've selected the

0:23:59.520000 --> 0:24:03.540000
 position so we can start the attack and
 the community version of burpsweet

0:24:03.540000 --> 0:24:06.540000
 will limit the number of requests.

0:24:06.540000 --> 0:24:07.480000
 So there we are.

0:24:07.480000 --> 0:24:12.080000
 Let's see if we get any change in
 the length of the response here.

0:24:12.080000 --> 0:24:15.940000
 And there's about 154 payloads
 that is going to fuzz.

0:24:15.940000 --> 0:24:19.020000
 And again, you can do this same process
 or you can go through the same

0:24:19.020000 --> 0:24:21.840000
 process with OS per zap.

0:24:21.840000 --> 0:24:23.260000
 It's entirely up to you.

0:24:23.260000 --> 0:24:26.640000
 I just want to show you what I would
 typically do once I start using a

0:24:26.640000 --> 0:24:28.140000
 specific web proxy.

0:24:28.140000 --> 0:24:31.400000
 I end up just going through the entire
 assessment with it unless I need

0:24:31.400000 --> 0:24:32.980000
 some bespoke feature set.

0:24:32.980000 --> 0:24:36.240000
 So I'm going to let this complete and
 then we'll take a look at the actual

0:24:36.240000 --> 0:24:38.480000
 results. All right.

0:24:38.480000 --> 0:24:41.500000
 So the intruder attack or
 the fuzzing is complete.

0:24:41.500000 --> 0:24:47.600000
 Now, one thing when using burpsweet
 to focus on is the actual length of

0:24:47.600000 --> 0:24:49.620000
 the response and the status code.

0:24:49.620000 --> 0:24:54.500000
 So in this case, they all 200 status
 codes, which means we got a response,

0:24:54.500000 --> 0:24:58.320000
 which is great. However, we can see
 that for the first few, the length

0:24:58.320000 --> 0:25:00.120000
 is pretty much uniform, right?

0:25:00.120000 --> 0:25:02.760000
 So we can actually view
 the response here.

0:25:02.760000 --> 0:25:07.040000
 And if you take a look at the responses
 for the first few set of payloads

0:25:07.040000 --> 0:25:10.260000
 that we're already familiar with that,
 you know, can typically be used

0:25:10.260000 --> 0:25:13.120000
 to bypass a login screen.

0:25:13.120000 --> 0:25:18.240000
 We can see that if we go into the actual
 response and you click on render,

0:25:18.240000 --> 0:25:20.580000
 it'll actually show you what
 the response looks like.

0:25:20.580000 --> 0:25:23.800000
 And if I expand the page here,
 you'll be able to see that.

0:25:23.800000 --> 0:25:28.800000
 So we can go through the ones that,
 so, you know, any response to the

0:25:28.800000 --> 0:25:37.400000
 length of 3046 bytes here or kilobytes
 will all look to have the same

0:25:37.400000 --> 0:25:39.180000
 type of response from
 the web application.

0:25:39.180000 --> 0:25:41.300000
 So this is very common fuzzing.

0:25:41.300000 --> 0:25:43.400000
 What you're looking for is anomaly.

0:25:43.400000 --> 0:25:48.720000
 So in this case, we have 352, right,
 or 3052, which also looks like the

0:25:48.720000 --> 0:25:49.500000
 same sort of response.

0:25:49.500000 --> 0:25:53.100000
 The only reason it's a bit larger is
 because the size of the payload we

0:25:53.100000 --> 0:25:56.820000
 injected or we are fuzzing for
 in this case have increased.

0:25:56.820000 --> 0:25:58.980000
 What we're looking for is anomaly.

0:25:58.980000 --> 0:26:02.580000
 So you can see they pretty much
 all have around the same size.

0:26:02.580000 --> 0:26:06.600000
 However, we do have some very
 interesting ones like 2696.

0:26:06.600000 --> 0:26:11.340000
 So if we click on this, in this case,
 we can see aha, we have a database

0:26:11.340000 --> 0:26:16.000000
 error. So we know there is SQL
 injection is indeed possible.

0:26:16.000000 --> 0:26:20.080000
 Why? Firstly, there's multiple application
 inputs, but in this case, we're

0:26:20.080000 --> 0:26:22.640000
 testing the login form.

0:26:22.640000 --> 0:26:25.400000
 And also, there isn't
 any input validation.

0:26:25.400000 --> 0:26:29.880000
 Now, we've confirmed that it exists,
 but were we able to see any payloads

0:26:29.880000 --> 0:26:35.180000
 that look like they were successful in
 either a bypassing the login form.

0:26:35.180000 --> 0:26:37.520000
 Or giving us any type of data.

0:26:37.520000 --> 0:26:41.060000
 Well, in this case, not really apart
 from bypassing the login form, these

0:26:41.060000 --> 0:26:47.160000
 payloads typically just confirm SQL injection,
 which is all that we would

0:26:47.160000 --> 0:26:51.780000
 really want when doing a bug
 bounty hunting, right?

0:26:51.780000 --> 0:26:56.500000
 So if we click on this one here, we
 can see that we get the SQL error.

0:26:56.500000 --> 0:26:59.700000
 So we've pretty much confirmed it.

0:26:59.700000 --> 0:27:05.180000
 And for some of them, we have the query
 being returned or the error, the

0:27:05.180000 --> 0:27:07.040000
 mistake with the query as it were.

0:27:07.040000 --> 0:27:11.660000
 So if we click on some of these here
 that we're familiar with, like, or

0:27:11.660000 --> 0:27:16.320000
 one equals one, and then we use the comment,
 we can see that once it renders,

0:27:16.320000 --> 0:27:18.380000
 it looks like we have
 an error, et cetera.

0:27:18.380000 --> 0:27:23.140000
 And you can go ahead and take a look
 at the responses with varying lengths

0:27:23.140000 --> 0:27:26.600000
 or non-uniform lengths here.

0:27:26.600000 --> 0:27:31.060000
 And at this point, you know, we've
 confirmed it, but I'm going to show

0:27:31.060000 --> 0:27:37.260000
 you shortly how we can go about identifying
 or identifying additional

0:27:37.260000 --> 0:27:42.280000
 payloads that can help us perform enumeration
 or can help us identify

0:27:42.280000 --> 0:27:47.240000
 more information about the database,
 as is our goal or as was our goal

0:27:47.240000 --> 0:27:51.960000
 in the slides. So you can see for this
 one, for example, it looks like

0:27:51.960000 --> 0:28:00.780000
 there we are. This payload here specifically
 says, you know, it utilizes

0:28:00.780000 --> 0:28:05.640000
 this prebuilt payload with, you know,
 one to three force double quotes

0:28:05.640000 --> 0:28:10.120000
 and using a logical operator one equals
 zero, which is false, and then

0:28:10.120000 --> 0:28:12.320000
 union select admin.

0:28:12.320000 --> 0:28:14.640000
 And we don't get any information there.

0:28:14.640000 --> 0:28:19.320000
 All right, so we know that SQL injection,
 a SQL injection vulnerability

0:28:19.320000 --> 0:28:23.900000
 exists, more specifically error based
 within the initial search form,

0:28:23.900000 --> 0:28:26.580000
 as well as the login form.

0:28:26.580000 --> 0:28:31.520000
 Let's perform a few more tests on some
 of the other application inputs

0:28:31.520000 --> 0:28:36.780000
 that we have. Now, with Burbsweet, the
 community edition, we really can't

0:28:36.780000 --> 0:28:37.960000
 save these results.

0:28:37.960000 --> 0:28:41.160000
 I'm just going to exit out of here,
 or you can actually minimize it, but

0:28:41.160000 --> 0:28:43.200000
 I'll just exit here.

0:28:43.200000 --> 0:28:45.160000
 And there we are, just discard it.

0:28:45.160000 --> 0:28:47.740000
 We don't really need it at this point,
 and I'll get rid of the intruder

0:28:47.740000 --> 0:28:51.940000
 session there, as well as this one here,
 and under the proxy, we'll just

0:28:51.940000 --> 0:28:53.120000
 for that request.

0:28:53.120000 --> 0:28:56.800000
 So we know that there is a SQL
 injection vulnerability.

0:28:56.800000 --> 0:29:00.140000
 You could have taken any of those payloads
 and then tested them manually

0:29:00.140000 --> 0:29:03.760000
 here. In this case, we know the single
 quote doesn't work, which is perfectly

0:29:03.760000 --> 0:29:06.660000
 fine. I'm just going
 to disable intercept.

0:29:06.660000 --> 0:29:10.820000
 And the other one, of course, is the
 search functionality here, which

0:29:10.820000 --> 0:29:14.300000
 has a PHP file called find recipe.

0:29:14.300000 --> 0:29:18.100000
 And in the beginning, when we use this
 search form, we can see that it

0:29:18.100000 --> 0:29:22.760000
 has a PHP file, or it's utilizing a
 PHP file called do search, right?

0:29:22.760000 --> 0:29:26.560000
 So we're going to search here, and
 we just type in, for example, test

0:29:26.560000 --> 0:29:28.700000
 in any of these fields.

0:29:28.700000 --> 0:29:30.060000
 And let me turn on the intercept.

0:29:30.060000 --> 0:29:33.560000
 I want to see something, you know, I'm
 just testing to see what's going

0:29:33.560000 --> 0:29:38.120000
 on. So I'll hit search, and we can see
 no parameters passed in the URL.

0:29:38.120000 --> 0:29:41.600000
 However, the parameters and their values
 are passed in the body of the

0:29:41.600000 --> 0:29:43.680000
 request. In this case,
 this is a post request.

0:29:43.680000 --> 0:29:53.200000
 So we can see that we have, in this
 case, one, two, three, four, five,

0:29:53.200000 --> 0:29:54.840000
 and six parameters.

0:29:54.840000 --> 0:29:57.860000
 All right. Now, are any
 one of these injectable?

0:29:57.860000 --> 0:30:02.260000
 Well, again, in this case, we can utilize
 the burp suite intruder or the

0:30:02.260000 --> 0:30:03.820000
 OASP zap fuzzer.

0:30:03.820000 --> 0:30:08.740000
 It's, again, entirely up to you to test
 them for SQL injection vulnerabilities.

0:30:08.740000 --> 0:30:11.920000
 So what we'll do in this case, let's
 send this to the intruder and we

0:30:11.920000 --> 0:30:16.240000
 can test the first two for SQL injection
 vulnerabilities, the first two

0:30:16.240000 --> 0:30:17.320000
 parameters that is.

0:30:17.320000 --> 0:30:20.720000
 So I'll just clear the
 predefined ones here.

0:30:20.720000 --> 0:30:25.060000
 And we'll say, for example, I
 want you to add a place there.

0:30:25.060000 --> 0:30:31.460000
 And I also want you to encapsulate
 this here and actually hold on.

0:30:31.460000 --> 0:30:33.280000
 Let me get rid of that one there.

0:30:33.280000 --> 0:30:37.240000
 We can add a space typically that usually
 works just to highlight that

0:30:37.240000 --> 0:30:40.660000
 there. And we can add this one here.

0:30:40.660000 --> 0:30:46.060000
 So in this particular case, hold on, let
 me just make sure that is working.

0:30:46.060000 --> 0:30:51.580000
 And in this particular case, we can
 just say we want to add it in here.

0:30:51.580000 --> 0:30:54.880000
 So I'm just going to, you know, say
 test, for example, just keep that

0:30:54.880000 --> 0:30:57.820000
 as is and also add one here.

0:30:57.820000 --> 0:31:00.740000
 All right. So these are the two
 that we want to test for.

0:31:00.740000 --> 0:31:03.920000
 Now, if we go into payloads, we're just
 going to use the same one we used

0:31:03.920000 --> 0:31:06.780000
 from the previous section of this course.


0:31:06.780000 --> 0:31:11.160000
 And again, you can just copy a set
 of SQL injection payloads from the

0:31:11.160000 --> 0:31:14.140000
 GitHub repo that has them,
 save them in a text file.

0:31:14.140000 --> 0:31:19.820000
 And you now have a fuzzing, a fuzzing
 list or a payload list as it were.

0:31:19.820000 --> 0:31:21.940000
 And we can go ahead and
 start this attack.

0:31:21.940000 --> 0:31:24.700000
 So again, this will be throttle
 when using burp suite.

0:31:24.700000 --> 0:31:26.980000
 And we want to take a
 look at the responses.

0:31:26.980000 --> 0:31:30.180000
 So this is going to take a few
 seconds to a couple of minutes.

0:31:30.180000 --> 0:31:32.520000
 And I'm just going to wait for this
 to complete and then we'll analyze