WEBVTT

0:00:03.520000 --> 0:00:05.680000
 Hello everyone and welcome.

0:00:05.680000 --> 0:00:09.740000
 In this video we're going to be taking
 a look at second order SQL injection.

0:00:09.740000 --> 0:00:15.780000
 So this is not that much of a difficult
 vulnerability or attack to understand.

0:00:15.780000 --> 0:00:20.840000
 Again, just like what we explored in
 the previous video, the out of band

0:00:20.840000 --> 0:00:26.980000
 attacks or techniques, you just need
 to understand how it works and more

0:00:26.980000 --> 0:00:33.040000
 importantly that will shed light on when
 this would become, this particular

0:00:33.040000 --> 0:00:40.060000
 vulnerability becomes relevant
 or when it typically shows up.

0:00:40.060000 --> 0:00:47.520000
 So I'll also be augmenting this video
 by giving you as real as an example

0:00:47.520000 --> 0:00:50.500000
 as I possibly can.

0:00:50.500000 --> 0:00:54.540000
 But second order SQL injection is
 very, very easy to understand.

0:00:54.540000 --> 0:01:00.500000
 So if we want to understand second order
 SQL injection, you need to understand

0:01:00.500000 --> 0:01:02.440000
 first order SQL injection.

0:01:02.440000 --> 0:01:09.300000
 Now the great thing is, the great thing
 about second order SQL injection

0:01:09.300000 --> 0:01:13.780000
 is you're going to be already going
 to be familiar with first order SQL

0:01:13.780000 --> 0:01:18.680000
 injection. So when I say you're familiar
 with it, pretty much all techniques

0:01:18.680000 --> 0:01:26.540000
 excluding the out of band actually including
 the out of band techniques

0:01:26.540000 --> 0:01:31.400000
 we explored in the previous video are what
 you typically classify or technically

0:01:31.400000 --> 0:01:36.660000
 classify as first order SQL injection
 vulnerabilities or attacks.

0:01:36.660000 --> 0:01:40.580000
 So the bottom line is that whenever we're
 discussing SQL injection attacks,

0:01:40.580000 --> 0:01:45.640000
 generally speaking, you're going to be
 referring to the traditional first

0:01:45.640000 --> 0:01:49.160000
 order SQL injection scenarios or attacks.


0:01:49.160000 --> 0:01:54.700000
 So that begs the question, what exactly
 is or can you define first order

0:01:54.700000 --> 0:01:59.020000
 SQL injection? And we're talking
 about defining it.

0:01:59.020000 --> 0:02:04.620000
 It's really more so outlining how the
 attack functions with regards to

0:02:04.620000 --> 0:02:11.140000
 you, the attacker and the actual target
 web application databases etc.

0:02:11.140000 --> 0:02:15.840000
 So first order SQL, the first order SQL
 injection process is conceptually

0:02:15.840000 --> 0:02:20.320000
 similar to you know, the standard challenge
 response system that's used

0:02:20.320000 --> 0:02:22.200000
 in authentication where
 you have a challenge.

0:02:22.200000 --> 0:02:27.860000
 And then based on that challenge,
 you know, you get a response.

0:02:27.860000 --> 0:02:32.380000
 What this means is that in this type
 of attack, the attacker directly

0:02:32.380000 --> 0:02:40.660000
 sends or inject malicious input, which
 could be a response that says this

0:02:40.660000 --> 0:02:45.800000
 input or payload, if you will, and returns,
 I wouldn't say an immediate

0:02:45.800000 --> 0:02:49.620000
 but you know, most of the time it's
 going to be an immediate exploitable

0:02:49.620000 --> 0:02:54.920000
 response or a response that indicates
 or tells you, Hey, you know, yes,

0:02:54.920000 --> 0:02:56.540000
 I am vulnerable or no.

0:02:56.540000 --> 0:03:01.080000
 So just think of when we're exploiting
 SQL injection vulnerabilities in

0:03:01.080000 --> 0:03:06.060000
 this course earlier on, when we injected
 a payload, we got the response

0:03:06.060000 --> 0:03:09.000000
 almost immediately.

0:03:09.000000 --> 0:03:13.720000
 And when I say instantly, or when I use
 the word immediate, I'm referring

0:03:13.720000 --> 0:03:18.120000
 to the fact that, you know, generally
 speaking, even including, you know,

0:03:18.120000 --> 0:03:23.240000
 time based SQL injection, it's going
 to be relatively quick, right?

0:03:23.240000 --> 0:03:27.420000
 Or you will, you know, for example,
 if I inject a time based payload,

0:03:27.420000 --> 0:03:30.640000
 I'll still get the response that
 I'm looking for immediately.

0:03:30.640000 --> 0:03:39.200000
 So or is sleeping, let's say, then
 I know, you know, immediately that,

0:03:39.200000 --> 0:03:44.880000
 yes, my payload did work, or if I don't
 get anything back or the web application

0:03:44.880000 --> 0:03:48.880000
 response normally, then I know that
 yeah, that probably failed.

0:03:48.880000 --> 0:03:54.340000
 The bottom line is that you actually
 get to see or to understand very

0:03:54.340000 --> 0:03:58.000000
 quickly, whether you know your attack
 is successful or not, or whether

0:03:58.000000 --> 0:04:00.600000
 you need to start testing
 other techniques.

0:04:00.600000 --> 0:04:04.400000
 So the bottom line is that the exploitation
 occurs in real time during

0:04:04.400000 --> 0:04:08.700000
 the initial interaction, therefore allowing
 the attacker to observe the

0:04:08.700000 --> 0:04:12.500000
 application's response and adjust
 their payloads dynamically.

0:04:12.500000 --> 0:04:18.960000
 And this, this direct feedback loop is a
 hallmark of first order SQL injection,

