WEBVTT 0:00:09.300000 --> 0:00:13.100000 So I'll just say copy and for this and make sure intercept is off just 0:00:13.100000 --> 0:00:16.860000 to see what we get here, whether you know, we have a public interface, 0:00:16.860000 --> 0:00:21.060000 yeah, there we are, looks like a particular API or something that then 0:00:21.060000 --> 0:00:23.020000 interacts with the database for us. 0:00:23.020000 --> 0:00:25.160000 So again, the complexity really doesn't matter. 0:00:25.160000 --> 0:00:29.380000 The only thing you need to understand is that this information is being 0:00:29.380000 --> 0:00:36.060000 sent from here, from results.abc.university .edu to another service, in 0:00:36.060000 --> 0:00:39.840000 this case what appears to be an API or an endpoint that then interacts 0:00:39.840000 --> 0:00:43.360000 with the database based on the value of the parameter you've specified 0:00:43.360000 --> 0:00:49.760000 and then returns the data back here or on results.abc.university.edu. 0:00:49.760000 --> 0:00:53.380000 So we click on get results again, you can see that here. 0:00:53.380000 --> 0:00:57.360000 All right, now this still doesn't tell us whether we're dealing with string 0:00:57.360000 --> 0:01:01.160000 -based, a string-based parameter or an integer parameter. 0:01:01.160000 --> 0:01:04.840000 And again, you never want to rely on the fact that the data being requested 0:01:04.840000 --> 0:01:09.040000 to be input by the use of the web application legitimately. 0:01:09.040000 --> 0:01:13.260000 You never want to consider the data, the actual data type, because an 0:01:13.260000 --> 0:01:18.000000 integer can still be passed in as a string via the query itself, right? 0:01:18.000000 --> 0:01:22.140000 So the easiest test we can perform, and I can go ahead and shut down the, 0:01:22.140000 --> 0:01:25.500000 shut down BERT Suite here, because we really don't need it in this particular 0:01:25.500000 --> 0:01:30.400000 case. Let me just shut that down here, and I'll make sure that this is, 0:01:30.400000 --> 0:01:34.820000 we turn off the BERT Suite profile for Foxy proxy there. 0:01:34.820000 --> 0:01:37.600000 Looks like BERT Suite isn't terminating here. 0:01:37.600000 --> 0:01:39.580000 So let me just shut this down. 0:01:39.580000 --> 0:01:41.560000 All right, so I got that shut down. 0:01:41.560000 --> 0:01:45.060000 So we can try for a simple test, right? 0:01:45.060000 --> 0:01:49.740000 And that is using a single quote right over here, and we had get result. 0:01:49.740000 --> 0:01:53.160000 Now, we're not getting any errors, which is a little bit strange. 0:01:53.160000 --> 0:01:56.060000 You know, we can try a double quote or something like that, or say, you 0:01:56.060000 --> 0:02:00.160000 know, that doesn't seem to work, but we can try a Boolean operation like 0:02:00.160000 --> 0:02:05.460000 single quote or one equals one, and let's use the pound symbol. 0:02:05.460000 --> 0:02:11.880000 If it is my sequel, we should get pretty much all of the, we should get 0:02:11.880000 --> 0:02:16.140000 all the roll numbers, the names and marks of and ranks of all students. 0:02:16.140000 --> 0:02:20.960000 So if I hit get result, okay, something happens, but we don't get anything 0:02:20.960000 --> 0:02:26.960000 because it says results for single quote or one equals one, but we really 0:02:26.960000 --> 0:02:28.900000 don't get anything. 0:02:28.900000 --> 0:02:33.080000 So what if we try and change this to the SQL delimiter here? 0:02:33.080000 --> 0:02:35.840000 So that is the semi colon and hit enter. 0:02:35.840000 --> 0:02:39.960000 Okay, nothing. So what if we're dealing with something like a postgreSQL 0:02:39.960000 --> 0:02:43.500000 or SQL light database relational database? 0:02:43.500000 --> 0:02:47.080000 Well, in that case, we can try the double dashes or the double hyphen 0:02:47.080000 --> 0:02:49.940000 there and click on get results. 0:02:49.940000 --> 0:02:51.420000 All right, fantastic. 0:02:51.420000 --> 0:02:55.140000 So number one, we've identified an application input. 0:02:55.140000 --> 0:02:59.580000 Secondly, we've confirmed that it is vulnerable to SQL injection, and 0:02:59.580000 --> 0:03:03.220000 we've been able to get data, you know, all of the records from this particular 0:03:03.220000 --> 0:03:07.260000 table. But remember, we still don't know what table this is. 0:03:07.260000 --> 0:03:11.080000 We just know that it, you know, the columns within it that at least are 0:03:11.080000 --> 0:03:16.660000 being referenced by the query are roll number and name marks and rank. 0:03:16.660000 --> 0:03:22.300000 And it looks like Rohan Singh here as the highest marks or rather actually, 0:03:22.300000 --> 0:03:26.720000 no, Rahul Verma looks to be, you know, actually, sorry, that's a molya 0:03:26.720000 --> 0:03:30.340000 here, because their rank is set to one. 0:03:30.340000 --> 0:03:33.440000 All right, and that brings me to my first example. 0:03:33.440000 --> 0:03:39.760000 And that is how to utilize the order by the order by statement. 0:03:39.760000 --> 0:03:44.220000 And you know, the way we would typically inject this is fairly simple 0:03:44.220000 --> 0:03:48.320000 to understand is, you know, we have a logical statement here. 0:03:48.320000 --> 0:03:52.920000 But what we could do is say, for example, you know, order by one. 0:03:52.920000 --> 0:03:55.760000 So we can say order by one. 0:03:55.760000 --> 0:04:00.240000 And we know that we're most likely dealing with SQL like database here. 0:04:00.240000 --> 0:04:01.680000 So we'll say get results. 0:04:01.680000 --> 0:04:06.520000 Okay, we could say, or one equals one. 0:04:06.520000 --> 0:04:12.460000 And we can also say, and order by one get results. 0:04:12.460000 --> 0:04:13.940000 Okay, that doesn't work. 0:04:13.940000 --> 0:04:19.860000 If we try and say, in this particular case, what we could do is utilize 0:04:19.860000 --> 0:04:22.800000 a comment there and say, get results. 0:04:22.800000 --> 0:04:28.220000 In this case, it doesn't look like it's going through the order that we 0:04:28.220000 --> 0:04:33.180000 want. But the way this works, when we utilize the order by statement or 0:04:33.180000 --> 0:04:39.000000 clause, what it does is it increments the specified column index until, 0:04:39.000000 --> 0:04:49.500000 you know, if we go ahead and say order by, let's say, order by five, for 0:04:49.500000 --> 0:04:53.040000 example, in it, get results, we don't get anything in here or any other 0:04:53.040000 --> 0:04:55.720000 errors, say get results, etc. 0:04:55.720000 --> 0:05:02.320000 But let's get rid of this here, because I don't want any data stored there. 0:05:02.320000 --> 0:05:06.040000 So the point here, and I probably should have explained this is the reason 0:05:06.040000 --> 0:05:09.940000 we're using numerical values here, like order by six is referring to the 0:05:09.940000 --> 0:05:13.600000 actual column number, because columns have numbers, right? 0:05:13.600000 --> 0:05:17.100000 So what we are saying we could do, and we'll get to this shortly, we could 0:05:17.100000 --> 0:05:21.360000 say, or, you know, one equals one, and then we have double comment to 0:05:21.360000 --> 0:05:27.520000 them, and then we can say, in this particular case, order by, and then 0:05:27.520000 --> 0:05:31.280000 the actual column, in this case, we don't know the column numbers, but 0:05:31.280000 --> 0:05:32.520000 we could specify the name. 0:05:32.520000 --> 0:05:38.460000 So for example, order by name, and we then specify whether, you know, 0:05:38.460000 --> 0:05:39.660000 we want it ascending. 0:05:39.660000 --> 0:05:45.180000 So we could just say, by the name displayed in ascending order, and did 0:05:45.180000 --> 0:05:46.240000 that change anything? 0:05:46.240000 --> 0:05:47.040000 I don't think so. 0:05:47.040000 --> 0:05:50.880000 So we could say, let's get rid of this here. 0:05:50.880000 --> 0:05:53.160000 Let's just see whether that changes anything. 0:05:53.160000 --> 0:05:55.480000 So one equals one. 0:05:55.480000 --> 0:05:58.640000 Let us display that here. 0:05:58.640000 --> 0:05:59.420000 So there we are. 0:05:59.420000 --> 0:06:01.700000 So now it sorts that out, right? 0:06:01.700000 --> 0:06:03.500000 But this is not really union based. 0:06:03.500000 --> 0:06:07.220000 I'm just giving you an example of some of the queries we weren't able 0:06:07.220000 --> 0:06:10.640000 to practically see the results off. 0:06:10.640000 --> 0:06:14.260000 So we could also do that to, you know, for example, rank, which would 0:06:14.260000 --> 0:06:18.460000 make sense if we wanted to see who is ranked first, we could do that here, 0:06:18.460000 --> 0:06:23.100000 we can see that Amolia, Shiva, Puneet, and relevant marks. 0:06:23.100000 --> 0:06:25.240000 And you know, we could then filter by their data type. 0:06:25.240000 --> 0:06:29.240000 So the point I'm trying to make here is that, you know, firstly, we're 0:06:29.240000 --> 0:06:32.200000 leveraging the original select statement, which looks like it's getting 0:06:32.200000 --> 0:06:35.980000 the following columns, or it's referencing the following. 0:06:35.980000 --> 0:06:40.380000 So it's saying select a roll number, name marks and rank from, we don't 0:06:40.380000 --> 0:06:43.160000 know whether those are there, it actually looks like these are the original 0:06:43.160000 --> 0:06:48.000000 column names. But we're saying select these columns, or select from these 0:06:48.000000 --> 0:06:54.880000 columns where, or select these columns from the table, where, you know, 0:06:54.880000 --> 0:06:58.760000 the actual roll number is equal to, but we're utilizing the single quote 0:06:58.760000 --> 0:07:03.220000 and saying, okay, or one equals one, which is always true. 0:07:03.220000 --> 0:07:06.840000 And that's going to display every record in this particular table. 0:07:06.840000 --> 0:07:10.540000 And we're also saying for that same set of results, I want you to order 0:07:10.540000 --> 0:07:13.460000 this by rank or the column. 0:07:13.460000 --> 0:07:16.760000 And the, the ordering is in ascending order. 0:07:16.760000 --> 0:07:18.480000 So hopefully that makes sense. 0:07:18.480000 --> 0:07:22.460000 But I said this is still not union based SQL injection. 0:07:22.460000 --> 0:07:31.240000 Now, in order to perform union based two, three, four columns that are 0:07:31.240000 --> 0:07:36.680000 visible here. But these are not an accurate representation of the total 0:07:36.680000 --> 0:07:40.580000 number of columns within the table that we're referencing or the queries 0:07:40.580000 --> 0:07:41.600000 referencing here. 0:07:41.600000 --> 0:07:46.820000 So how do we go about finding these particular, how do we go about identifying 0:07:46.820000 --> 0:07:51.800000 how many columns exist within this particular table that we currently 0:07:51.800000 --> 0:07:56.800000 have access to? Well, the way we could do that is by utilizing the union 0:07:56.800000 --> 0:08:02.540000 operator here and saying union and saying select, and then we utilize 0:08:02.540000 --> 0:08:05.280000 column numbers. So we can say union select. 0:08:05.280000 --> 0:08:10.460000 And if this works, or when it starts working, it'll actually display the 0:08:10.460000 --> 0:08:12.580000 relevant column numbers. 0:08:12.580000 --> 0:08:16.440000 All right, so we can say union select one, and we'll add a comment there 0:08:16.440000 --> 0:08:17.980000 and say get result. 0:08:17.980000 --> 0:08:19.860000 Okay, nothing is listed here. 0:08:19.860000 --> 0:08:21.220000 So what do we do next? 0:08:21.220000 --> 0:08:25.800000 The next thing we do is we increment this value here, we say two. 0:08:25.800000 --> 0:08:28.460000 Okay, nothing displayed here. 0:08:28.460000 --> 0:08:32.840000 We say three are they three columns, we know they are three, but the order 0:08:32.840000 --> 0:08:35.880000 or that the actual number for each of these columns is not listed when 0:08:35.880000 --> 0:08:40.560000 we hit an accurate match of the correct number of columns within this 0:08:40.560000 --> 0:08:46.420000 table, we'll actually see those numbers juxtaposed in the, in the actual 0:08:46.420000 --> 0:08:51.260000 columns, their respective columns, I'll say get results here, nothing. 0:08:51.260000 --> 0:08:55.180000 So we know that we have four, that's what is being displayed here, but 0:08:55.180000 --> 0:08:56.040000 they could be more. 0:08:56.040000 --> 0:08:57.680000 So we'll say get results. 0:08:57.680000 --> 0:09:01.600000 How about five, are we, do we have a table or sorry, a column that's not 0:09:01.600000 --> 0:09:06.320000 being displayed publicly here, we could, if we say get result, boom, there 0:09:06.320000 --> 0:09:11.120000 we go. So we can see, and this is very important, we have columns, we 0:09:11.120000 --> 0:09:14.900000 have a column called roll number, which has a column number of one, which 0:09:14.900000 --> 0:09:18.220000 means in the table, this would come first. 0:09:18.220000 --> 0:09:22.280000 However, we can see that we don't have a column call to that is displayed 0:09:22.280000 --> 0:09:25.800000 publicly on the web application, we're just checking the order, we can 0:09:25.800000 --> 0:09:30.040000 see that name, the column name is column three in the table and marks 0:09:30.040000 --> 0:09:33.800000 is column four, and rank is column five. 0:09:33.800000 --> 0:09:44.580000 All right. Now what that means essentially, from a union-based column, 0:09:44.580000 --> 0:09:48.360000 specifically, there are numbers, we can use any of them to inject or to 0:09:48.360000 --> 0:09:54.100000 select another or other data from another table, right? 0:09:54.100000 --> 0:09:56.420000 And I'll actually show you what that looks like. 0:09:56.420000 --> 0:10:01.680000 We just need to specify what column we want to inject or what column we 0:10:01.680000 --> 0:10:06.920000 want to display that data from another, from another table. 0:10:06.920000 --> 0:10:08.080000 And this is very important. 0:10:08.080000 --> 0:10:09.820000 So I know that might be confusing. 0:10:09.820000 --> 0:10:13.540000 What we're doing here is, and this is a manual technique that's typically 0:10:13.540000 --> 0:10:21.720000 done, is we're essentially saying union select and the select, the select 0:10:21.720000 --> 0:10:27.140000 operator in this case is being used to identify the actual column numbers. 0:10:27.140000 --> 0:10:31.620000 Now the web application by design only wants the end user or the use of 0:10:31.620000 --> 0:10:35.980000 this web application to see these four columns. 0:10:35.980000 --> 0:10:39.600000 But based on the numbering here, we can see that there are five columns. 0:10:39.600000 --> 0:10:44.260000 We just know that from this particular table, whose name we don't know, 0:10:44.260000 --> 0:10:50.160000 column two, or the values in column two are not being displayed by the 0:10:50.160000 --> 0:10:51.120000 web application. 0:10:51.120000 --> 0:10:52.220000 So just keep that in mind. 0:10:52.220000 --> 0:10:57.480000 What that means is that this column here, column two is non injectable, 0:10:57.480000 --> 0:11:03.120000 which means we cannot take any data using the union select command or 0:11:03.120000 --> 0:11:08.680000 query. We cannot take data any from any other table and inject it in here, 0:11:08.680000 --> 0:11:12.600000 because remember, going back to the definition of union base SQL injection, 0:11:12.600000 --> 0:11:18.640000 we're utilizing the union operator to combine the results of two or two 0:11:18.640000 --> 0:11:20.000000 or more select statements. 0:11:20.000000 --> 0:11:23.760000 So one select statement is already being used by the query, that essentially 0:11:23.760000 --> 0:11:25.560000 displays this info. 0:11:25.560000 --> 0:11:34.720000 And then we're using a second, in this case, we're utilizing a display 0:11:34.720000 --> 0:11:38.340000 this info here. And we're doing this to identify what we can and cannot 0:11:38.340000 --> 0:11:42.840000 do with regards to displaying data from other tables in this particular 0:11:42.840000 --> 0:11:46.860000 table. And the reason for that is because the number of columns have to 0:11:46.860000 --> 0:11:50.780000 match. And that's why we're running into these issues in the finding SQL 0:11:50.780000 --> 0:11:54.720000 injection vulnerabilities video when we're taking a look at those payloads. 0:11:54.720000 --> 0:11:56.240000 So hopefully it makes sense now. 0:11:56.240000 --> 0:12:02.340000 Now the question is, we don't know the values, or we don't know the names 0:12:02.340000 --> 0:12:06.740000 of any other tables within this database, we don't know what columns they 0:12:06.740000 --> 0:12:09.500000 have, or the names of the columns or anything else. 0:12:09.500000 --> 0:12:12.960000 The only thing we know is that we have access to a table here. 0:12:12.960000 --> 0:12:18.040000 And this table has five columns, one of which we cannot see its actual 0:12:18.040000 --> 0:12:24.300000 name. So how do we go about firstly, identifying what SQL database or 0:12:24.300000 --> 0:12:28.160000 DBMS we are currently interacting with. 0:12:28.160000 --> 0:12:32.300000 And that is very important, because it'll allow us to choose the payloads 0:12:32.300000 --> 0:12:37.120000 we use specifically, to, you know, extract info from the database schema 0:12:37.120000 --> 0:12:40.460000 and learn more about the other tables within the database. 0:12:40.460000 --> 0:12:45.740000 So based on that info, I'm already pretty sure that we're dealing with 0:12:45.740000 --> 0:12:47.500000 a SQL light database. 0:12:47.500000 --> 0:12:51.580000 All right, now given that that is the case, let me switch over to another 0:12:51.580000 --> 0:12:55.820000 browser window, where I have one of those GitHub repositories that contains 0:12:55.820000 --> 0:13:00.780000 database specific queries that you can run during SQL injection. 0:13:00.780000 --> 0:13:03.000000 So let me just switch over for a second. 0:13:03.000000 --> 0:13:07.340000 All right, so I'm currently on a GitHub repo called payload, all the things, 0:13:07.340000 --> 0:13:08.740000 and I've already shown you this. 0:13:08.740000 --> 0:13:13.040000 So under SQL injection, you can see that there's different payloads for 0:13:13.040000 --> 0:13:14.720000 different types of SQL databases. 0:13:14.720000 --> 0:13:18.180000 So we have MS SQL, MySQL, which we're familiar with. 0:13:18.180000 --> 0:13:20.000000 And then we have SQL light. 0:13:20.000000 --> 0:13:24.080000 All right, now in here, you can see that SQL light comments are typically 0:13:24.080000 --> 0:13:28.660000 defined or denoted by the double hyphen or the double dash, or a forward 0:13:28.660000 --> 0:13:32.040000 slash asterisk, asterisk forward slash. 0:13:32.040000 --> 0:13:36.740000 In order to get the SQL light version, we just need to say select SQL 0:13:36.740000 --> 0:13:40.400000 light. So we need to utilize a select operator statement. 0:13:40.400000 --> 0:13:42.220000 So let's try that out. 0:13:42.220000 --> 0:13:46.300000 All right, so I'm back in the lab, and we're going to use that info here. 0:13:46.300000 --> 0:13:49.080000 Now you may be asking yourself, well, how do we use this info? 0:13:49.080000 --> 0:13:53.900000 Well, the first thing you need to know is that that data is does not exist 0:13:53.900000 --> 0:13:57.860000 in this particular table, but we can utilize the union select operator, 0:13:57.860000 --> 0:14:03.020000 and our knowledge of columns or the column numbers to essentially display 0:14:03.020000 --> 0:14:09.000000 it or display the version in a particular, in a particular column here. 0:14:09.000000 --> 0:14:13.060000 So the way we can do that is firstly identify what columns are visible 0:14:13.060000 --> 0:14:21.440000 publicly. In this case, we can inject into any into any one of them, and 0:14:21.440000 --> 0:14:22.860000 have that data displayed here. 0:14:22.860000 --> 0:14:23.840000 So let's try it out. 0:14:23.840000 --> 0:14:28.400000 So we can do this, for example, in column one, which is injectable, we 0:14:28.400000 --> 0:14:33.100000 can do that by just saying SQL light, a version, so the the actual command 0:14:33.100000 --> 0:14:38.820000 or query displayed on the GitHub repo, and make sure to include the double 0:14:38.820000 --> 0:14:42.840000 brackets here. And that's pretty much all that we need to do. 0:14:42.840000 --> 0:14:44.460000 So I'll hit get result. 0:14:44.460000 --> 0:14:49.920000 And at the bottom, you can now see in column one, which is roll number, 0:14:49.920000 --> 0:14:52.620000 the the SQL light version is displayed here. 0:14:52.620000 --> 0:14:57.280000 So that actually validates union SQL injection or union based SQL injection, 0:14:57.280000 --> 0:15:01.720000 we can see it's three to two dot zero, and then the other column numbers. 0:15:01.720000 --> 0:15:05.320000 Now, the way it's displayed may be a little bit confusing, but don't worry, 0:15:05.320000 --> 0:15:08.420000 that typically happens when you're dealing with in band SQL injection, 0:15:08.420000 --> 0:15:11.940000 because the web application will determine how it's displayed. 0:15:11.940000 --> 0:15:15.920000 The point I'm making here is that it's displaying it last, because firstly, 0:15:15.920000 --> 0:15:20.020000 it doesn't match any of the other data types or any of the other records. 0:15:20.020000 --> 0:15:24.500000 And it's a new value, because you know, it's not been added to that particular 0:15:24.500000 --> 0:15:28.680000 table, but we're just combining the results of one table, which is this 0:15:28.680000 --> 0:15:33.780000 one here. And we're combining, we're combining it with another value, 0:15:33.780000 --> 0:15:37.020000 not really another table, but another piece of information. 0:15:37.020000 --> 0:15:39.040000 And we're injecting it into the first column. 0:15:39.040000 --> 0:15:43.520000 So you can now get an idea of what else we can do. 0:15:43.520000 --> 0:15:47.780000 So we've identified and confirmed that it's a SQL light database, right? 0:15:47.780000 --> 0:15:52.240000 And the reason why this is important is because in order to enumerate 0:15:52.240000 --> 0:15:56.540000 the database schema, you need to know what database you're working with. 0:15:56.540000 --> 0:16:00.040000 So I'm just going to switch over to another browser here and or another 0:16:00.040000 --> 0:16:03.420000 browser tab to show you the SQL light schema. 0:16:03.420000 --> 0:16:09.020000 And you know, what commands we can reference to get specific information. 0:16:09.020000 --> 0:16:14.360000 All right, so I'm currently on the SQLite schema table documentation page. 0:16:14.360000 --> 0:16:17.620000 So if we go through the introduction really quickly, you can see that 0:16:17.620000 --> 0:16:23.720000 every SQL light or every SQLite database or rather every MySQL database, 0:16:23.720000 --> 0:16:26.560000 even MySQL postgreSQL, etc. 0:16:26.560000 --> 0:16:29.280000 They all contain a single schema table. 0:16:29.280000 --> 0:16:31.520000 So what is a schema table? 0:16:31.520000 --> 0:16:35.000000 A schema table stores the schema for that database. 0:16:35.000000 --> 0:16:40.160000 The schema for a database is a description of all of the other tables, 0:16:40.160000 --> 0:16:45.000000 indexes, triggers, and views that are contained within the database. 0:16:45.000000 --> 0:16:48.680000 So hopefully now you should start to see why we always, you know, perform 0:16:48.680000 --> 0:16:52.700000 database key manipulation is so we can learn the names of other tables, 0:16:52.700000 --> 0:16:56.000000 the columns within, etc. 0:16:56.000000 --> 0:17:01.380000 Now in the case, what we want to find out in the case of SQLite is what 0:17:01.380000 --> 0:17:03.600000 the schema table name is. 0:17:03.600000 --> 0:17:08.720000 In this particular case, it looks like it is either SQLite master SQLite 0:17:08.720000 --> 0:17:11.780000 temp schema or SQLite temp master. 0:17:11.780000 --> 0:17:15.240000 All right. And it says that the alternatives, which is two and three, 0:17:15.240000 --> 0:17:19.380000 only work for the temp database associated with each database connection. 0:17:19.380000 --> 0:17:22.560000 But alternative one works anywhere. 0:17:22.560000 --> 0:17:26.960000 So this is what we want to use to get info regarding other tables. 0:17:26.960000 --> 0:17:28.600000 So we'll actually use that right now. 0:17:28.600000 --> 0:17:33.280000 Now the interpretation of the schema table, firstly, we have type, right? 0:17:33.280000 --> 0:17:37.900000 So the SQLite schema type column will be one of the following text strings 0:17:37.900000 --> 0:17:43.920000 table index view or trigger according to the type of object defined, the 0:17:43.920000 --> 0:17:48.060000 table string is used for both ordinary and virtual tables, we then have 0:17:48.060000 --> 0:17:52.400000 the name. So the SQLite schema dot name column will hold the name of the 0:17:52.400000 --> 0:18:00.660000 object. So that's as far as I'll we then have another fields, another 0:18:00.660000 --> 0:18:02.820000 field, sorry, and that is the table name. 0:18:02.820000 --> 0:18:08.520000 All right. So the SQLite schema dot table name column holds the name of 0:18:08.520000 --> 0:18:14.040000 a table of view that the object is associated with for a table of view, 0:18:14.040000 --> 0:18:17.100000 the table name column is a copy of the name column. 0:18:17.100000 --> 0:18:19.740000 And you'll actually see this and how it works. 0:18:19.740000 --> 0:18:25.080000 The other one that's important is the SQL, the SQL field. 0:18:25.080000 --> 0:18:30.760000 So the SQLite schema dot SQL column stores SQL text that describes the 0:18:30.760000 --> 0:18:35.220000 object. So it'll essentially tell you, in the I'll just go by this description, 0:18:35.220000 --> 0:18:39.880000 this SQL text is a create table, create virtual table, create index, create 0:18:39.880000 --> 0:18:43.980000 view or create trigger statement that if evaluated against the database 0:18:43.980000 --> 0:18:47.820000 file, when it is the main database of a database connection would recreate 0:18:47.820000 --> 0:18:53.940000 the object in essence, it tells you it essentially will tell you what 0:18:53.940000 --> 0:18:57.360000 commands were used to create specific tables. 0:18:57.360000 --> 0:19:02.220000 And that can tell us the other tables, the other tables within the system, 0:19:02.220000 --> 0:19:07.900000 but that can be, you know, inferred using the table name column or or 0:19:07.900000 --> 0:19:11.060000 field. So you may be a little bit confused, don't worry, this will make 0:19:11.060000 --> 0:19:12.860000 sense in a couple of seconds. 0:19:12.860000 --> 0:19:15.780000 I'm going to switch back over into the lab environment. 0:19:15.780000 --> 0:19:18.380000 And I'm back. So what does this mean? 0:19:18.380000 --> 0:19:25.160000 Well, what if we wanted, for example, to display or to get the names of 0:19:25.160000 --> 0:19:32.860000 tables in the actual, from the actual SQLite master database scheme or 0:19:32.860000 --> 0:19:36.460000 schema, sorry, the way we could do that is again, just using the same 0:19:36.460000 --> 0:19:39.520000 statement. So all one equals one union select. 0:19:39.520000 --> 0:19:43.020000 However, now what we do is we say union select. 0:19:43.020000 --> 0:19:45.820000 And again, you can put this anywhere you want. 0:19:45.820000 --> 0:19:50.360000 So either in column one, not column two, but column three, four and five, 0:19:50.360000 --> 0:19:54.820000 we can say we want to get the field table name. 0:19:54.820000 --> 0:20:00.660000 So table name. And I've got that from the SQLite documentation page where 0:20:00.660000 --> 0:20:02.620000 they were just took a look at. 0:20:02.620000 --> 0:20:06.620000 And now we need to select where we're getting this from. 0:20:06.620000 --> 0:20:09.520000 And in this case, we're referring to the database schema table, which 0:20:09.520000 --> 0:20:14.720000 in the case of SQLite databases is called SQLite master. 0:20:14.720000 --> 0:20:18.420000 All right. So we're saying essentially union select table name. 0:20:18.420000 --> 0:20:22.560000 And we want that injected into into column one. 0:20:22.560000 --> 0:20:26.640000 From SQLite master and we get result. 0:20:26.640000 --> 0:20:27.840000 And there we go. 0:20:27.840000 --> 0:20:31.500000 So we can see that we have results, which is the table we are currently 0:20:31.500000 --> 0:20:34.660000 working in. That's results right over here. 0:20:34.660000 --> 0:20:38.440000 And we have another table called secret flag. 0:20:38.440000 --> 0:20:42.660000 And that's really the objective of this lab is to obtain that secret flag. 0:20:42.660000 --> 0:20:45.980000 So we know that there are two tables really within the database. 0:20:45.980000 --> 0:20:50.560000 They could be more, but we know that we're currently interacting or operating 0:20:50.560000 --> 0:20:55.220000 or this data right over here, row number, name marks and rank, is the 0:20:55.220000 --> 0:21:00.080000 results table that the web application essentially interacts with via 0:21:00.080000 --> 0:21:05.460000 the query or the query that precedes this single quote right over here. 0:21:05.460000 --> 0:21:08.500000 So what else can we enumerate? 0:21:08.500000 --> 0:21:14.860000 Well, it would be wise to utilize the SQL field to sort of see or to try 0:21:14.860000 --> 0:21:19.600000 and identify the columns within each of these, within each of these tables. 0:21:19.600000 --> 0:21:24.200000 Now we already know the columns within the results table, but the secret 0:21:24.200000 --> 0:21:25.580000 flag is the one we need. 0:21:25.580000 --> 0:21:29.960000 Because if we're to extract info from this table, we need to know the 0:21:29.960000 --> 0:21:33.240000 columns store the columns within that table. 0:21:33.240000 --> 0:21:36.340000 The way we would do this is utilize instead of table name here. 0:21:36.340000 --> 0:21:39.100000 And in this case, let's try something different. 0:21:39.100000 --> 0:21:41.440000 I'll inject it into three. 0:21:41.440000 --> 0:21:46.400000 All right, I can say in here, we can reference the SQL field from the 0:21:46.400000 --> 0:21:50.940000 database schema and say, from SQLite master. 0:21:50.940000 --> 0:21:55.780000 And for each of the tables, it'll show us what SQL query that was used 0:21:55.780000 --> 0:22:03.060000 to create that particular table and the columns that were created. 0:22:03.060000 --> 0:22:04.540000 So let's get result. 0:22:04.540000 --> 0:22:05.300000 And there we are. 0:22:05.300000 --> 0:22:10.280000 So we can see that right over here, we injected it into column three, 0:22:10.280000 --> 0:22:14.340000 right? So one, two, and three is where we put SQL, we have create table 0:22:14.340000 --> 0:22:26.900000 results. And within why column two was not displayed publicly. 0:22:26.900000 --> 0:22:30.940000 And that's why it's not injectable, because it'll not be displayed publicly. 0:22:30.940000 --> 0:22:33.520000 And this would not be an in band SQL injection attack. 0:22:33.520000 --> 0:22:38.380000 We then have email text or sorry, in this case, email text, it also looks 0:22:38.380000 --> 0:22:41.180000 like that was not displayed as well. 0:22:41.180000 --> 0:22:44.780000 We then have the name, which is what which is actually displayed here. 0:22:44.780000 --> 0:22:56.660000 We have marks, which is what is not displayed is email text. 0:22:56.660000 --> 0:23:00.000000 The email text column is not displayed publicly, which means it's not 0:23:00.000000 --> 0:23:02.120000 injectable. I do apologize for that. 0:23:02.120000 --> 0:23:06.300000 Roll number is obviously the primary key that is used for referencing. 0:23:06.300000 --> 0:23:10.520000 Now for the other table called secret flag, we can see that it only has 0:23:10.520000 --> 0:23:13.520000 two columns, it has flag and value. 0:23:13.520000 --> 0:23:16.300000 And they're both text in terms of their data type. 0:23:16.300000 --> 0:23:17.280000 So what does this mean? 0:23:17.280000 --> 0:23:21.820000 It means that within any of these columns here that are injectable, we 0:23:21.820000 --> 0:23:27.180000 can get their values from the secret flag table. 0:23:27.180000 --> 0:23:30.880000 So what we would need to do, and I'll just write it from, I'll just write 0:23:30.880000 --> 0:23:34.540000 it fresh, is we can say select flag. 0:23:34.540000 --> 0:23:40.260000 So this would be column one, we could say select flag, and then two, which 0:23:40.260000 --> 0:23:41.480000 is not injectable. 0:23:41.480000 --> 0:23:47.680000 And then we would now specify this column here. 0:23:47.680000 --> 0:23:51.280000 So we've selected column one, which is flag, we're saying select flag 0:23:51.280000 --> 0:23:58.340000 and value from, and we would then say four and five for the other columns. 0:23:58.340000 --> 0:24:06.200000 And we would say from the table called secret underscore flag, and use 0:24:06.200000 --> 0:24:08.380000 the double comment, and we hit get result. 0:24:08.380000 --> 0:24:12.220000 And at the bottom here, you can see we're able to get those two columns 0:24:12.220000 --> 0:24:19.180000 or the data from that table, limited to two columns, injected into the, 0:24:19.180000 --> 0:24:23.720000 the columns from the original table, which was the results table that 0:24:23.720000 --> 0:24:25.500000 we're currently working in. 0:24:25.500000 --> 0:24:29.100000 Now the reason why you would get errors like the columns do not match 0:24:29.100000 --> 0:24:34.780000 is when you try and select columns from another table, that are either 0:24:34.780000 --> 0:24:40.020000 too many, typically too many, or do not match the, the number of columns 0:24:40.020000 --> 0:24:43.740000 in the table that you're performing the injection in, right? 0:24:43.740000 --> 0:24:48.000000 So in, for example, in this case, the only injectable columns here were 0:24:48.000000 --> 0:24:52.660000 four, right, realistically speaking, because column two is not injectable, 0:24:52.660000 --> 0:24:54.020000 and is not being displayed. 0:24:54.020000 --> 0:24:59.920000 And if we could inject, you know, flag and value, or the flag and value 0:24:59.920000 --> 0:25:03.500000 columns into, you know, column two, but it will not be displayed. 0:25:03.500000 --> 0:25:06.020000 And therefore, we would not be able to see that, right? 0:25:06.020000 --> 0:25:09.320000 And that's why we're doing it in columns that are publicly displayed. 0:25:09.320000 --> 0:25:13.500000 So what we've done is we've essentially just said, okay, can you please 0:25:13.500000 --> 0:25:25.520000 get the, can you please display or get all using union, to say I want 0:25:25.520000 --> 0:25:31.640000 you to display them in this, in the results table, or to essentially, 0:25:31.640000 --> 0:25:36.080000 you know, display or perform, they display everything within the results 0:25:36.080000 --> 0:25:41.300000 table, and then also add this, these two columns or, you know, our of 0:25:41.300000 --> 0:25:44.980000 many records within that table just display the two columns from the secret 0:25:44.980000 --> 0:25:49.560000 flag table. So again, a bit confusing, but very simple to understand. 0:25:49.560000 --> 0:25:51.660000 And you know, we just hit get result. 0:25:51.660000 --> 0:25:54.320000 And again, we can always change this around. 0:25:54.320000 --> 0:25:58.760000 We can say, you know, we can say select, and we can leave column one as 0:25:58.760000 --> 0:26:04.020000 it is, column three is, we can change to value, and we can also just say, 0:26:04.020000 --> 0:26:10.940000 column four is where we can put in the flag column, and we can hit enter. 0:26:10.940000 --> 0:26:15.100000 And in this case, you can see the order is changed, where we have the 0:26:15.100000 --> 0:26:22.280000 flag, and then, you know, the actual, the actual value of the flag right 0:26:22.280000 --> 0:26:25.200000 over here. And you can see how that works. 0:26:25.200000 --> 0:26:30.080000 So the just to summarize, and I think this is quite important, you may 0:26:30.080000 --> 0:26:33.060000 be a little bit confused with regards to how union works. 0:26:33.060000 --> 0:26:36.360000 But the main error that you'll typically, as you'll typically see, as 0:26:36.360000 --> 0:26:40.860000 I said, is the fact that, you know, you have an existing table that you're 0:26:40.860000 --> 0:26:44.040000 currently interacting with via the query that you've just performed the 0:26:44.040000 --> 0:26:49.760000 injection on. And we're able to see those columns, the columns and the 0:26:49.760000 --> 0:26:55.480000 column numbers, you know, through the initial union select SQL payload 0:26:55.480000 --> 0:26:58.160000 that we used, that essentially showed their numbers. 0:26:58.160000 --> 0:27:04.120000 We saw that there are five columns, and pretty much four out of five of 0:27:04.120000 --> 0:27:07.660000 them are being publicly displayed, which is what we wanted to know. 0:27:07.660000 --> 0:27:11.200000 Right once we identified that, we knew that any one of these columns is 0:27:11.200000 --> 0:27:16.280000 injectable with regards to combining the results, you know, of another 0:27:16.280000 --> 0:27:20.000000 select statement in here, or getting values and then juxtaposing them 0:27:20.000000 --> 0:27:24.340000 against this particular results that we already have here. 0:27:24.340000 --> 0:27:27.980000 So we already know that at that point, the only then the next step, of 0:27:27.980000 --> 0:27:32.860000 course, was to utilize database specific or SQL database specific information 0:27:32.860000 --> 0:27:37.920000 regarding the database schema. 0:27:37.920000 --> 0:27:41.640000 And, you know, in this case, we knew it was a SQLite database and we took 0:27:41.640000 --> 0:27:45.340000 a look at their documentation page to learn about, you know, what the 0:27:45.340000 --> 0:27:47.760000 name of the database schema is. 0:27:47.760000 --> 0:27:53.340000 In this case, we knew, you know, it's called SQLite master, and we were 0:27:53.340000 --> 0:27:57.100000 then able to extract information from there, like, you know, the tables 0:27:57.100000 --> 0:28:06.880000 within the database, we found that there was a table called the columns 0:28:06.880000 --> 0:28:09.600000 within each of those tables. 0:28:09.600000 --> 0:28:15.120000 And from that, we were able to say, okay, you can run the first query, 0:28:15.120000 --> 0:28:19.680000 the first union select query that, you know, essentially gets data or 0:28:19.680000 --> 0:28:23.760000 references data from the results table, and publicly displays four out 0:28:23.760000 --> 0:28:24.900000 of the five columns. 0:28:24.900000 --> 0:28:28.880000 We know that that is important, but we also want to combine this or the 0:28:28.880000 --> 0:28:33.820000 results of that initial select query with this select query, where we 0:28:33.820000 --> 0:28:42.160000 are essentially going to inject the values of the columns value and flag 0:28:42.160000 --> 0:28:47.500000 from the secret flag table in here, and we then get the data there. 0:28:47.500000 --> 0:28:51.300000 So if there are multiple records that info would be juxtaposed in different 0:28:51.300000 --> 0:28:54.180000 rows here, or as different records. 0:28:54.180000 --> 0:28:57.180000 So it doesn't have to match, it doesn't have to be an exact match where, 0:28:57.180000 --> 0:29:03.080000 you know, if you're, if you want to combine it with, you know, the, you 0:29:03.080000 --> 0:29:07.320000 don't need an exact match where you combine two columns with two columns, 0:29:07.320000 --> 0:29:11.580000 you just need to ensure that the second union select or the other table 0:29:11.580000 --> 0:29:16.260000 you're trying to get data from, you're only referencing, you know, columns 0:29:16.260000 --> 0:29:23.240000 that can fit within the actual columns, or the results of the nation of 0:29:23.240000 --> 0:29:24.740000 the initial select query. 0:29:24.740000 --> 0:29:27.920000 So as I said, when I refer to the initial select query, I'm referring 0:29:27.920000 --> 0:29:31.820000 to the query that is being used by the web application to essentially 0:29:31.820000 --> 0:29:34.580000 access data from the results table. 0:29:34.580000 --> 0:29:39.220000 And in this case, it looks like it's referencing the rule number, primarily, 0:29:39.220000 --> 0:29:43.640000 or it's utilizing the roll number value that the user inputs, and then 0:29:43.640000 --> 0:29:48.100000 displaying the information or other columns like the name, marks and rank. 0:29:48.100000 --> 0:29:51.040000 What we're doing is we're just saying, okay, we know that there are four 0:29:51.040000 --> 0:29:55.260000 columns here. Second column is not displayed and therefore not injectable 0:29:55.260000 --> 0:29:59.540000 in that it will not display the results publicly or on this web application. 0:29:59.540000 --> 0:30:03.540000 And we're saying, okay, we can combine the results or the data from another 0:30:03.540000 --> 0:30:07.340000 table within this particular table here. 0:30:07.340000 --> 0:30:08.620000 And that's exactly what we've done. 0:30:08.620000 --> 0:30:12.460000 And the process through which we have arrived here, as you know, has been 0:30:12.460000 --> 0:30:13.360000 very, very manual. 0:30:13.360000 --> 0:30:15.660000 So hopefully all of this makes sense. 0:30:15.660000 --> 0:30:19.260000 And that is going to conclude the practical demonstration side of this 0:30:19.260000 --> 0:30:24.960000 video. All right, so that is union based SQL injection in a nutshell. 0:30:24.960000 --> 0:30:28.460000 I know that was a little bit confusing, but hopefully you understood what 0:30:28.460000 --> 0:30:33.360000 was going on. And the lab that we just took a look at did a great job 0:30:33.360000 --> 0:30:37.340000 or, you know, was set up to demonstrate this exactly. 0:30:37.340000 --> 0:30:40.320000 And I think it, you know, gives you that visual understanding of what's 0:30:40.320000 --> 0:30:45.240000 going on with regards to matching column numbers, or, you know, data from 0:30:45.240000 --> 0:30:49.820000 other tables with regards to having the data correctly juxtaposed against, 0:30:49.820000 --> 0:30:55.460000 you know, the results, or the number of columns in the, that's being referenced 0:30:55.460000 --> 0:30:58.700000 from the table being used in the initial select statement. 0:30:58.700000 --> 0:31:03.060000 So, you know, just understanding that, you know, you typically have a 0:31:03.060000 --> 0:31:08.120000 web application that is running, you know, a particular query, typically 0:31:08.120000 --> 0:31:11.280000 a select query. And that's getting specific data. 0:31:11.280000 --> 0:31:14.500000 What all you're doing is just injecting another select statement after 0:31:14.500000 --> 0:31:19.680000 that, using the union operator to say, okay, you can get this data from 0:31:19.680000 --> 0:31:22.940000 the, from this select query, that's no problem. 0:31:22.940000 --> 0:31:26.500000 That's why we utilized the Boolean payload there, where we said one equals 0:31:26.500000 --> 0:31:29.740000 one, which means that operation will run just fine. 0:31:29.740000 --> 0:31:33.420000 And we're saying in addition to that, can you also combine these results 0:31:33.420000 --> 0:31:39.020000 with this, or with data from another table, and you then specify where 0:31:39.020000 --> 0:31:42.340000 you want them injected, or in what column you want them injected. 0:31:42.340000 --> 0:31:45.080000 And as you saw, we were able to do that. 0:31:45.080000 --> 0:31:49.360000 And we also took a look at, you know, database enumerating information 0:31:49.360000 --> 0:31:50.940000 from the database schema. 0:31:50.940000 --> 0:31:55.520000 And that, as I said, is very nuanced and very specific to the SQL database 0:31:55.520000 --> 0:31:57.820000 that you are currently interacting with. 0:31:57.820000 --> 0:32:00.340000 So always keep that in mind, and always check the documentation. 0:32:00.340000 --> 0:32:05.220000 Of course, I highlighted this information with regards to the comments, 0:32:05.220000 --> 0:32:11.200000 or how to add a comment in the finding SQL injection vulnerabilities video, 0:32:11.200000 --> 0:32:13.880000 but you can always refer back to that. 0:32:13.880000 --> 0:32:16.960000 With that being said, we're now going to turn our attention to the next 0:32:16.960000 --> 0:32:22.580000 section of the course, where we'll be taking a look at blind SQL injection, 0:32:22.580000 --> 0:32:26.620000 and we'll be starting off with Boolean, basically, injection, which, as 0:32:26.620000 --> 0:32:30.300000 you've already been able to tell, we've already covered quite a lot. 0:32:30.300000 --> 0:32:34.760000 So we'll be taking a look at a much more, much more complex web app with 0:32:34.760000 --> 0:32:35.800000 regards to how it works. 0:32:35.800000 --> 0:32:41.320000 But you'll sort of get the gist as to what, you know, Boolean, or in this 0:32:41.320000 --> 0:32:43.700000 case, blind SQL injection is all about. 0:32:43.700000 --> 0:32:47.060000 So for that, being said, I'll be seeing you in the next video.