WEBVTT

0:00:04.640000 --> 0:00:08.780000
 exploiting union based SQL
 injection vulnerabilities.

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

0:00:13.480000 --> 0:00:17.120000
 union based SQL injection vulnerabilities
 through a practical example.

0:00:17.120000 --> 0:00:20.680000
 So this video will have a lab
 environment attached to it.

0:00:20.680000 --> 0:00:24.600000
 And we're going to be using it to again,
 demonstrate the methodology and

0:00:24.600000 --> 0:00:28.800000
 the techniques behind union based
 SQL injection vulnerabilities.

0:00:28.800000 --> 0:00:31.440000
 Now, of course, the previous
 video was quite lengthy.

0:00:31.440000 --> 0:00:35.760000
 And that's because of the complexity
 or rather the multitude of steps

0:00:35.760000 --> 0:00:40.900000
 involved in not only identifying and exploiting
 a SQL injection vulnerability

0:00:40.900000 --> 0:00:44.740000
 in general, but in that case, an error
 base SQL injection vulnerability.

0:00:44.740000 --> 0:00:48.660000
 So we're going to be utilizing the info
 from that video and then taking

0:00:48.660000 --> 0:00:53.200000
 it into here and essentially
 using it where it applies.

0:00:53.200000 --> 0:00:56.420000
 Now, this may be a little bit confusing
 to you, but don't worry, everything

0:00:56.420000 --> 0:00:57.240000
 will make sense.

0:00:57.240000 --> 0:01:00.800000
 The only thing you need to come into
 this video knowing is that this is

0:01:00.800000 --> 0:01:03.940000
 still an in band SQL injection
 vulnerability.

0:01:03.940000 --> 0:01:07.520000
 So let's get started by taking a
 look at this hierarchy tree here.

0:01:07.520000 --> 0:01:10.400000
 So we've taken a look at error
 base SQL injection already.

0:01:10.400000 --> 0:01:13.940000
 And remember, union based, which is
 what we're taking a look at right

0:01:13.940000 --> 0:01:16.800000
 now, still falls under in band, right?

0:01:16.800000 --> 0:01:19.800000
 So I hope you're already familiar with
 what in band is, if not, I'll just

0:01:19.800000 --> 0:01:22.620000
 give you a brief description of it.

0:01:22.620000 --> 0:01:28.020000
 So an in band SQL injection vulnerability
 is where the the attacker utilizes

0:01:28.020000 --> 0:01:32.960000
 the same communication channel to perform
 the injection and retrieve the

0:01:32.960000 --> 0:01:38.800000
 results. So think back to the error
 base SQL injection video, where we

0:01:38.800000 --> 0:01:43.020000
 utilized or we found an application
 input, we injected our payload or

0:01:43.020000 --> 0:01:46.360000
 SQL query, and we got an output.

0:01:46.360000 --> 0:01:50.240000
 So don't focus on the what the output
 was, we just get a response from

0:01:50.240000 --> 0:01:52.780000
 the database in in band SQL injection.

0:01:52.780000 --> 0:01:57.300000
 The response from the database is performed
 through the same communication

0:01:57.300000 --> 0:01:59.840000
 channel. What am I saying here?

0:01:59.840000 --> 0:02:04.520000
 If you performed the SQL injection attack
 via an input point on the web

0:02:04.520000 --> 0:02:08.600000
 application, in in band SQL injection,
 the results will be returned typically

0:02:08.600000 --> 0:02:10.260000
 to the same page.

0:02:10.260000 --> 0:02:14.080000
 And the data will be returned or displayed
 on the same page where you

0:02:14.080000 --> 0:02:16.020000
 performed the injection.

0:02:16.020000 --> 0:02:20.120000
 With blind SQL injection, no errors
 are displayed on the web page where

0:02:20.120000 --> 0:02:21.480000
 you made the injection.

0:02:21.480000 --> 0:02:24.540000
 That's why it's called blind in that
 you're not aware of whether your

0:02:24.540000 --> 0:02:27.200000
 query was successfully executed or not.

0:02:27.200000 --> 0:02:32.420000
 And that's why you have to resort to
 more heuristic based techniques in