0:04:18.960000 --> 0:04:23.980000
 which makes it or distinguishes itself
 from delayed or stored attack types,

0:04:23.980000 --> 0:04:28.580000
 which is exactly these are the attacks
 that, you know, would fall under

0:04:28.580000 --> 0:04:31.900000
 second order SQL injection.

0:04:31.900000 --> 0:04:36.140000
 So let's now turn our attention
 to second order SQL injection.

0:04:36.140000 --> 0:04:38.960000
 But before we do that, I'm just, you
 know, I have an example here that

0:04:38.960000 --> 0:04:42.800000
 sort of explains everything that all
 the SQL injection vulnerabilities

0:04:42.800000 --> 0:04:47.660000
 that we've exploited, you know, up
 to this point, which all, you know,

0:04:47.660000 --> 0:04:49.960000
 traditionally fall under first order.

0:04:49.960000 --> 0:04:54.280000
 So in this case, we have an attacker
 and then there's the victim site.

0:04:54.280000 --> 0:04:58.300000
 And the bottom line is, you know, you
 can see that it's fairly simple

0:04:58.300000 --> 0:05:00.740000
 in terms of the flow or the steps.

0:05:00.740000 --> 0:05:04.720000
 So firstly, the attacker submits or
 injects a malicious payload into a

0:05:04.720000 --> 0:05:09.200000
 vulnerable application input or an injection
 point, so a login form, so

0:05:09.200000 --> 0:05:11.580000
 on and so forth, URL parameter.

0:05:11.580000 --> 0:05:15.440000
 Secondly, the target application processes
 the input and executes the

0:05:15.440000 --> 0:05:19.600000
 injected query, if, you know,
 there's no sanitization.

0:05:19.600000 --> 0:05:23.980000
 And you know, the queries is going
 to be the execution of the query is

0:05:23.980000 --> 0:05:25.200000
 going to involve the database.

0:05:25.200000 --> 0:05:29.020000
 But regardless, you know, the application
 executes the injected query,

0:05:29.020000 --> 0:05:33.240000
 or it tells the database to
 essentially execute it.

0:05:33.240000 --> 0:05:37.440000
 The key point is that the results of
 the executed query or evidence of

0:05:37.440000 --> 0:05:42.520000
 its execution, evidence of its execution
 being a blind SQL injection stuff

0:05:42.520000 --> 0:05:47.580000
 like that, where you're not told directly
 by the web application that,

0:05:47.580000 --> 0:05:50.460000
 hey, yes, I am indeed vulnerable.

0:05:50.460000 --> 0:05:56.940000
 But you're able to use, let's say, blind,
 time-based payloads to essentially

0:05:56.940000 --> 0:06:01.780000
 monitor the response of the web application
 that indirectly tells you

0:06:01.780000 --> 0:06:06.720000
 that, yes, your payload is executed
 because you told the database to to

0:06:06.720000 --> 0:06:10.660000
 sleep or you gave it quite a lengthy
 arithmetic operation that led to

0:06:10.660000 --> 0:06:14.880000
 an increase or a longer processing time.

0:06:14.880000 --> 0:06:19.980000
 The bottom line is that you get direct
 feedback or information leakage

0:06:19.980000 --> 0:06:23.480000
 depending on the type of vulnerability
 exploiting or the payload you're

0:06:23.480000 --> 0:06:32.060000
 using. Okay, so this injection scenario,
 you know, first order SQL injection

0:06:32.060000 --> 0:06:37.680000
 has a more advanced counterpart, which
 I've been, I've been mentioning,

0:06:37.680000 --> 0:06:39.780000
 and that second order SQL injection.

0:06:39.780000 --> 0:06:45.800000
 Now, what sets this, what sets this
 particular technique apart is the

0:06:45.800000 --> 0:06:51.540000
 altered sequence of events, where the
 payload's impact is delayed until

0:06:51.540000 --> 0:06:54.940000
 a later stage of the application's
 workflow.

0:06:54.940000 --> 0:06:58.120000
 All right, now in the next couple of
 slides, we're going to explore how

0:06:58.120000 --> 0:07:01.960000
 this scenario unfolds and examine
 a typical use case.

0:07:01.960000 --> 0:07:05.360000
 So that brings us to second
 order SQL injection.

0:07:05.360000 --> 0:07:09.100000
 And first things, first, we need to
 understand what it is, technically

0:07:09.100000 --> 0:07:13.960000
 speaking. So second order SQL injection
 is a type of SQL injection where

0:07:13.960000 --> 0:07:18.800000
 the malicious payload is not immediately
 executed upon initial injection.

0:07:18.800000 --> 0:07:23.640000
 Instead, it is stored in the database
 and executed later when a different

0:07:23.640000 --> 0:07:28.520000
 query, and this is the key when a another
 query or functionality of the

0:07:28.520000 --> 0:07:30.460000
 application processes it.

0:07:30.460000 --> 0:07:34.980000
 So this type of attack exploit scenarios
 where user inputs are sanitized

0:07:34.980000 --> 0:07:39.980000
 during the initial query, but are later
 used unsanitized in a subsequent

0:07:39.980000 --> 0:07:41.500000
 database operation.

0:07:41.500000 --> 0:07:45.740000
 Now this is usually the part or the
 point of which the, you know, the,

0:07:45.740000 --> 0:07:53.720000
 this is the point that really, or the,
 the phase or the step, if you will,

0:07:53.720000 --> 0:07:55.460000
 that really confuses people.

0:07:55.460000 --> 0:08:00.340000
 And that's to do with the fact that,
 you know, the second query is the

0:08:00.340000 --> 0:08:05.060000
 one that actually does the injection
 for us or executes the, the original

