WEBVTT

0:00:03.780000 --> 0:00:05.860000
 Hello everyone and welcome.

0:00:05.860000 --> 0:00:09.760000
 In this video, we're going to be taking
 a look at an SQL injection testing

0:00:09.760000 --> 0:00:12.940000
 methodology that I've
 sort of put together.

0:00:12.940000 --> 0:00:18.180000
 That's very closely aligned to what
 we'll be covering in this course,

0:00:18.180000 --> 0:00:21.300000
 but really goes beyond it.

0:00:21.300000 --> 0:00:24.840000
 And I just wanted to touch on, you
 know, I sort of wanted to give you

0:00:24.840000 --> 0:00:28.880000
 an understanding of what methodology
 I typically use in terms of where

0:00:28.880000 --> 0:00:33.700000
 I start, all the way to exploitation,
 if an SQL injection vulnerability

0:00:33.700000 --> 0:00:38.640000
 exists. And I've also put together
 a quick checklist in the form of a

0:00:38.640000 --> 0:00:40.560000
 table in these slides.

0:00:40.560000 --> 0:00:45.020000
 So let's get started firstly by, you
 know, listing out my methodology

0:00:45.020000 --> 0:00:49.760000
 that again is sequential, depending
 on a couple of factors.

0:00:49.760000 --> 0:00:52.900000
 But we always start off with
 entry point detection, right?

0:00:52.900000 --> 0:00:56.860000
 And so that's all a step one, you
 can call this reconnaissance, etc.

0:00:56.860000 --> 0:01:00.260000
 But what this involves, you know, during
 a web app and test is identifying

0:01:00.260000 --> 0:01:04.500000
 all user input fields that interact
 with the database in the case of SQL

0:01:04.500000 --> 0:01:09.380000
 injection. And these could be in the form
 of form fields, query parameters,

0:01:09.380000 --> 0:01:13.340000
 headers, cookies, pretty much anyway,
 where you can, you can essentially

0:01:13.340000 --> 0:01:16.500000
 specify data that's processed
 by the database.

0:01:16.500000 --> 0:01:20.180000
 Secondly, you know, understand the
 applications, behavior and logic to

0:01:20.180000 --> 0:01:23.420000
 predict possible SQL query structures.

0:01:23.420000 --> 0:01:27.620000
 And then look for dynamic SQL queries
 and application responses, very

0:01:27.620000 --> 0:01:30.700000
 common when we're talking about
 error messages, right?

0:01:30.700000 --> 0:01:36.120000
 Now, the second step is not always
 the case, generally speaking, or it

0:01:36.120000 --> 0:01:40.000000
 may come after initial testing, but
 generally speaking, if there is a

0:01:40.000000 --> 0:01:44.060000
 database, or we know, you know, through
 how the application works and

0:01:44.060000 --> 0:01:47.860000
 how it's responding, that there is a
 database, whether it be relational

0:01:47.860000 --> 0:01:51.480000
 or, you know, non relational
 really doesn't matter.

0:01:51.480000 --> 0:01:55.580000
 Generally speaking, I like to know what
 I'm dealing with in terms of the

0:01:55.580000 --> 0:01:59.180000
 type of RDBMS, for example,
 so is it MySQL?

0:01:59.180000 --> 0:02:01.360000
 Is it postgreSQL?

0:02:01.360000 --> 0:02:03.880000
 Is it Oracle? What am I dealing with?

0:02:03.880000 --> 0:02:07.440000
 And the reason why that's important
 is because as you know, for each of

0:02:07.440000 --> 0:02:13.460000
 these types of RDBMSs, they all have
 their own nuances in terms of the

0:02:13.460000 --> 0:02:18.500000
 query language. So if I tried to run
 some, or if I tried to inject some

0:02:18.500000 --> 0:02:23.020000
 MySQL payloads into a web application
 input that is then processed by

0:02:23.020000 --> 0:02:27.420000
 a post or by an Oracle database, in
 the back end, I'm obviously going

0:02:27.420000 --> 0:02:33.180000
 to have issues. So the bottom line is
 that certain SQL keywords are specific

0:02:33.180000 --> 0:02:37.120000
 to particular database management
 systems or DBMSs.

0:02:37.120000 --> 0:02:40.840000
 In the case of relational databases,
 they are called RDBMSs.

0:02:40.840000 --> 0:02:44.260000
 So, you know, if that's confusing,
 you that's what I meant there.

0:02:44.260000 --> 0:02:47.800000
 The bottom line is that by using these
 keywords in SQL injection attempts