0:02:32.420000 --> 0:02:36.400000
 order to monitor that, like using Boolean's,
 and you'll actually see what

0:02:36.400000 --> 0:02:39.940000
 that looks like, as well as time-based
 SQL injection, where you monitor

0:02:39.940000 --> 0:02:45.860000
 the time taken by the web page
 to respond to your query.

0:02:45.860000 --> 0:02:48.680000
 And that tells you, you know, whether
 your query was executed successfully.

0:02:48.680000 --> 0:02:52.340000
 So the point I'm making here is we
 there are based, we're essentially

0:02:52.340000 --> 0:02:55.160000
 using payloads that would invoke an
 error and then, you know, building

0:02:55.160000 --> 0:02:58.600000
 from there. And I, you know, we took
 a look at the exploitation and what

0:02:58.600000 --> 0:03:02.160000
 we can do with the vulnerability is pretty
 much going to be the same from

0:03:02.160000 --> 0:03:04.300000
 a high level category perspective.

0:03:04.300000 --> 0:03:07.840000
 But we're just using a different
 set of payloads.

0:03:07.840000 --> 0:03:11.720000
 So this is where the the exploitation
 technique differs.

0:03:11.720000 --> 0:03:16.320000
 All right, so let me introduce you
 to union-based SQL injection.

0:03:16.320000 --> 0:03:21.260000
 I sort of gave you a brief introduction
 in the, the types of SQL injection

0:03:21.260000 --> 0:03:22.980000
 vulnerabilities video.

0:03:22.980000 --> 0:03:24.440000
 But let me reintroduce it here.

0:03:24.440000 --> 0:03:29.340000
 So as the name suggests, union-based SQL
 injection is a type of SQL injection

0:03:29.340000 --> 0:03:34.820000
 attack of vulnerability that exploits
 the ability to utilize the union

0:03:34.820000 --> 0:03:37.360000
 operator in the SQL queries.

0:03:37.360000 --> 0:03:41.920000
 It typically occurs when an application
 fails to properly validate or

0:03:41.920000 --> 0:03:46.720000
 sanitize user input and allows an attacker
 to inject malicious SQL code

0:03:46.720000 --> 0:03:50.920000
 or queries into the original query being
 used by the web application to

0:03:50.920000 --> 0:03:52.980000
 communicate with the database, right?

0:03:52.980000 --> 0:03:57.520000
 So we've already taken a look at the
 union operator very briefly in the

0:03:57.520000 --> 0:03:59.340000
 SQL fundamentals video.

0:03:59.340000 --> 0:04:06.880000
 And I didn't really cover
 union-based video.

0:04:06.880000 --> 0:04:09.700000
 And the reason for that will become
 apparent because identifying them

0:04:09.700000 --> 0:04:13.600000
 is not really the, uh, the thing that
 you need to know, that's fairly

0:04:13.600000 --> 0:04:15.660000
 simple based on what we've
 taken a look at.

0:04:15.660000 --> 0:04:19.820000
 What we need to know is how to utilize
 the union operator, which I wanted

0:04:19.820000 --> 0:04:24.380000
 to essentially pause until this point
 or until this video and for good

0:04:24.380000 --> 0:04:28.400000
 reason, because this can be quite
 complicated and not in a bad way.

0:04:28.400000 --> 0:04:33.240000
 It essentially means that you need to, you
 really need to have an understanding

0:04:33.240000 --> 0:04:38.000000
 of how specific MySQL databases work
 with regards to their database schema

0:04:38.000000 --> 0:04:43.600000
 and what you are essentially doing when
 you utilize the union operator.

0:04:43.600000 --> 0:04:45.740000
 So what is the union operator?

0:04:45.740000 --> 0:04:50.000000
 Well, the union operator is used in the
 structured query language to combine

0:04:50.000000 --> 0:04:53.980000
 the results, keep in mind
 this particular keyword.

0:04:53.980000 --> 0:04:56.900000
 So it's used to combine the
 results of two or more.

0:04:56.900000 --> 0:05:01.360000
 So two or more select statements into
 a single result set and we will

0:05:01.360000 --> 0:05:05.620000
 revisit what the select statement is
 used for, but by this point, you