0:08:05.060000 --> 0:08:08.640000
 malicious query that we injected prior.

0:08:08.640000 --> 0:08:10.640000
 But don't worry, it'll
 actually make sense.

0:08:10.640000 --> 0:08:14.660000
 So this is what second order SQL injection
 looks like, you know, on the

0:08:14.660000 --> 0:08:18.980000
 right, you have a diagram or an attack
 flow diagram that sort of explains

0:08:18.980000 --> 0:08:21.540000
 it. But let me go through
 the steps first.

0:08:21.540000 --> 0:08:25.180000
 So firstly, the attacker submits his malicious
 request, his or her malicious

0:08:25.180000 --> 0:08:29.280000
 request. So just think of you
 injecting a payload, right?

0:08:29.280000 --> 0:08:33.960000
 Now what happens is that the application
 stores that input instead of,

0:08:33.960000 --> 0:08:36.260000
 you know, that input being executed.

0:08:36.260000 --> 0:08:41.720000
 So it's not really a query, it could
 be a part of a query that you later,

0:08:41.720000 --> 0:08:46.320000
 that the application later completes
 as part of another query.

0:08:46.320000 --> 0:08:49.140000
 And this is typically a legitimate query.


0:08:49.140000 --> 0:08:53.300000
 But again, let's just keep
 things simple for now.

0:08:53.300000 --> 0:08:57.180000
 So the third part or the third step
 in, you know, is where the attacker

0:08:57.180000 --> 0:08:59.160000
 submits another request.

0:08:59.160000 --> 0:09:02.900000
 This can either be done by the attacker
 or it could be done by let's say

0:09:02.900000 --> 0:09:08.320000
 an admin, the bottom line is that this
 second request, and I'll use the

0:09:08.320000 --> 0:09:11.820000
 explanation yet to handle the second
 request, the application retrieves

0:09:11.820000 --> 0:09:17.160000
 the previously stored input that let's
 say had a part of a SQL query.

0:09:17.160000 --> 0:09:21.180000
 And this time, the attackers
 injected query is executed.

0:09:21.180000 --> 0:09:24.780000
 The results of the query are returned
 in some way to the attacker.

0:09:24.780000 --> 0:09:31.260000
 So what's going on is again, just think
 of standard first order SQL injection.

0:09:31.260000 --> 0:09:36.740000
 However, in this case, what you're
 doing is your again, we'll use the

0:09:36.740000 --> 0:09:40.380000
 example of a log in form or registration
 form, a registration form being

0:09:40.380000 --> 0:09:44.300000
 the best example or the best
 way to explain this.

0:09:44.300000 --> 0:09:48.780000
 So the registration form only has your
 email and password, let's say,

0:09:48.780000 --> 0:09:53.320000
 okay. So typically, with first order,
 you would try and inject, let's

0:09:53.320000 --> 0:09:56.520000
 say, in the password and your injection
 of the payload would be a query

0:09:56.520000 --> 0:10:01.020000
 that you'd expect the database
 to process almost immediately.

0:10:01.020000 --> 0:10:04.800000
 However, let's say there is
 some sanitization of input.

0:10:04.800000 --> 0:10:09.340000
 And as a result, you use, let's say,
 the second part of the of the payload

0:10:09.340000 --> 0:10:11.840000
 that you would have used in first order.

0:10:11.840000 --> 0:10:17.740000
 And as a result, you know, the the
 web application says, hey, there's

0:10:17.740000 --> 0:10:18.700000
 nothing wrong with this.

0:10:18.700000 --> 0:10:20.040000
 It looks fine to me.

0:10:20.040000 --> 0:10:20.900000
 And it saves it.

0:10:20.900000 --> 0:10:25.960000
 It saves that second part of
 the query in the database.

0:10:25.960000 --> 0:10:32.000000
 So now the idea is to either, you know,
 you being the attacker, or you

0:10:32.000000 --> 0:10:36.960000
 know, if you play, or if you take this
 role as the attacker, to then make

0:10:36.960000 --> 0:10:44.620000
 a second request to the web application
 that then uses a, uses a query

0:10:44.620000 --> 0:10:51.880000
 that actually interacts with or executes
 that query that was saved in

0:10:51.880000 --> 0:10:56.120000
 the database. Now again, this may be
 a bit complicated to understand,

0:10:56.120000 --> 0:10:58.640000
 but I'll, you, I'll use some
 very detailed examples.

0:10:58.640000 --> 0:11:02.680000
 So you get it. So again, malicious
 request stored input.

0:11:02.680000 --> 0:11:04.080000
 Okay, done. Okay.

0:11:04.080000 --> 0:11:05.340000
 That's the first part.

0:11:05.340000 --> 0:11:09.440000
 And the second is where you, you or
 any other user or the application

0:11:09.440000 --> 0:11:12.980000
 somehow sends a request.

0:11:12.980000 --> 0:11:20.080000
 And the, you can see right of the rescue
 input and execute the query.

0:11:20.080000 --> 0:11:24.440000
 And what is executed really
 is what was saved.

0:11:24.440000 --> 0:11:28.400000
 But as I said, typically it's going
 to be, you know, the second part of

0:11:28.400000 --> 0:11:34.760000
 an initial payload that then is combined
 with another one or a legitimate

0:11:34.760000 --> 0:11:38.760000
 query that the web application makes
 in order to again facilitate the

0:11:38.760000 --> 0:11:45.640000
 injection. So that brings us to, you
 know, to the point, how does this

0:11:45.640000 --> 0:11:49.260000
 work? And when I say this, I know you
 probably understood it with a previous

0:11:49.260000 --> 0:11:52.840000
 slide, but we need to look at it from
 a methodological point of view.

0:11:52.840000 --> 0:11:56.740000
 So the way I see it is we have the injection
 phase and then the triggering