0:02:47.800000 --> 0:02:51.680000
 and observing how the website responds
 or the web application, you can

0:02:51.680000 --> 0:02:57.180000
 often, often is the keyword determine
 the type of DBMS being used.

0:02:57.180000 --> 0:03:00.240000
 And then of course, we have initial
 testing where you test for the basic

0:03:00.240000 --> 0:03:04.540000
 stuff, right? So basic SQL injection
 payloads, which are your Boolean

0:03:04.540000 --> 0:03:07.460000
 in terms of the actual payload.

0:03:07.460000 --> 0:03:12.240000
 So, you know, just specify statements
 or queries that are likely to return

0:03:12.240000 --> 0:03:15.520000
 a specific result, you know,
 either true or false.

0:03:15.520000 --> 0:03:21.820000
 In this case, we are using the, we're
 essentially delimiting or terminating

0:03:21.820000 --> 0:03:26.700000
 the previous, you know, anything after
 what is expected to be input and

0:03:26.700000 --> 0:03:27.760000
 then running the query.

0:03:27.760000 --> 0:03:31.260000
 So we say, or one equals
 one, which is true.

0:03:31.260000 --> 0:03:32.880000
 And then we see what we get.

0:03:32.880000 --> 0:03:35.320000
 We can also say one equals two,
 which is going to be false.

0:03:35.320000 --> 0:03:38.140000
 And we see what type of
 output we get, right?

0:03:38.140000 --> 0:03:42.040000
 The bottom bottom line is you observe
 the applications response for errors,

0:03:42.040000 --> 0:03:45.140000
 unexpected outputs or
 behavioral anomalies.

0:03:45.140000 --> 0:03:49.180000
 And then based on that, you can move on
 to more specific or vulnerabilities,

0:03:49.180000 --> 0:03:51.800000
 SQL I vulnerability specific testing.

0:03:51.800000 --> 0:03:55.820000
 So error based testing, where you inject
 payloads that intentionally cause

0:03:55.820000 --> 0:04:01.340000
 SQL syntax errors, for example, or
 sleep, you know, five seconds, look

0:04:01.340000 --> 0:04:07.020000
 for database error messages that expose
 the database type or structure.

0:04:07.020000 --> 0:04:09.560000
 And then of course, you're going to
 have blind, obviously, where you'd

0:04:09.560000 --> 0:04:13.940000
 use, you know, Boolean based payloads
 to infer database behavior without

0:04:13.940000 --> 0:04:16.980000
 direct input. So, and one
 equals one, that's true.

0:04:16.980000 --> 0:04:21.540000
 I mentioned that, you know, in the initial
 testing phase, and then false

0:04:21.540000 --> 0:04:26.480000
 one equals two. And you know, you would
 apply time based payloads to test

0:04:26.480000 --> 0:04:28.860000
 responses based on delay.

0:04:28.860000 --> 0:04:35.000000
 So, or if one equals one, which is going
 to be true, sleep for five seconds,

0:04:35.000000 --> 0:04:36.560000
 you monitor the response.

0:04:36.560000 --> 0:04:40.900000
 If it hits that time, you know,
 you're, you're good to go.

0:04:40.900000 --> 0:04:45.320000
 And then of course, you have union based
 testing, where you identify the

0:04:45.320000 --> 0:04:50.520000
 number of columns in the SQL query,
 by incrementing the number of null

0:04:50.520000 --> 0:04:52.080000
 values in payloads.

0:04:52.080000 --> 0:04:55.740000
 So union select null, then the comment,
 and then you test data extraction

0:04:55.740000 --> 0:05:02.540000
 with union select username, password
 from users, end it with a, you end

0:05:02.540000 --> 0:05:05.680000
 it there. And then of course, advanced
 testing, which will, I'll dive

0:05:05.680000 --> 0:05:08.260000
 into that methodology
 when we get to that.

0:05:08.260000 --> 0:05:12.100000
 But what you're doing is testing for
 out of band SQL injection using DNS

0:05:12.100000 --> 0:05:18.680000
 or HTTP callbacks, for example, you
 know, through the BIP collaborator,

0:05:18.680000 --> 0:05:22.600000
 and then also looking for second order
 vulnerabilities by injecting payloads

0:05:22.600000 --> 0:05:25.060000
 that are executed in later queries.

0:05:25.060000 --> 0:05:30.400000
 So, as I said, advanced testing, the advanced
 testing methodology, methodologies

0:05:30.400000 --> 0:05:34.700000
 specific to these vulnerabilities,
 we will we will explore when we get

0:05:34.700000 --> 0:05:39.540000
 them. And then of course, I also include
 the use of automated testing