0:05:05.620000 --> 0:05:06.660000
 should already know that.

0:05:06.660000 --> 0:05:09.500000
 So what are the requirements here?

0:05:09.500000 --> 0:05:13.180000
 Well, it essentially requires that the
 number of columns and their data

0:05:13.180000 --> 0:05:16.720000
 types match in the select
 statements being combined.

0:05:16.720000 --> 0:05:20.420000
 So you're utilizing two
 select statements.

0:05:20.420000 --> 0:05:25.260000
 Let's say, for example, how do you, how
 do you get data from two different

0:05:25.260000 --> 0:05:31.920000
 tables and specific columns and get the
 output of those select statements

0:05:31.920000 --> 0:05:34.700000
 to be displayed in one, right?

0:05:34.700000 --> 0:05:36.260000
 Or as one, if you will.

0:05:36.260000 --> 0:05:38.580000
 The way you do that is using
 the union operator.

0:05:38.580000 --> 0:05:42.820000
 Union, if you have done mathematics
 before, if you have done, you know,

0:05:42.820000 --> 0:05:44.580000
 Venn diagrams, you know what union means.


0:05:44.580000 --> 0:05:49.220000
 It's simply used to infer that there's
 an intersection and there's now

0:05:49.220000 --> 0:05:54.960000
 a union of, in this case, datasets,
 or in the case of SQL injection, you

0:05:54.960000 --> 0:05:58.840000
 know, the actual results
 of two or more data sets.

0:05:58.840000 --> 0:06:03.720000
 And as I said, the key thing here is that
 it requires the number of columns

0:06:03.720000 --> 0:06:05.820000
 and their data types match.

0:06:05.820000 --> 0:06:09.440000
 And if the previous examples, when we're
 finding SQL injection vulnerabilities,

0:06:09.440000 --> 0:06:13.980000
 I sort of went over the payloads to
 use, but I didn't really, we really

0:06:13.980000 --> 0:06:14.920000
 didn't have much success.

0:06:14.920000 --> 0:06:19.220000
 And again, that was done on purpose
 because if I dived into that there,

0:06:19.220000 --> 0:06:23.900000
 it would have confused pretty much any
 other sub SQL injection vulnerability

0:06:23.900000 --> 0:06:25.720000
 subtype that we explored.

0:06:25.720000 --> 0:06:27.940000
 So it's great that we're getting
 into it right now.

0:06:27.940000 --> 0:06:32.460000
 So in a union base SQL injection attack,
 the attacker injects additional

0:06:32.460000 --> 0:06:36.380000
 select statements through vulnerable
 input to retrieve data from other

0:06:36.380000 --> 0:06:39.760000
 database tables or extract
 sensitive information.

0:06:39.760000 --> 0:06:43.960000
 So in other words, we're just changing
 around the technique we're utilizing

0:06:43.960000 --> 0:06:45.400000
 to extract data.

0:06:45.400000 --> 0:06:48.760000
 Now, as I said, once you've verified
 that a SQL injection vulnerability

0:06:48.760000 --> 0:06:54.000000
 exists, in the case of in the case of
 union base SQL injection, identifying

0:06:54.000000 --> 0:06:58.600000
 the impact and severity of the vulnerability
 will involve you running

0:06:58.600000 --> 0:07:01.000000
 or utilizing the union operator.

0:07:01.000000 --> 0:07:06.020000
 So this is very, very important because
 this is a very nuanced type of

0:07:06.020000 --> 0:07:07.440000
 SQL injection vulnerability.

0:07:07.440000 --> 0:07:12.460000
 Now, the easiest way to understand this
 is through the use of this example

0:07:12.460000 --> 0:07:15.180000
 that will sort of illustrate
 what's going on.

0:07:15.180000 --> 0:07:19.520000
 So let's say we have a web application
 input and it utilizes the following

0:07:19.520000 --> 0:07:24.440000
 query to interact with the database
 and get whatever data is required

0:07:24.440000 --> 0:07:27.580000
 or to confirm if a particular
 user exists, right?

0:07:27.580000 --> 0:07:33.480000
 So the as you know, in order to retrieve
 data from a particular from a

0:07:33.480000 --> 0:07:38.160000
 particular table and refer to a particular
 column with regards to the