0:11:56.740000 --> 0:11:58.220000
 phase and then impact.

0:11:58.220000 --> 0:12:01.680000
 So injection phase, this is where the
 attack identifies just like first

0:12:01.680000 --> 0:12:06.320000
 order, a vulnerable input field in the
 application, the injected payload

0:12:06.320000 --> 0:12:10.200000
 is stored in the database without
 being executed immediately.

0:12:10.200000 --> 0:12:14.660000
 Okay. The triggering phase is where, you
 know, at a later point, the application

0:12:14.660000 --> 0:12:19.400000
 somehow either invoked by you as the
 attacker or let's say by an admin,

0:12:19.400000 --> 0:12:23.060000
 retrieves the stored data and uses it
 in another database query without

0:12:23.060000 --> 0:12:24.520000
 proper sanitization.

0:12:24.520000 --> 0:12:30.340000
 So the key point is that because this
 query, the second query or this

0:12:30.340000 --> 0:12:34.760000
 other query not related to the initial
 one, like, you know, the one used

0:12:34.760000 --> 0:12:39.040000
 for registration, because this one is
 let's say not exposed to the public,

0:12:39.040000 --> 0:12:44.160000
 it may lack that sanitization that prevents
 it from loading another query.

0:12:44.160000 --> 0:12:49.160000
 So you actually, you're trying to look
 for those embedded queries within

0:12:49.160000 --> 0:12:52.680000
 the back end of the web application
 that let's say as a standard user,

0:12:52.680000 --> 0:12:54.620000
 you would not be able to interact with.

0:12:54.620000 --> 0:12:57.700000
 And you're taking advantage of the, you
 know, of the fact that the developers,

0:12:57.700000 --> 0:13:00.760000
 you know, would have thought to themselves,
 well, no one's ever going

0:13:00.760000 --> 0:13:01.900000
 to interact with this query.

0:13:01.900000 --> 0:13:04.640000
 We don't need to have any sanitization.

0:13:04.640000 --> 0:13:09.200000
 Now, the issue is that, you know, if
 that particular query is pulling

0:13:09.200000 --> 0:13:15.720000
 data from, let's say the user's table,
 and you stored part of or, you

0:13:15.720000 --> 0:13:21.400000
 know, a specific payload as a password
 of a user, and, you know, this

0:13:21.400000 --> 0:13:26.380000
 particular payload does something else,
 then, you know, that, the second

0:13:26.380000 --> 0:13:31.800000
 query, if not sanitized, will actually
 execute what was saved as a password,

0:13:31.800000 --> 0:13:38.040000
 right? And the bottom line is that,
 and we'll go into the example, this

0:13:38.040000 --> 0:13:44.520000
 initial payload or query that you inject
 really isn't a complete query,

0:13:44.520000 --> 0:13:48.640000
 because again, remember, you don't
 want it to be injected first.

0:13:48.640000 --> 0:13:52.840000
 Otherwise, that standard first order,
 the bottom line and the typical

0:13:52.840000 --> 0:13:57.740000
 examples, or, you know, if you if you
 take a look at various bug bounty

0:13:57.740000 --> 0:14:04.120000
 reports, you'll actually see that it's
 really just using injecting, let's

0:14:04.120000 --> 0:14:09.080000
 say, the second or a segment of the
 query that you wanted to inject, and

0:14:09.080000 --> 0:14:13.540000
 then getting the web application to
 use, let's say, a legitimate query

0:14:13.540000 --> 0:14:18.120000
 that you then, you know, interrupt and
 then execute the one you initially

0:14:18.120000 --> 0:14:22.920000
 injected. So the impact of this is
 just like that of first order, you

0:14:22.920000 --> 0:14:27.320000
 know, data leakage privilege escalation
 or system compromise, you know,

0:14:27.320000 --> 0:14:31.180000
 depending on the query's response
 or the payload that you use.

0:14:31.180000 --> 0:14:35.540000
 So let me use a technical example
 here that will make sense.

0:14:35.540000 --> 0:14:39.680000
 So in this case, we have a scenario,
 right, an example scenario, where

0:14:39.680000 --> 0:14:44.220000
 a web application has a registration
 feature or a registration form that

0:14:44.220000 --> 0:14:47.080000
 stores user information
 in a database, right?

0:14:47.080000 --> 0:14:52.020000
 Now, later on, an admin panel fetches user
 details for display or validation.

0:14:52.020000 --> 0:14:55.560000
 So let's say you had a web app where
 you allow users to register and you

0:14:55.560000 --> 0:14:58.400000
 also have admin functionality
 or an admin panel.

0:14:58.400000 --> 0:15:04.980000
 Now, this admin panel fetches this
 user information like the username,

0:15:04.980000 --> 0:15:09.320000
 password, etc. So the vulnerable workflow
 or the vulnerability that you're

0:15:09.320000 --> 0:15:14.400000
 looking for here is let's say the application
 sanitize sanitize's input

0:15:14.400000 --> 0:15:16.260000
 during registration, right?

0:15:16.260000 --> 0:15:20.240000
 So let's say you can do any injection
 there because, you know, the it

0:15:20.240000 --> 0:15:22.760000
 escapes special characters, for example.

0:15:22.760000 --> 0:15:28.420000
 However, the application retrieves and
 concatenates the stored user input

0:15:28.420000 --> 0:15:33.320000
 unsafely in subsequent queries that
 let's say require that information.

0:15:33.320000 --> 0:15:39.340000
 So an admin panel, when you click on
 view, view all users on the site,

0:15:39.340000 --> 0:15:45.080000
 then that query would be pulling information
 from the user's table.

0:15:45.080000 --> 0:15:48.800000
 And that's really what you're interested
 in, you know, is how that second