0:05:39.540000 --> 0:05:44.240000
 when I now need to be very sure of what
 I found and to validate whether

0:05:44.240000 --> 0:05:47.780000
 there's other types of SQL injection
 vulnerabilities, because let's say

0:05:47.780000 --> 0:05:51.620000
 a login form can be vulnerable to error
 based, or it can also be vulnerable

0:05:51.620000 --> 0:05:57.160000
 to let's say blind Boolean
 based as an example, right?

0:05:57.160000 --> 0:06:01.900000
 So you use tools like SQL map, burp suite,
 or OASP SAP to perform automated

0:06:01.900000 --> 0:06:05.520000
 scans, and then confirm finding
 confirm findings manually.

0:06:05.520000 --> 0:06:09.060000
 This can work vice versa, where you start
 manually, and then you validate

0:06:09.060000 --> 0:06:13.700000
 with SQL map in terms of getting more
 info, or you start with SQL map,

0:06:13.700000 --> 0:06:17.980000
 and then, you know, validate manually
 to avoid false positives.

0:06:17.980000 --> 0:06:24.480000
 And then of course, finally, we have
 the validation and exploitation.

0:06:24.480000 --> 0:06:27.820000
 And apologies if the slide is a little
 bit clipped here, but you know,

0:06:27.820000 --> 0:06:31.220000
 you validate the exploitability of the
 vulnerability by extracting data.

0:06:31.220000 --> 0:06:34.700000
 Essentially, what you do in a bug bounty
 report where you essentially

0:06:34.700000 --> 0:06:39.560000
 demonstrate a POC that can be recreated,
 but also shows impact.

0:06:39.560000 --> 0:06:42.020000
 And then of course, you document the
 impact and provide recommendations

0:06:42.020000 --> 0:06:43.720000
 for fixing the issue.

0:06:43.720000 --> 0:06:47.620000
 So that brings us to the checklist that
 is extrapolated from the methodology,

0:06:47.620000 --> 0:06:53.080000
 where, you know, firstly, you have
 the first column is the step of the

0:06:53.080000 --> 0:06:56.820000
 methodology, you know, within the checklist,
 the description, and then

0:06:56.820000 --> 0:06:59.560000
 the example, an example of
 what would be done there.

0:06:59.560000 --> 0:07:03.420000
 So identifying the input points, locate
 all inputs that interact with

0:07:03.420000 --> 0:07:07.240000
 the database. There's could be form
 fields, URL parameters, cookies, of

0:07:07.240000 --> 0:07:08.400000
 course, there's many others.

0:07:08.400000 --> 0:07:11.060000
 But in this case, we have that then
 of course, I've sort of listed out

0:07:11.060000 --> 0:07:16.280000
 the basic payload testing, error based
 testing, Boolean based testing,

0:07:16.280000 --> 0:07:21.960000
 time based testing, union based testing,
 and the types of example payloads

0:07:21.960000 --> 0:07:25.100000
 you typically see or use in those cases.

0:07:25.100000 --> 0:07:28.620000
 And then, oh, B testing, so use out
 of band techniques to trigger DNS

0:07:28.620000 --> 0:07:30.700000
 or HTTP callbacks.

0:07:30.700000 --> 0:07:34.000000
 And then second order testing,
 tool based scanning.

0:07:34.000000 --> 0:07:37.740000
 So essentially, an extrapolation of the
 methodology, but now in a systematic

0:07:37.740000 --> 0:07:41.860000
 and organized format, that sort of gives
 you an idea of where to start,

0:07:41.860000 --> 0:07:46.340000
 where to end. Of course, this is, as
 I said, there's a few nuances to

0:07:46.340000 --> 0:07:51.720000
 this checklist. And I've sort of designed
 this one with what based on

0:07:51.720000 --> 0:07:55.000000
 what I what my checklist or methodology
 is in the real world.

0:07:55.000000 --> 0:08:01.860000
 And sort of, but also adapted it to
 to be suitable for for use in this

0:08:01.860000 --> 0:08:03.000000
 particular course.

0:08:03.000000 --> 0:08:06.560000
 But apart from that, this is generally
 speaking, if you go and, you know,

0:08:06.560000 --> 0:08:11.100000
 perform some research online, this is
 generally speaking what you'd expect.

0:08:11.100000 --> 0:08:13.400000
 So definitely check that out.

0:08:13.400000 --> 0:08:17.040000
 Okay, so that brings us to
 the end of this video.

0:08:17.040000 --> 0:08:19.220000
 And I will be seeing you
 in the next video.