0:07:38.160000 --> 0:07:42.960000
 data that you want for a particular record,
 what you do is use the select

0:07:42.960000 --> 0:07:45.260000
 operator, which already familiar with.

0:07:45.260000 --> 0:07:50.340000
 So we say select and then after that,
 what we need to provide, if required,

0:07:50.340000 --> 0:07:53.680000
 is the columns or the attributes
 we're interested in.

0:07:53.680000 --> 0:07:58.440000
 So we're saying select ID and name
 from the table called users.

0:07:58.440000 --> 0:08:02.900000
 All right. So in this case, it looks like
 this may be a login query, right?

0:08:02.900000 --> 0:08:06.360000
 Where we're, you know, the web application
 wants the ID and the name,

0:08:06.360000 --> 0:08:07.520000
 but there's no real password.

0:08:07.520000 --> 0:08:12.500000
 So again, just disregard that, that
 example of, you know, the login form

0:08:12.500000 --> 0:08:13.800000
 example that I just used.

0:08:13.800000 --> 0:08:17.460000
 So select ID and name from
 the table called users.

0:08:17.460000 --> 0:08:29.720000
 And I only want you to display data
 that matches the following that, you

0:08:29.720000 --> 0:08:32.940000
 know, or in this particular case,
 the parameter is called ID.

0:08:32.940000 --> 0:08:36.280000
 And then the value is where
 we inject our query, right?

0:08:36.280000 --> 0:08:41.120000
 Now, as I mentioned previously in other
 videos, this particular parameter

0:08:41.120000 --> 0:08:47.740000
 here ID equals or it can be name equals
 is data type specific in that

0:08:47.740000 --> 0:08:53.580000
 if this, if the SQL query utilizes,
 you know, two single quotes or two

0:08:53.580000 --> 0:08:56.900000
 double quotes. And that means
 it's treated as a string.

0:08:56.900000 --> 0:09:00.560000
 And if you wanted to perform your injection,
 you would essentially utilize

0:09:00.560000 --> 0:09:05.460000
 a single quote to terminate the string
 literal and then pass in your query

0:09:05.460000 --> 0:09:10.080000
 after that. So an attacker can exploit
 this vulnerability by injecting

0:09:10.080000 --> 0:09:14.260000
 a union based attack payload into
 the user input parameter.

0:09:14.260000 --> 0:09:15.900000
 It's really the value of the parameter.

0:09:15.900000 --> 0:09:27.080000
 But just for the sake of conversation,
 they could over here to terminate

0:09:27.080000 --> 0:09:32.240000
 the string literal and then start
 their own, their own SQL query.

0:09:32.240000 --> 0:09:35.320000
 So it's not really terminating the previous
 one is just saying in addition

0:09:35.320000 --> 0:09:38.020000
 to that query, I also want
 you to run this one.

0:09:38.020000 --> 0:09:42.400000
 And in this case, we're saying, in addition
 to running this select query,

0:09:42.400000 --> 0:09:46.240000
 I also want you to run the
 following so union select.

0:09:46.240000 --> 0:09:57.720000
 And in this case, the columns being
 referred to so you may be thinking

0:09:57.720000 --> 0:10:03.000000
 to yourself, well, I'm a little bit confused
 here because you're now referencing

0:10:03.000000 --> 0:10:06.520000
 a different set of columns
 in a different table.

0:10:06.520000 --> 0:10:11.780000
 And that's exactly the core or the crocs
 of union base SQL injection is

0:10:11.780000 --> 0:10:16.040000
 because you're already working or you
 can leverage this very query here

0:10:16.040000 --> 0:10:21.560000
 to extract info from the users table
 using something like a Boolean base

0:10:21.560000 --> 0:10:30.300000
 payload way and use the comment, the comment
 symbol based on the relational

0:10:30.300000 --> 0:10:32.920000
 database management system being used.

0:10:32.920000 --> 0:10:37.980000
 That would essentially display all values
 for this particular, for this

0:10:37.980000 --> 0:10:41.400000
 particular table or all records
 in the users table.

0:10:41.400000 --> 0:10:45.560000
 When we talk about union base SQL injection
 is very powerful because you