0:15:48.800000 --> 0:15:52.540000
 query accesses, you know,
 the data in there.

0:15:52.540000 --> 0:15:58.360000
 And if it accesses, let's say the password
 and that password value or

0:15:58.360000 --> 0:16:04.240000
 what you set is, let's say, is a query
 that, you know, will be completed

0:16:04.240000 --> 0:16:08.700000
 by this query, the admin panel query,
 then it could be injected.

0:16:08.700000 --> 0:16:11.160000
 Anyway, I know I'm confusing you.

0:16:11.160000 --> 0:16:13.900000
 We move to stage two, you know,
 the actual injection.

0:16:13.900000 --> 0:16:20.020000
 So what the attacker does is he does
 not use, you know, the standard SQL

0:16:20.020000 --> 0:16:24.060000
 injection payload, he uses he registers
 for an account with the malicious

0:16:24.060000 --> 0:16:27.000000
 username. And this is what he provides.

0:16:27.000000 --> 0:16:29.180000
 So drop table users.

0:16:29.180000 --> 0:16:34.240000
 Okay. And it's very clear what this
 SQL query does is it deletes the,

0:16:34.240000 --> 0:16:38.280000
 it deletes the user's table, right?

0:16:38.280000 --> 0:16:42.880000
 So this registration forms, sanitizes
 the input and stores it as a string.

0:16:42.880000 --> 0:16:45.820000
 Okay. So just keep that in mind.

0:16:45.820000 --> 0:16:50.500000
 Now the triggering phase is, in this
 case, it's going to be an admin that

0:16:50.500000 --> 0:16:52.680000
 will trigger the actual injection.

0:16:52.680000 --> 0:16:56.200000
 So when an admin views the user's details
 in the admin panel, the application

0:16:56.200000 --> 0:17:02.740000
 concatenates the stored username into a
 new query without proper sanitization.

0:17:02.740000 --> 0:17:08.100000
 So this is the query that the admin
 panel would be using to list users.

0:17:08.100000 --> 0:17:11.740000
 So select all from users where username,
 let's say they clicked on a specific

0:17:11.740000 --> 0:17:17.720000
 user. And if you injected your, you
 know, the initial payload that again

0:17:17.720000 --> 0:17:21.360000
 was not processed by the database, you
 can now see because of the inbuilt

0:17:21.360000 --> 0:17:27.800000
 concatenation, it actually treats this
 as a separate SQL query that will

0:17:27.800000 --> 0:17:29.900000
 then delete the user's table.

0:17:29.900000 --> 0:17:33.440000
 So the bottom line is that the malicious
 payload is executed because you're

0:17:33.440000 --> 0:17:38.260000
 now combining both of these queries or
 you're letting another query execute

0:17:38.260000 --> 0:17:43.880000
 this, this payload or query that you
 initially injected, but because of

0:17:43.880000 --> 0:17:47.300000
 all the web application
 works, it sanitized it.

0:17:47.300000 --> 0:17:52.500000
 But then, because there's no sanitization
 for this query, it actually

0:17:52.500000 --> 0:17:58.140000
 gets executed. So you're trying to again
 leverage another query made by

0:17:58.140000 --> 0:18:02.060000
 the web application, not related to
 this one directly, to do the bidding

0:18:02.060000 --> 0:18:07.480000
 for you. And this is where the whole
 idea of, or this is the, where the

0:18:07.480000 --> 0:18:11.020000
 distinction between first and
 second order comes into play.

0:18:11.020000 --> 0:18:14.040000
 And when I was referencing immediate,
 this is what I meant.

0:18:14.040000 --> 0:18:19.340000
 So with second order, again, you can
 actually invoke the web application

0:18:19.340000 --> 0:18:21.240000
 to make the second query.

0:18:21.240000 --> 0:18:24.640000
 But generally speaking, could be
 done by an admin or another user.

0:18:24.640000 --> 0:18:29.200000
 The bottom line is that this other query
 essentially allows for the injection

0:18:29.200000 --> 0:18:33.780000
 of the initial query that you saved that
 was not executed by the database.

0:18:33.780000 --> 0:18:37.940000
 You know, one of the reasons for that
 is sanitization, as you can see

0:18:37.940000 --> 0:18:42.300000
 here. So this is what it
 looks like visualized.

0:18:42.300000 --> 0:18:45.040000
 So the attacker submits the following
 username during registration.

0:18:45.040000 --> 0:18:47.400000
 So a standard query that is legitimate.

0:18:47.400000 --> 0:18:52.620000
 However, because the web application
 is secure quote unquote, it saved

0:18:52.620000 --> 0:18:55.240000
 as a username or as a
 string, I should say.

0:18:55.240000 --> 0:18:59.380000
 So later on, when an admin fetches
 the user details with the following

0:18:59.380000 --> 0:19:02.240000
 query, or that page makes this query.

0:19:02.240000 --> 0:19:05.960000
 So select all from users where username
 is equal to expecting a username

0:19:05.960000 --> 0:19:09.340000
 from the user's table.

0:19:09.340000 --> 0:19:15.300000
 Instead of that, what what happens is
 because of the payload we injected,

0:19:15.300000 --> 0:19:18.500000
 you can see terminates that there.

0:19:18.500000 --> 0:19:25.880000
 And then it, it, it essentially executes
 this particular query here that

0:19:25.880000 --> 0:19:28.720000
 pretty much deletes the user's table.

0:19:28.720000 --> 0:19:33.540000
 So this is in essence, and this is
 one of the examples I really like.

0:19:33.540000 --> 0:19:36.580000
 This is how second order
 SQL injection works.

0:19:36.580000 --> 0:19:40.800000
 Now, in this case, I'm using this is
 quite an advanced example, because