0:10:45.560000 --> 0:10:50.340000
 can now say, okay, I also want
 to get data from another table.

0:10:50.340000 --> 0:10:56.000000
 Now the problem here is that if you're
 targeting a real world web application,

0:10:56.000000 --> 0:11:01.840000
 firstly, you don't know really what
 table this query is interacting with

0:11:01.840000 --> 0:11:04.440000
 or you don't know the name of the table.

0:11:04.440000 --> 0:11:09.320000
 Secondly, you don't know the names
 of any other tables and the columns

0:11:09.320000 --> 0:11:11.660000
 that they have within that table.

0:11:11.660000 --> 0:11:18.440000
 So this is where the whole idea of the
 whole idea of performing database

0:11:18.440000 --> 0:11:23.320000
 enumeration and enumerating the database
 schema comes into play and we'll

0:11:23.320000 --> 0:11:26.320000
 talk a little bit about this
 in the practical section.

0:11:26.320000 --> 0:11:30.360000
 So the injected payload modifies the
 original query to retrieve the credit

0:11:30.360000 --> 0:11:35.000000
 card numbers along with a custom value
 called hack from the credit cards

0:11:35.000000 --> 0:11:40.200000
 table. All right, actually in this,
 yeah, from the credit cards table,

0:11:40.200000 --> 0:11:43.380000
 the double dash at the end is used to
 comment out the remaining part of

0:11:43.380000 --> 0:11:44.820000
 the original query.

0:11:44.820000 --> 0:11:47.480000
 All right, so very simple to understand.

0:11:47.480000 --> 0:11:51.660000
 But the key thing is how do we know
 that there is a table called credit

0:11:51.660000 --> 0:11:55.560000
 card number? Or sorry, there is
 a table called credit cards.

0:11:55.560000 --> 0:11:59.480000
 And that table has the columns credit
 card number and you know, a particular

0:11:59.480000 --> 0:12:01.240000
 value called hack, right?

0:12:01.240000 --> 0:12:05.000000
 So if the application is vulnerable
 to union base equal injection, the

0:12:05.000000 --> 0:12:06.920000
 modified query would
 become the following.

0:12:06.920000 --> 0:12:12.400000
 So select ID and name from the table
 users where the ID equals, and then

0:12:12.400000 --> 0:12:14.540000
 you know, we use the single quote there.

0:12:14.540000 --> 0:12:18.620000
 And then we say union select credit card
 number and hack from credit cards.

0:12:18.620000 --> 0:12:23.120000
 And then we use the double dash to infer
 a, you know, essentially to act

0:12:23.120000 --> 0:12:26.660000
 as a comment and end the query there
 if anything follows after that.

0:12:26.660000 --> 0:12:31.880000
 Now this comment symbol or the way you
 specify comments will differ based

0:12:31.880000 --> 0:12:36.740000
 on the type of MySQL database you are
 utilized, sorry, the type of SQL

0:12:36.740000 --> 0:12:39.400000
 database you're using specifically.

0:12:39.400000 --> 0:12:43.480000
 So in the case of MySQL, you're able
 to see through the practical examples

0:12:43.480000 --> 0:12:47.180000
 that the pound symbol or the
 hash symbol typically worked.

0:12:47.180000 --> 0:12:49.900000
 And that's not, that's not a mistake.

0:12:49.900000 --> 0:12:50.900000
 That's by design.

0:12:50.900000 --> 0:12:54.880000
 In some other SQL databases, you'll
 typically see that the double dash

0:12:54.880000 --> 0:12:56.660000
 works. All right.

0:12:56.660000 --> 0:13:03.080000
 And in the finding SQL injection vulnerabilities
 video, there is a slide

0:13:03.080000 --> 0:13:08.560000
 that gives you an example of what comment,
 comment symbols or characters

0:13:08.560000 --> 0:13:13.040000
 to use based on the type of SQL
 database you are targeting.

0:13:13.040000 --> 0:13:16.340000
 All right, so the database would then
 execute this modified query and

0:13:16.340000 --> 0:13:20.180000
 the result would include the credit
 card numbers alongside the original

0:13:20.180000 --> 0:13:25.440000
 user data and the attacker can subsequently
 extract this sensitive information.

0:13:25.440000 --> 0:13:29.460000
 So what is the methodology of identifying
 and exploiting union based SQL

0:13:29.460000 --> 0:13:30.740000
 injection vulnerability?

0:13:30.740000 --> 0:13:35.520000
 So number one, as we saw in the previous
 video, identify user inputs or

0:13:35.520000 --> 0:13:38.880000
 determine the inputs on the application
 that are used in database queries

0:13:38.880000 --> 0:13:40.260000
 or that interact with the database.

0:13:40.260000 --> 0:13:44.760000
 These inputs can include URL parameters,
 form fields, cookies or any other

0:13:44.760000 --> 0:13:46.640000
 user controllable data.

0:13:46.640000 --> 0:13:50.340000
 Secondly, test inputs for
 the actual vulnerability.

0:13:50.340000 --> 0:13:54.020000
 This is done through the use of the
 injection of a simple payload, such

0:13:54.020000 --> 0:13:56.220000
 as a single quote or a double quote.

0:13:56.220000 --> 0:14:00.880000
 If the application produces an error
 or exhibits unexpected behavior,

0:14:00.880000 --> 0:14:05.680000
 it may or it might indicate a potential
 SQL injection vulnerability.

0:14:05.680000 --> 0:14:09.140000
 Thirdly, identify vulnerable
 injection points.

0:14:09.140000 --> 0:14:12.960000
 So this involves manipulating the injected
 payload to check if the application

0:14:12.960000 --> 0:14:15.880000
 responds differently based
 on the injected data.

0:14:15.880000 --> 0:14:19.060000
 This is specific to union
 based injection.

0:14:19.060000 --> 0:14:23.580000
 So in other words, you can try injecting
 various payloads like or typically

0:14:23.580000 --> 0:14:28.580000
 union select statements or Boolean conditions,
 for example, or one equals

0:14:28.580000 --> 0:14:34.680000
 one or see if the application behaves
 differently based on the response.

0:14:34.680000 --> 0:14:37.420000
 And then fourthly, confirm the
 presence of a vulnerability.

0:14:37.420000 --> 0:14:41.040000
 Once you've identified a potential injection
 point, you need to confirm

0:14:41.040000 --> 0:14:44.560000
 if it is, you know, you need to confirm
 that it is vulnerable to union

0:14:44.560000 --> 0:14:46.240000
 based SQL injection.

0:14:46.240000 --> 0:14:49.600000
 To do this, you can inject union select
 statement and observe the application's

0:14:49.600000 --> 0:14:53.660000
 response. If the application includes
 additional columns on expected data,

0:14:53.660000 --> 0:15:01.840000
 it is likely vulnerable
 to union based data.

0:15:01.840000 --> 0:15:04.880000
 So if you're touching on, you know,
 you can exploit the union based SQL

0:15:04.880000 --> 0:15:08.600000
 injection vulnerability to enumerate
 the database structure, inject union

0:15:08.600000 --> 0:15:12.040000
 select statements with the appropriate
 column names and the table names

0:15:12.040000 --> 0:15:15.500000
 to retrieve information about the database
 schema, be touching on that

0:15:15.500000 --> 0:15:18.440000
 as well. Database schema
 tables and columns.

0:15:18.440000 --> 0:15:22.760000
 And you can utilize techniques like order
 by or limit clauses to retrieve

0:15:22.760000 --> 0:15:24.940000
 specific information.

0:15:24.940000 --> 0:15:29.160000
 With that being said, this brings
 us to the practical demo.

0:15:29.160000 --> 0:15:34.360000
 So as I said in the, in the beginning
 of this video, this, this video

0:15:34.360000 --> 0:15:36.880000
 has a lab environment attached to it.

0:15:36.880000 --> 0:15:40.520000
 The lab environment is a real world
 web application, but much simply in

0:15:40.520000 --> 0:15:43.180000
 terms of complexity, and
 that's for good reason.

0:15:43.180000 --> 0:15:47.260000
 This lab environment will also provide
 you with your own Kali Linux box

0:15:47.260000 --> 0:15:50.700000
 or system. So you don't have to use
 your own, which is great, you can