0:19:40.800000 --> 0:19:44.860000
 again, I would have liked to start over
 the basic one, but the practical

0:19:44.860000 --> 0:19:49.420000
 demo that I'll give you in a few seconds
 is going to be fairly basic in

0:19:49.420000 --> 0:19:51.280000
 terms of how the backend works.

0:19:51.280000 --> 0:19:54.320000
 But you'll actually understand
 it a whole lot better.

0:19:54.320000 --> 0:19:59.460000
 So with that being said, before we end
 the video, I'm going to give you

0:19:59.460000 --> 0:20:00.520000
 a practical demo.

0:20:00.520000 --> 0:20:03.960000
 Now it's not going to be in the
 form of a lab that you can play.

0:20:03.960000 --> 0:20:08.000000
 It's just within my local environment,
 I've set up a web app to demonstrate

0:20:08.000000 --> 0:20:12.280000
 this. It's not really important
 that you try this out yourself.

0:20:12.280000 --> 0:20:15.660000
 And you, you, you'll actually see why
 in a few seconds, because in order

0:20:15.660000 --> 0:20:19.880000
 for you to do this, you actually need
 to understand fairly well how the

0:20:19.880000 --> 0:20:21.160000
 web application works.

0:20:21.160000 --> 0:20:25.000000
 So I'm going to switch over into my
 Kali Linux system, and I'll show you

0:20:25.000000 --> 0:20:27.960000
 the web app and I'll sort
 of explain how it works.

0:20:27.960000 --> 0:20:30.820000
 So I'll see you there in
 a couple of seconds.

0:20:30.820000 --> 0:20:35.020000
 All right, so I'm currently
 within my Kali Linux system.

0:20:35.020000 --> 0:20:37.800000
 And I've just started
 up the web app here.

0:20:37.800000 --> 0:20:41.820000
 It's a very simple flask web
 app that has two endpoints.

0:20:41.820000 --> 0:20:46.240000
 So it has a register,
 a registration portal.

0:20:46.240000 --> 0:20:48.580000
 And you can see it's as basic as can be.

0:20:48.580000 --> 0:20:52.740000
 So there's a username field and a bio
 field bio being, you know, the user's

0:20:52.740000 --> 0:20:55.920000
 biography, or just a short
 description about you.

0:20:55.920000 --> 0:21:01.400000
 And then you also have the ability to
 view the details of a specific profile

0:21:01.400000 --> 0:21:04.400000
 or user. So you can say profile
 and then the name of the user.

0:21:04.400000 --> 0:21:09.540000
 So there was a, you know, if I created
 the user Lexis, I'll be able to

0:21:09.540000 --> 0:21:11.900000
 see that that there now.

0:21:11.900000 --> 0:21:14.400000
 That's really not what
 I'm referring to here.

0:21:14.400000 --> 0:21:19.000000
 So the way this works or the way the
 web application works is the first

0:21:19.000000 --> 0:21:28.520000
 part is going to involve the registration
 form where we will specify a

0:21:28.520000 --> 0:21:30.160000
 legitimate username.

0:21:30.160000 --> 0:21:33.380000
 And in the bio, we will be
 injecting our payloads.

0:21:33.380000 --> 0:21:39.000000
 Now these payloads will only be or
 can only be executed by the admin.

0:21:39.000000 --> 0:21:43.700000
 And the admin only is the only user again
 for the purposes of this example,

0:21:43.700000 --> 0:21:48.700000
 who has access to the profile, the profile
 functionality that allows you

0:21:48.700000 --> 0:21:52.660000
 to view the details of a specific user.

0:21:52.660000 --> 0:21:57.840000
 So the input that's injectable
 is bio as I mentioned.

0:21:57.840000 --> 0:22:03.880000
 So the way to it will work is because of
 how the the registration functionality

0:22:03.880000 --> 0:22:09.620000
 works is when you register and let's
 say injected a payload in here, a

0:22:09.620000 --> 0:22:12.340000
 legitimate one is not
 going to be processed.

0:22:12.340000 --> 0:22:15.900000
 Okay, just I'll get into
 the vulnerable code.

0:22:15.900000 --> 0:22:17.940000
 But again, nothing's going to happen.

0:22:17.940000 --> 0:22:21.600000
 So it's not going to be executed
 by the database.

0:22:21.600000 --> 0:22:26.900000
 However, it's going to be stored as
 is in the database, which means we

0:22:26.900000 --> 0:22:31.320000
 can then, and this is the second
 order part as an admin.

0:22:31.320000 --> 0:22:35.880000
 When the admin tries to view your details,
 because the bio information

0:22:35.880000 --> 0:22:42.800000
 is included in that page, that
 query will be processed.

0:22:42.800000 --> 0:22:45.920000
 So whatever that query does
 will then be processed.

0:22:45.920000 --> 0:22:48.660000
 So I'll just show you all
 the web application work.

0:22:48.660000 --> 0:22:53.700000
 So let's say I create a user, you know,
 user called Alexis and I say hello.

0:22:53.700000 --> 0:22:58.480000
 Okay. So I can just say username, Alexis
 bio, hello, there's nothing injected.

0:22:58.480000 --> 0:23:00.380000
 I click on register.

0:23:00.380000 --> 0:23:02.620000
 And now I'm going to simulate
 being the admin.

0:23:02.620000 --> 0:23:06.860000
 Okay. So just for the purposes of this
 demo, just think I'm now the admin

0:23:06.860000 --> 0:23:09.140000
 or just think of me as the admin now.

0:23:09.140000 --> 0:23:14.140000
 So the admin would typically go to profile
 and then, you know, let's say

0:23:14.140000 --> 0:23:18.620000
 they clicked on the user Alexis, when
 they click on the user, Alexis,