0:15:50.700000 --> 0:15:54.760000
 access it directly via browser will not
 be utilizing any specialized tools

0:15:54.760000 --> 0:15:59.000000
 or automated tools like you'll see why.

0:15:59.000000 --> 0:16:02.200000
 So with that being said, I'm going to
 start up the lab environment, and

0:16:02.200000 --> 0:16:04.080000
 I'll see you there.

0:16:04.080000 --> 0:16:10.960000
 All right, so I'm currently back or I'm
 currently within the lab environment.

0:16:10.960000 --> 0:16:14.540000
 And as you can see, you'll be provided
 with a Kali Linux system.

0:16:14.540000 --> 0:16:18.000000
 And a Firefox window will be
 automatically open for you.

0:16:18.000000 --> 0:16:22.180000
 That'll direct you to a web application
 called exam results.

0:16:22.180000 --> 0:16:28.380000
 All right. And the URL is results
 dot ABC dot university dot edu.

0:16:28.380000 --> 0:16:32.840000
 And it looks like the web server
 is running on port 5000.

0:16:32.840000 --> 0:16:37.040000
 Okay, so as I said, we're going to be
 utilizing primarily manual techniques

0:16:37.040000 --> 0:16:41.940000
 here. I'm just going to zoom into the point
 where you can see things clearly.

0:16:41.940000 --> 0:16:44.400000
 And the web application
 is very, very simple.

0:16:44.400000 --> 0:16:48.180000
 Right? It's essentially asks
 us to enter your role number.

0:16:48.180000 --> 0:16:51.620000
 Right? And or that would typically
 mean your enrollment number.

0:16:51.620000 --> 0:16:54.980000
 Now this is data that obviously is a
 pen tester or a bug bounty hunter.

0:16:54.980000 --> 0:16:56.900000
 You're not going to be privy to.

0:16:56.900000 --> 0:17:01.980000
 Okay, so we can enter data like, let's
 say 100 or something random to

0:17:01.980000 --> 0:17:03.400000
 see where that matches.

0:17:03.400000 --> 0:17:07.560000
 And typically with web applications like
 this, where the information like

0:17:07.560000 --> 0:17:11.680000
 a role number is going to be unique,
 unless you know a student goes to

0:17:11.680000 --> 0:17:15.920000
 the university, for example, you, it'll
 be very difficult to guess what

0:17:15.920000 --> 0:17:19.080000
 type of system they're using, what type
 of numbering system they're using?

0:17:19.080000 --> 0:17:21.540000
 Is it random? Is it order based?

0:17:21.540000 --> 0:17:24.280000
 And if it is order based, at
 what point does it start?

0:17:24.280000 --> 0:17:28.320000
 Because it could start at, you
 know, 10, 100, 1000, etc.

0:17:28.320000 --> 0:17:30.820000
 So let's, you know, enter this in here.

0:17:30.820000 --> 0:17:31.860000
 And what do we get?

0:17:31.860000 --> 0:17:34.700000
 All right, so it says result for 100.

0:17:34.700000 --> 0:17:38.760000
 And it displays the date, it looks
 like the web application by design

0:17:38.760000 --> 0:17:49.940000
 will interact with the enrollment number,
 the name of the student, their

0:17:49.940000 --> 0:17:53.580000
 marks, and their rank, which makes sense,
 because this is an exam results

0:17:53.580000 --> 0:17:58.000000
 portal. So in terms of identification,
 there's multiple ways we can go

0:17:58.000000 --> 0:17:58.800000
 about doing this.

0:17:58.800000 --> 0:18:02.360000
 The first thing we need to identify,
 and this is extremely manual and

0:18:02.360000 --> 0:18:06.000000
 blind, or however, don't confuse
 this with blind SQL injection.

0:18:06.000000 --> 0:18:11.060000
 But what we need to do is identify
 firstly, whether this value here is

0:18:11.060000 --> 0:18:14.000000
 being treated as a string or integer.

0:18:14.000000 --> 0:18:18.000000
 All right, and the way we can do
 that is by utilizing a web proxy.

0:18:18.000000 --> 0:18:19.940000
 And this is the only time we'll use it.

0:18:19.940000 --> 0:18:23.940000
 But we'll go into burp suite, you should
 have foxy proxy enabled as a

0:18:23.940000 --> 0:18:28.400000
 extension in Firefox, and the burp
 suite proxy configured for Firefox.

0:18:28.400000 --> 0:18:32.060000
 What that means is that once you select
 burp suite, it'll proxy all the

0:18:32.060000 --> 0:18:35.220000
 traffic from this particular
 browser into burp suite.

0:18:35.220000 --> 0:18:39.620000
 And we can access burp suite by opening
 up the Kali menu here and going

0:18:39.620000 --> 0:18:42.880000
 into web application analysis
 and burp suite.

0:18:42.880000 --> 0:18:46.740000
 This is obviously an older version of
 burp suite, but again, works exactly

0:18:46.740000 --> 0:18:51.420000
 the same. We'll start a temporary
 project and start that up here.

0:18:51.420000 --> 0:18:52.380000
 And there we go.

0:18:52.380000 --> 0:18:55.280000
 So it's going to fire up burp suite.

0:18:55.280000 --> 0:18:59.420000
 And we want to navigate or just going
 to maximize this and going to the

0:18:59.420000 --> 0:19:01.000000
 proxy right over here.

0:19:01.000000 --> 0:19:05.280000
 And actually, what I'm also going to do
 in this particular case is increase

0:19:05.280000 --> 0:19:09.680000
 the font size. So on the display, the
 user interface, we can change that

0:19:09.680000 --> 0:19:11.640000
 something like 18.

0:19:11.640000 --> 0:19:13.460000
 And that will need us to restart it.

0:19:13.460000 --> 0:19:14.740000
 But I don't think we need to do that.

0:19:14.740000 --> 0:19:19.260000
 And the font size for the HTTP message,
 we're going to proxy, make sure

0:19:19.260000 --> 0:19:21.800000
 the intercept is set to on.

0:19:21.800000 --> 0:19:24.400000
 And we're going to the web application.

0:19:24.400000 --> 0:19:26.460000
 And we'll click on get result.

0:19:26.460000 --> 0:19:32.700000
 All right, so in this particular case,
 we can see that the data is being

0:19:32.700000 --> 0:19:35.480000
 passed in the URL, right, as a parameter.


0:19:35.480000 --> 0:19:39.220000
 In this case, the parameter
 name is roll number.

0:19:39.220000 --> 0:19:40.380000
 And that's equals to 100.

0:19:40.380000 --> 0:19:43.220000
 Now, the reason you don't see this here
 is down to how the web application

0:19:43.220000 --> 0:19:47.580000
 is built, where the URL or any parameters
 are not displayed publicly,

0:19:47.580000 --> 0:19:52.080000
 which is a great thing that web developers
 do to sort of mask how the

0:19:52.080000 --> 0:19:53.120000
 web application works.

0:19:53.120000 --> 0:19:57.940000
 But obviously, this information can
 be, you know, can be inferred.

0:19:57.940000 --> 0:20:01.900000
 However, it's not really referring to
 this web server, because the host

0:20:01.900000 --> 0:20:06.160000
 is the IP of the target, but port 8000.

0:20:06.160000 --> 0:20:08.580000
 All right. Now, that's not really
 important in this case.

0:20:08.580000 --> 0:20:11.980000
 But you can see that the referrer,
 we're able to confirm that because

0:20:11.980000 --> 0:20:15.440000
 the referrer is the actual site we're
 targeting, where the injection is

0:20:15.440000 --> 0:20:19.720000
 made. So results dot ABC
 dot university dot edu.

0:20:19.720000 --> 0:20:24.600000
 The point I'm making is that this parameter
 is being sent to this particular

0:20:24.600000 --> 0:20:26.700000
 web server here.

0:20:26.700000 --> 0:20:30.700000
 Now, it could be the same web server,
 but just a different service running.

0:20:30.700000 --> 0:20:34.360000
 In this case, it is a web server
 because you can see HTTP.

0:20:34.360000 --> 0:20:35.740000
 And the port is 8000.

0:20:35.740000 --> 0:20:38.840000
 So we could potentially try and access
 this in a browser and see what