0:23:18.620000 --> 0:23:21.660000
 the info for the user
 Alexis is displayed.

0:23:21.660000 --> 0:23:27.060000
 So the profile name or the username
 and the bio or whatever was put in

0:23:27.060000 --> 0:23:28.420000
 on the web page.

0:23:28.420000 --> 0:23:30.780000
 So I think you're starting
 to get the idea.

0:23:30.780000 --> 0:23:35.100000
 Okay. So now what I'm going to do is
 I'm going to keep this tab as the

0:23:35.100000 --> 0:23:37.840000
 admin. And this one is the attacker.

0:23:37.840000 --> 0:23:39.820000
 So I'll now go back into register.

0:23:39.820000 --> 0:23:43.340000
 And I'm going to show you how
 this injection will work.

0:23:43.340000 --> 0:23:47.780000
 So the other thing to that I want to
 mention is that there's no filtering

0:23:47.780000 --> 0:23:52.860000
 or sanitization, if you will, during
 the registration, which means I can

0:23:52.860000 --> 0:23:57.060000
 just specify direct SQL queries, the
 only difference is there'll be not

0:23:57.060000 --> 0:23:58.760000
 they'll not be executed.

0:23:58.760000 --> 0:24:03.920000
 They can only be executed when the admin
 views the profile information.

0:24:03.920000 --> 0:24:10.520000
 So for example, if we use the payload,
 you know, select database, that'll

0:24:10.520000 --> 0:24:14.960000
 essentially give, tell
 us the database name.

0:24:14.960000 --> 0:24:18.740000
 And again, you don't need to think
 of the second bit as being done by

0:24:18.740000 --> 0:24:23.160000
 the admin. It could also be a page.

0:24:23.160000 --> 0:24:31.300000
 So I'll create a username here called,
 we'll just call this user.

0:24:31.300000 --> 0:24:33.840000
 Let's just call it one.

0:24:33.840000 --> 0:24:36.340000
 Okay. Or for the first example.

0:24:36.340000 --> 0:24:40.660000
 So one, and then in the bio, I'll just
 use the payload select database.

0:24:40.660000 --> 0:24:42.900000
 So this will not be executed here.

0:24:42.900000 --> 0:24:47.500000
 It can only be executed, you know, second
 order, if you will, by the admin

0:24:47.500000 --> 0:24:51.780000
 or, you know, by you as the attacker,
 if you had access to the part of

0:24:51.780000 --> 0:24:56.980000
 the web application that, you know, used
 a different query that then executed

0:24:56.980000 --> 0:25:01.680000
 this one. So one, remember the username,
 so we'll click on register.

0:25:01.680000 --> 0:25:05.740000
 And now when the admin or, you know,
 even the attacker tries to view this

0:25:05.740000 --> 0:25:10.820000
 page, so profile instead of
 Alexis, we click on one.

0:25:10.820000 --> 0:25:13.940000
 What happens here is you can
 see the queries displayed.

0:25:13.940000 --> 0:25:17.440000
 However, and I just developed
 the web app to do this.

0:25:17.440000 --> 0:25:20.380000
 It actually, you know, displays the
 string SQL injection results.

0:25:20.380000 --> 0:25:24.500000
 And it tells us the name of the database,
 which is what that payload or

0:25:24.500000 --> 0:25:29.320000
 query does. So the bottom line is that
 another query is actually executing

0:25:29.320000 --> 0:25:33.740000
 that initial one that was saved in the
 database, but not executed during

0:25:33.740000 --> 0:25:37.660000
 registration. If it was, then
 that would be first order.

0:25:37.660000 --> 0:25:41.840000
 But because it relies on a second
 query, it's now second order.

0:25:41.840000 --> 0:25:43.400000
 Hopefully that makes sense.

0:25:43.400000 --> 0:25:49.300000
 And again, this need not be done by,
 you know, this need not be triggered

0:25:49.300000 --> 0:25:52.900000
 by an admin. It could also
 be done by the attacker.

0:25:52.900000 --> 0:25:57.860000
 The bottom line is you rely on this
 second query or this other bit of

0:25:57.860000 --> 0:26:02.300000
 web application functionality to then
 execute the initial one that was

0:26:02.300000 --> 0:26:03.100000
 saved in the database.

0:26:03.100000 --> 0:26:08.380000
 So let's say I wanted to this, I wanted
 to list out all the tables in

0:26:08.380000 --> 0:26:09.560000
 the current database.

0:26:09.560000 --> 0:26:13.980000
 So what I would do is let's say I create
 a new user here, and we'll just

0:26:13.980000 --> 0:26:17.200000
 call this user to for the second example.


0:26:17.200000 --> 0:26:18.920000
 So this query, it's quite long.

0:26:18.920000 --> 0:26:21.960000
 You can see it right over
 here will list out.

0:26:21.960000 --> 0:26:26.180000
 So you can see select group concatenate
 table name from information schema.

0:26:26.180000 --> 0:26:29.400000
 This will just list out all tables
 in the current database.

0:26:29.400000 --> 0:26:35.380000
 So I now register, you can see no processing,
 but now the admin or you

0:26:35.380000 --> 0:26:39.260000
 as the attacker goes and let's say when
 you view your profile, which then

0:26:39.260000 --> 0:26:44.480000
 uses the second query, that'll then
 execute the initial query or payload

0:26:44.480000 --> 0:26:48.280000
 that was saved in the database,
 you'll see right over here.

0:26:48.280000 --> 0:26:53.340000
 Because of our design, it just displays
 the actual query or the bio what

0:26:53.340000 --> 0:26:54.340000
 was saved in the bio.

0:26:54.340000 --> 0:26:56.520000
 But you can see SQL injection results.

0:26:56.520000 --> 0:27:02.140000
 It actually says that your current table
 or all the tables in the current,

0:27:02.140000 --> 0:27:05.860000
 you know, this query lists out all
 the tables in the current database.

0:27:05.860000 --> 0:27:09.660000
 In this case, you only have
 one table which is users.

0:27:09.660000 --> 0:27:15.060000
 Okay, now, what if I wanted to retrieve
 the current MySQL user?

0:27:15.060000 --> 0:27:19.200000
 Well, again, and I know that these
 payloads are just SQL queries, but

0:27:19.200000 --> 0:27:22.780000
 you know, without any delimiters or
 anything like that, but this is the

0:27:22.780000 --> 0:27:24.380000
 best way to understand it.

0:27:24.380000 --> 0:27:28.460000
 So I'll now register another user, and
 I'll call this user three for the

0:27:28.460000 --> 0:27:30.700000
 third example that I'm
 going to give here.

0:27:30.700000 --> 0:27:33.240000
 And in this case, we're just going
 to use the query select user.

0:27:33.240000 --> 0:27:38.440000
 So register. And now when that second
 query is executed, it then executes

0:27:38.440000 --> 0:27:41.380000
 that in initial query or
 payload that we injected.

0:27:41.380000 --> 0:27:43.360000
 So I'll say three.

0:27:43.360000 --> 0:27:47.580000
 And as expected, it actually tells
 us our current user or the current

0:27:47.580000 --> 0:27:49.340000
 MySQL database user.

0:27:49.340000 --> 0:27:52.500000
 So root at local host or whatever.

0:27:52.500000 --> 0:27:55.920000
 So that's pretty much second
 order SQL injection.

0:27:55.920000 --> 0:27:56.720000
 That's really it.

0:27:56.720000 --> 0:27:59.400000
 It's it's it's nothing too
 advanced or complicated.

0:27:59.400000 --> 0:28:03.940000
 As I said, it's really, it's really down
 to how the target web application

0:28:03.940000 --> 0:28:09.240000
 is configured. And you know, how data
 is stored in the database and you

0:28:09.240000 --> 0:28:13.480000
 know, what other queries interact with
 the data in, in let's say, you

0:28:13.480000 --> 0:28:17.720000
 know, a different and let's say different
 table, but I can give you a

0:28:17.720000 --> 0:28:20.180000
 couple of other examples.

0:28:20.180000 --> 0:28:26.300000
 If I wanted to dump all usernames and
 BIOS, I can now create another account

0:28:26.300000 --> 0:28:28.320000
 here called for.

0:28:28.320000 --> 0:28:34.200000
 So we'll just say for like so, and
 this will dump all usernames.

0:28:34.200000 --> 0:28:38.700000
 This payload will dump
 all usernames and BIOS.

0:28:38.700000 --> 0:28:39.860000
 So I'll click register.

0:28:39.860000 --> 0:28:45.720000
 And now when that second query
 is executed, there we are.

0:28:45.720000 --> 0:28:47.020000
 So we get that here.

0:28:47.020000 --> 0:28:50.500000
 So all users and their BIOS or Lexis.

0:28:50.500000 --> 0:28:53.900000
 And then the user or the account
 one that we created.

0:28:53.900000 --> 0:28:59.660000
 And then let's see two and their
 BIOS are then displayed here.

0:28:59.660000 --> 0:29:01.680000
 So that's another example.

0:29:01.680000 --> 0:29:04.520000
 Let's do a couple more because
 this is always fun.

0:29:04.520000 --> 0:29:09.380000
 If I wanted to extract all usernames,
 where this was for so this would

0:29:09.380000 --> 0:29:14.520000
 be five example five, I can use this
 query right over here, that again

0:29:14.520000 --> 0:29:18.940000
 will not be executed by this
 registration page query.

0:29:18.940000 --> 0:29:22.560000
 So we'll just say registration and
 you can see it's successful as an I

0:29:22.560000 --> 0:29:26.440000
 say five. And you can see it
 lists out all the users.

0:29:26.440000 --> 0:29:31.580000
 So this is this is in essence,
 second order SQL injection.

0:29:31.580000 --> 0:29:34.980000
 All right, that's as simple as it is,
 you know, in terms of what's going

0:29:34.980000 --> 0:29:40.920000
 on. The key thing to understand is generally
 speaking, it's a different

0:29:40.920000 --> 0:29:46.760000
 query than the initial one that actually
 processes the initial query or

0:29:46.760000 --> 0:29:50.140000
 payload that you injected that
 was saved in the database.

0:29:50.140000 --> 0:29:53.140000
 So that pretty much brings us to the
 end of the practical demonstration

0:29:53.140000 --> 0:29:55.340000
 section of this video.

0:29:55.340000 --> 0:29:59.420000
 All right, so hopefully
 you found that useful.

0:29:59.420000 --> 0:30:03.120000
 And yeah, that was a second
 order SQL injection.

0:30:03.120000 --> 0:30:04.740000
 Hopefully that makes sense.

0:30:04.740000 --> 0:30:13.860000
 I will be again work on adding that lab
 as an INE lab, the one I developed

0:30:13.860000 --> 0:30:17.360000
 the web application so you can
 test it out for yourself.

0:30:17.360000 --> 0:30:22.460000
 But you can see that it was very easy
 for me to, you know, as a developer

0:30:22.460000 --> 0:30:27.320000
 or someone who worked as a developer
 previously to actually develop a

0:30:27.320000 --> 0:30:31.860000
 web application that is vulnerable
 to second order SQL injection.

0:30:31.860000 --> 0:30:34.340000
 With that being said, that's going
 to be it for this video.

0:30:34.340000 --> 0:30:36.640000
 And I will be seeing you
 in the next video.