WEBVTT 0:00:11.940000 --> 0:00:15.300000 Type of SQL injection vulnerabilities. 0:00:15.300000 --> 0:00:20.580000 Now this is a video or a topic or a section of this course that is quite 0:00:20.580000 --> 0:00:22.040000 close to my heart. 0:00:22.040000 --> 0:00:25.880000 The reason I say that is because I wish someone would have explained this 0:00:25.880000 --> 0:00:30.180000 to me before I got started with SQL injection vulnerabilities. 0:00:30.180000 --> 0:00:34.700000 It would have saved me a lot of time conceptually and mentally to picture 0:00:34.700000 --> 0:00:39.640000 the differences between the various types and subtypes of SQL injection 0:00:39.640000 --> 0:00:40.100000 vulnerabilities. 0:00:40.100000 --> 0:00:44.700000 Now if you're asking yourself, there are types of SQL injection vulnerabilities 0:00:44.700000 --> 0:00:48.460000 and subtypes and this is a bit confusing. 0:00:48.460000 --> 0:00:51.880000 I thought SQL injection vulnerability was a type of vulnerability in and 0:00:51.880000 --> 0:00:53.300000 of itself. Well that's true. 0:00:53.300000 --> 0:00:59.000000 However, SQL injection as you will see consists of multiple types of SQL 0:00:59.000000 --> 0:01:04.100000 injection vulnerabilities as well as subtypes that are used or that exist 0:01:04.100000 --> 0:01:08.980000 because of their means of exploitation or the way they're exploited as 0:01:08.980000 --> 0:01:11.860000 well as how the web application is configured. 0:01:11.860000 --> 0:01:16.260000 So I don't want to explain too much before we actually get into this but 0:01:16.260000 --> 0:01:18.360000 I'm going to be breaking everything down. 0:01:18.360000 --> 0:01:21.800000 So if this is not, you're not familiar with this or if you're a pentester 0:01:21.800000 --> 0:01:24.940000 or a bug bounty hunter and you have somewhat of a basic understanding 0:01:24.940000 --> 0:01:29.080000 of this, don't worry, hold on to your horses. 0:01:29.080000 --> 0:01:31.960000 Let me introduce you to this the correct way. 0:01:31.960000 --> 0:01:36.460000 So this particular table is something I'm particularly proud of because 0:01:36.460000 --> 0:01:39.900000 you can go ahead and search anywhere online and you may find something 0:01:39.900000 --> 0:01:44.680000 similar to this but really this is the correct way of looking at SQL injection 0:01:44.680000 --> 0:01:49.920000 vulnerabilities with regards to their types and subtypes. 0:01:49.920000 --> 0:01:54.780000 So as you can see, we have the main vulnerability here which is SQL injection. 0:01:54.780000 --> 0:01:59.220000 Now SQL injection is made up of three primary types. 0:01:59.220000 --> 0:02:05.560000 And those are in band SQL injection which I mentioned in the introduction. 0:02:05.560000 --> 0:02:09.660000 We then have blind SQL injection and out of band SQL injection. 0:02:09.660000 --> 0:02:14.100000 In band and blind being the most common and most popular of the three 0:02:14.100000 --> 0:02:18.800000 out of band is also, I would say fairly popular but very difficult to 0:02:18.800000 --> 0:02:23.220000 orchestrate. So in this course we'll be touching upon in band and blind 0:02:23.220000 --> 0:02:26.460000 and also that applies to their subtypes. 0:02:26.460000 --> 0:02:30.740000 We'll be covering error based, union based, Boolean based and time based, 0:02:30.740000 --> 0:02:33.420000 each in their own video or their own section. 0:02:33.420000 --> 0:02:37.500000 Now why do we have this categorization of the vulnerability into types 0:02:37.500000 --> 0:02:42.700000 or subtypes? Well the reason we have them is personally by virtue of how 0:02:42.700000 --> 0:02:48.720000 they work and how they work, how they exploit it and how they essentially 0:02:48.720000 --> 0:02:53.380000 tie into the functionality of the web application and the database being 0:02:53.380000 --> 0:02:56.740000 used or the configuration of the database with regards to what queries 0:02:56.740000 --> 0:03:02.260000 you're allowed to execute as well as how data is returned back from the 0:03:02.260000 --> 0:03:06.340000 database and then how it's responded back to the user by the web application 0:03:06.340000 --> 0:03:11.960000 itself. So we'll return back to this table at the end of this video but 0:03:11.960000 --> 0:03:15.640000 let's get started with the first type which is in band. 0:03:15.640000 --> 0:03:20.960000 So what is in band SQL injection or SQL injection? 0:03:20.960000 --> 0:03:25.440000 In band SQL injection is the most common type of SQL injection attack 0:03:25.440000 --> 0:03:26.860000 or vulnerability. 0:03:26.860000 --> 0:03:31.820000 It occurs when an attacker uses the same communication channel to send 0:03:31.820000 --> 0:03:36.700000 the attack or the SQL payload and to receive the results. 0:03:36.700000 --> 0:03:37.920000 Now what does this mean? 0:03:37.920000 --> 0:03:41.960000 You may have been thinking to yourself that hey whenever I inject a payload, 0:03:41.960000 --> 0:03:46.340000 a SQL injection payload, I expect to get some data back and expect to 0:03:46.340000 --> 0:03:49.180000 get it back from the web application itself. 0:03:49.180000 --> 0:03:54.140000 Well yes, in most cases you do and that this is what you typically call 0:03:54.140000 --> 0:03:59.360000 an in-band SQL injection vulnerability where you inject an SQL payload 0:03:59.360000 --> 0:04:03.640000 through whatever application input that gets processed by the web application 0:04:03.640000 --> 0:04:07.860000 and then by the database and then the database returns data based on the 0:04:07.860000 --> 0:04:12.300000 query you injected and that data is then displayed by the web application 0:04:12.300000 --> 0:04:16.060000 itself somewhere on the page depending on how it's developed. 0:04:16.060000 --> 0:04:18.680000 So that is in band. 0:04:18.680000 --> 0:04:23.920000 The key thing to note here is that the attacker uses the same communication 0:04:23.920000 --> 0:04:27.220000 channel. When I refer to the communication channel, I'm referring to the 0:04:27.220000 --> 0:04:28.560000 web application. 0:04:28.560000 --> 0:04:32.520000 In most cases is going to be the web application being the single communication 0:04:32.520000 --> 0:04:36.660000 channel. When I say communication channel, I'm referring to what we're 0:04:36.660000 --> 0:04:39.740000 using to communicate with the database. 0:04:39.740000 --> 0:04:42.960000 All right, so in this case, the same communication channel is going to 0:04:42.960000 --> 0:04:44.240000 be the web application. 0:04:44.240000 --> 0:04:49.580000 So in other words, or simply put with in-band SQL injection, the attacker 0:04:49.580000 --> 0:04:55.020000 injects malicious or legitimate SQL code or query into the web application 0:04:55.020000 --> 0:04:59.920000 and then receives the results of the attack or from the database through 0:04:59.920000 --> 0:05:02.580000 the same channel used to submit the code. 0:05:02.580000 --> 0:05:05.960000 In this case, in most cases, the web application itself. 0:05:05.960000 --> 0:05:11.360000 So let's say you have a login form or you have a search bar or any input 0:05:11.360000 --> 0:05:16.820000 point on a web application, you inject a SQL query or payload that will 0:05:16.820000 --> 0:05:21.760000 essentially try and enumerate the database or the version of MySQL running. 0:05:21.760000 --> 0:05:25.600000 What happens with in-band, and this is how you identify that it is an 0:05:25.600000 --> 0:05:29.580000 in-band SQL injection vulnerability, is that the response or the version, 0:05:29.580000 --> 0:05:32.740000 if it is successful, will be displayed on that same page. 0:05:32.740000 --> 0:05:35.240000 So it'll actually be rendered by the web application. 0:05:35.240000 --> 0:05:38.420000 So it'll tell you it may give you an error, but it will have that info 0:05:38.420000 --> 0:05:43.040000 displayed on that same page of injection or the same communication channel. 0:05:43.040000 --> 0:05:47.420000 So when I say communication channel, just think of it as the web application, 0:05:47.420000 --> 0:05:49.880000 which in most cases it is. 0:05:49.880000 --> 0:05:56.160000 So coming to the third point here, in-band SQL injection attacks are extremely 0:05:56.160000 --> 0:05:59.720000 dangerous because they can be used to steal sensitive information, modify 0:05:59.720000 --> 0:06:03.840000 or delete data or take over the entire web application or even the entire 0:06:03.840000 --> 0:06:08.380000 server. Now this can be done with the other types of SQL injection vulnerabilities, 0:06:08.380000 --> 0:06:13.020000 but what makes in-band so dangerous is primarily the fact that you get 0:06:13.020000 --> 0:06:15.880000 the data that you're looking for, if you're trying to dump the database, 0:06:15.880000 --> 0:06:20.040000 it's going to be returned to you almost immediately on that same page. 0:06:20.040000 --> 0:06:23.620000 So that means you don't even need to use a tool like SQL map that will 0:06:23.620000 --> 0:06:27.480000 actually try and get it for you using different techniques with in-band 0:06:27.480000 --> 0:06:31.060000 specifically when you're doing error -based or union-based, you'll get 0:06:31.060000 --> 0:06:35.060000 exactly what you're looking for or even confirmation of successful execution 0:06:35.060000 --> 0:06:39.520000 of the SQL query on that same web page or the same page where you performed 0:06:39.520000 --> 0:06:44.080000 the injection if you're targeting a web application that is so very, very, 0:06:44.080000 --> 0:06:48.840000 very dangerous. Now this diagram is sort of one that was built on the 0:06:48.840000 --> 0:06:52.340000 one I highlighted in the anatomy of a SQL injection attack video, but 0:06:52.340000 --> 0:06:56.260000 it's essentially the same concept here where we have an attacker, the 0:06:56.260000 --> 0:06:59.400000 web application which consists of the web server and the database and 0:06:59.400000 --> 0:07:05.960000 of course I went over the fact that the web server and the database communicate 0:07:05.960000 --> 0:07:09.240000 essentially have authentication first and then they can communicate and 0:07:09.240000 --> 0:07:13.680000 you know send and receive data but it's essentially the same diagram for 0:07:13.680000 --> 0:07:15.120000 all intents and purposes. 0:07:15.120000 --> 0:07:18.920000 The only thing I've modified is what is being sent in the HTTP request 0:07:18.920000 --> 0:07:22.940000 and we'll talk about the various ways you can inject a SQL query but not 0:07:22.940000 --> 0:07:27.940000 right now. In this case the example is we've injected a SQL query that 0:07:27.940000 --> 0:07:32.480000 asks the web application and consequently the database to list user accounts 0:07:32.480000 --> 0:07:34.400000 from a particular table, right? 0:07:34.400000 --> 0:07:38.580000 The point I'm trying to make here is this is all a single communication 0:07:38.580000 --> 0:07:43.960000 channel in that the input or the injection and the output and the results 0:07:43.960000 --> 0:07:48.260000 are all facilitated through the web application itself. 0:07:48.260000 --> 0:07:52.080000 I know that in this case there was a pointing to the web server but realistically 0:07:52.080000 --> 0:07:55.680000 that's where it's coming from so all single communication channels. 0:07:55.680000 --> 0:08:06.220000 So we say there's no input validation, the web application sends it as 0:08:06.220000 --> 0:08:10.240000 a SQL query, the database processes, the data sends back the data and 0:08:10.240000 --> 0:08:13.820000 the web application receives the data and then renders it on that same 0:08:13.820000 --> 0:08:18.780000 page where you performed the actual injection and you get the result like 0:08:18.780000 --> 0:08:22.260000 this where the user accounts are admin, John, Mike, etc. 0:08:22.260000 --> 0:08:26.340000 So very very very powerful and very common as you'll see with the various 0:08:26.340000 --> 0:08:29.160000 labs that we'll be going through. 0:08:29.160000 --> 0:08:33.820000 So what are the subtypes, the in -band SQL injection subtypes? 0:08:33.820000 --> 0:08:40.860000 What techniques can you utilize to perform an in-band SQL injection attack? 0:08:40.860000 --> 0:08:44.820000 Well, the two subtypes are error -based and union-based. 0:08:44.820000 --> 0:08:48.800000 So, by the way, we'll be exploring each of these in the own videos. 0:08:48.800000 --> 0:08:50.840000 Don't worry if the description is fairly short. 0:08:50.840000 --> 0:08:52.660000 I just want to introduce you to them. 0:08:52.660000 --> 0:08:57.760000 When you speak of error-based SQL injection, in error-based SQL injection 0:08:57.760000 --> 0:09:02.620000 attacks, the attacker injects SQL code and this is very important. 0:09:02.620000 --> 0:09:04.520000 The SQL code here is very important. 0:09:04.520000 --> 0:09:09.180000 So the attacker injects SQL code that causes the web application to generate 0:09:09.180000 --> 0:09:13.080000 an error message based on the query that was specified. 0:09:13.080000 --> 0:09:16.320000 So the error message can contain valuable information about the database 0:09:16.320000 --> 0:09:21.740000 schema or the contents of the database itself, which makes which the attacker 0:09:21.740000 --> 0:09:25.040000 can then use to further exploit the vulnerability. 0:09:25.040000 --> 0:09:28.920000 So what you're doing with error-based is you're firstly using it as a 0:09:28.920000 --> 0:09:32.900000 way to verify whether there is in fact an in-band SQL injection vulnerability 0:09:32.900000 --> 0:09:35.540000 that exists on the web application. 0:09:35.540000 --> 0:09:40.260000 So you'll typically use an SQL payload that when executed by the web application 0:09:40.260000 --> 0:09:44.780000 or and consequently the database will generate an error typically by the 0:09:44.780000 --> 0:09:48.720000 web application itself telling you that whatever you've specified, whatever 0:09:48.720000 --> 0:09:51.640000 data of input is incorrect. 0:09:51.640000 --> 0:09:55.300000 And you know, you could have specified a query that asks that essentially 0:09:55.300000 --> 0:10:00.000000 requests or will display the version of the database being used. 0:10:00.000000 --> 0:10:03.440000 That will also be displayed on that same page where you made the injection 0:10:03.440000 --> 0:10:09.660000 because it is an in-band SQL injection subtype or it falls under in-band 0:10:09.660000 --> 0:10:14.500000 SQL injection. You then have union-based and this is very simple to understand. 0:10:14.500000 --> 0:10:18.820000 Once you understand SQL queries and now SQL works at a basic level, which 0:10:18.820000 --> 0:10:21.300000 we'll take a look at, this is very easy to understand. 0:10:21.300000 --> 0:10:26.120000 So with union-based SQL injection, the attacker uses the union operator 0:10:26.120000 --> 0:10:32.140000 to combine two SQL queries or rather the results of two or more SQL queries 0:10:32.140000 --> 0:10:34.900000 into a single result set. 0:10:34.900000 --> 0:10:39.020000 By manipulating the injected SQL code, the attacker can extract data from 0:10:39.020000 --> 0:10:41.180000 the database that they're not authorized to access. 0:10:41.180000 --> 0:10:46.200000 So essentially just combining two queries together or using the predefined 0:10:46.200000 --> 0:10:50.240000 queries that the web application sends and then appending another query 0:10:50.240000 --> 0:10:58.280000 to that original value of a particular parameter and saying, okay, Mr. 0:10:58.280000 --> 0:11:02.360000 database, can you also execute this second query as well? 0:11:02.360000 --> 0:11:04.520000 And you do that by using the union operator. 0:11:04.520000 --> 0:11:07.360000 And again, don't worry if this sounds a little bit confusing. 0:11:07.360000 --> 0:11:08.420000 It will make sense. 0:11:08.420000 --> 0:11:12.200000 Trust me, when we take a look at practical examples, and more specifically, 0:11:12.200000 --> 0:11:16.440000 when we take a look at the fundamentals of SQL or the structured query 0:11:16.440000 --> 0:11:20.600000 language. So I've used another diagram here to illustrate how error-based 0:11:20.600000 --> 0:11:22.840000 SQL injection works. 0:11:22.840000 --> 0:11:26.920000 So with error-based, in this particular example, during an error-based 0:11:26.920000 --> 0:11:30.580000 SQL injection attack, the penetration tester tries to force the database 0:11:30.580000 --> 0:11:34.280000 management system, just think of the database management system as the 0:11:34.280000 --> 0:11:37.640000 database, to output an error message. 0:11:37.640000 --> 0:11:41.600000 And once they have that error message, that error message gives them confirmation 0:11:41.600000 --> 0:11:47.740000 that, yes, this site is affected by an in-band SQL injection vulnerability, 0:11:47.740000 --> 0:11:49.100000 more so error-based. 0:11:49.100000 --> 0:11:53.240000 They then use that information to do additional stuff like listing out 0:11:53.240000 --> 0:11:57.940000 the contents of a particular table, viewing data, or dumping the entire 0:11:57.940000 --> 0:12:02.120000 database, etc. So very, very simple to understand because it's in-band, 0:12:02.120000 --> 0:12:05.720000 we're using the same communication channel, in this case, the web application 0:12:05.720000 --> 0:12:09.880000 in that, the injection point, and where we get the results from the database 0:12:09.880000 --> 0:12:13.280000 are all coming through the same single point or the same communication 0:12:13.280000 --> 0:12:17.340000 channel, in this case, and in most cases, that will always be the web 0:12:17.340000 --> 0:12:18.600000 application itself. 0:12:18.600000 --> 0:12:23.540000 So you can see step one, we inject the SQL payload, it can be anything. 0:12:23.540000 --> 0:12:27.320000 In this case, we're asking it to do something that will generate an error, 0:12:27.320000 --> 0:12:30.920000 and it does indeed do that because it's successfully executed by the database, 0:12:30.920000 --> 0:12:34.440000 and the web application knows that this is an error, so it also outputs 0:12:34.440000 --> 0:12:39.780000 that, and that tells you, yes, okay, this web application does not have 0:12:39.780000 --> 0:12:44.720000 any input validation, and whatever we specified for the SQL payload, the 0:12:44.720000 --> 0:12:49.240000 SQL query itself has been executed successfully, that's why we're getting 0:12:49.240000 --> 0:12:52.180000 the error, because it was indeed erroneous. 0:12:52.180000 --> 0:12:54.580000 So that's how that works. 0:12:54.580000 --> 0:12:58.100000 Now, the second type is, of course, blind SQL injection. 0:12:58.100000 --> 0:13:02.560000 Now, this is, again, also quite common, but the way it works is very, 0:13:02.560000 --> 0:13:05.640000 very different, and you may have a lot of questions after this one, and 0:13:05.640000 --> 0:13:09.180000 I don't, I'm not surprised by that. 0:13:09.180000 --> 0:13:14.260000 So, blind, as the name suggests, blind SQL injection is a type of SQL 0:13:14.260000 --> 0:13:18.440000 injection attack, where an attacker can exploit a vulnerability, or exploits 0:13:18.440000 --> 0:13:22.900000 a SQL injection vulnerability in a web application, that does not directly 0:13:22.900000 --> 0:13:27.380000 reveal information about the database, or does does not send back the 0:13:27.380000 --> 0:13:32.600000 results from the database based on the injected SQL query, or what you 0:13:32.600000 --> 0:13:36.580000 specified in the, or what SQL query you used. 0:13:36.580000 --> 0:13:37.740000 So what does that mean? 0:13:37.740000 --> 0:13:42.620000 It means that in contrast to the in -band SQL injection attacks, you're 0:13:42.620000 --> 0:13:44.840000 still using the same communication channel. 0:13:44.840000 --> 0:13:49.160000 However, in this one, this vulnerability, for some reason, depending on 0:13:49.160000 --> 0:13:53.680000 how the web application was designed, or the type of query you're executing, 0:13:53.680000 --> 0:13:58.460000 the web application does not respond, or does not display the results 0:13:58.460000 --> 0:14:01.560000 of your, of the SQL query that you injected. 0:14:01.560000 --> 0:14:05.780000 So this one is very, very confusing to understand, because you may then 0:14:05.780000 --> 0:14:11.700000 be asking yourself, well, what if the injection is possible, and my query 0:14:11.700000 --> 0:14:21.700000 is being in fact working, or there is a SQL injection vulnerability that 0:14:21.700000 --> 0:14:25.440000 exists here, regardless of whether I'm getting data back, and I'll get 0:14:25.440000 --> 0:14:26.440000 to that shortly. 0:14:26.440000 --> 0:14:31.040000 So in this type of attack, the attacker injects malicious SQL code, or 0:14:31.040000 --> 0:14:34.800000 queries, or payload, whatever you want to call it, into the application's 0:14:34.800000 --> 0:14:38.680000 input field, but the application does not return any useful information 0:14:38.680000 --> 0:14:41.120000 or error message to the attacker in the response. 0:14:41.120000 --> 0:14:43.460000 So you really don't know what's going on. 0:14:43.460000 --> 0:14:48.700000 And no pun intended, you are fundamentally blind as to whether your payload 0:14:48.700000 --> 0:14:51.520000 is working, which is where it gets its name from. 0:14:51.520000 --> 0:14:53.720000 So how do you know whether it's working? 0:14:53.720000 --> 0:14:57.600000 Well, the attack, the attacker will typically utilize various techniques 0:14:57.600000 --> 0:15:02.620000 to infer information about the database, such as time delays or Boolean 0:15:02.620000 --> 0:15:04.880000 logic. What does this mean? 0:15:04.880000 --> 0:15:09.700000 Well, the attacker may inject SQL code or a SQL query that causes the 0:15:09.700000 --> 0:15:15.000000 application or the database rather, to delay for a specified amount of 0:15:15.000000 --> 0:15:17.720000 time, depending on the result of a query. 0:15:17.720000 --> 0:15:21.900000 All right. So I'll get into how this can be done. 0:15:21.900000 --> 0:15:25.460000 But this is where the two subtypes come into play, the two blind SQL injection 0:15:25.460000 --> 0:15:30.240000 subtypes, where we have Boolean based SQL injection and time based SQL 0:15:30.240000 --> 0:15:34.080000 injection. So when you speak of Boolean based SQL injection, in this type 0:15:34.080000 --> 0:15:37.580000 of attack, the attacker exploits an application's response to Boolean 0:15:37.580000 --> 0:15:41.440000 conditions to infer information about the database. 0:15:41.440000 --> 0:15:45.700000 So the attacker sends a malicious SQL query to the application and evaluates 0:15:45.700000 --> 0:15:50.100000 the response on whether the query executed successfully or failed. 0:15:50.100000 --> 0:15:53.020000 So you're using Boolean based SQL query. 0:15:53.020000 --> 0:15:56.700000 So SQL queries that essentially ask the database to do something and the 0:15:56.700000 --> 0:16:01.560000 response is always going to be either true or false or a Boolean response. 0:16:01.560000 --> 0:16:04.880000 And that tells you whether what you've injected was executed successfully, 0:16:04.880000 --> 0:16:09.500000 fairly simple to understand, we'll dive deeper into this because there's 0:16:09.500000 --> 0:16:11.200000 a bit more nuance to it. 0:16:11.200000 --> 0:16:15.080000 And then with time based blind injection, this is one of my favorites. 0:16:15.080000 --> 0:16:18.700000 In this type of attack, the attacker exploits the application's response 0:16:18.700000 --> 0:16:21.840000 time to infer information about the database. 0:16:21.840000 --> 0:16:25.660000 So the attacker sends a malicious SQL query or a standard SQL query that 0:16:25.660000 --> 0:16:30.040000 has time parameters, essentially telling the application or the database 0:16:30.040000 --> 0:16:34.160000 to execute this after a certain amount of time. 0:16:34.160000 --> 0:16:38.660000 And then if the application does that or essentially returns a response 0:16:38.660000 --> 0:16:42.560000 within that specified amount of time or after that specified amount of 0:16:42.560000 --> 0:16:46.840000 time, you know that the injection was successful just because it obeyed 0:16:46.840000 --> 0:16:49.280000 your instructions with regards to time parameters. 0:16:49.280000 --> 0:16:53.800000 So you're not relying an output from the database, rather the actual time 0:16:53.800000 --> 0:16:58.280000 taken by the database or the web application to execute that SQL query. 0:16:58.280000 --> 0:17:02.480000 So essentially measuring the time to see whether the injection was successful 0:17:02.480000 --> 0:17:08.240000 or not. And touching upon one example of blind SQL injection, more specifically 0:17:08.240000 --> 0:17:13.280000 Boolean based SQL injection, we're using the same diagram here where an 0:17:13.280000 --> 0:17:16.980000 attacker might send a query that asks whether a particular username exists 0:17:16.980000 --> 0:17:18.440000 in the database. 0:17:18.440000 --> 0:17:21.340000 And the application's response will either be true or false by asking 0:17:21.340000 --> 0:17:25.900000 a series of questions and analyzing the responses, the attacker can slowly 0:17:25.900000 --> 0:17:28.700000 build up a picture of the database schema and the content. 0:17:28.700000 --> 0:17:33.440000 So Boolean based SQL injection can be very difficult to do or is a very 0:17:33.440000 --> 0:17:34.700000 nuanced technique. 0:17:34.700000 --> 0:17:36.420000 But as I said, we'll be breaking it down. 0:17:36.420000 --> 0:17:41.160000 So in this case, very, very simple example, we're asking a question using 0:17:41.160000 --> 0:17:45.100000 a SQL query like does the user john exists, right, very random piece of 0:17:45.100000 --> 0:17:49.680000 data. And then based on the response, we're able to say, okay, this exists. 0:17:49.680000 --> 0:17:55.460000 So maybe there, you know, maybe there is a table called users or usernames. 0:17:55.460000 --> 0:17:58.620000 If it doesn't respond correctly, we know, okay, we need to try something 0:17:58.620000 --> 0:18:04.260000 else. So let's try and see whether the table called WordPress users exists. 0:18:04.260000 --> 0:18:09.160000 If it does, then we'll say, okay, does the user admin exist, the web application 0:18:09.160000 --> 0:18:10.640000 responds with true. 0:18:10.640000 --> 0:18:12.460000 So we know that this user exists. 0:18:12.460000 --> 0:18:15.740000 Okay, so we now know a lot about the database and you build up your knowledge 0:18:15.740000 --> 0:18:20.840000 of the database and then dump data from the database using this technique. 0:18:20.840000 --> 0:18:25.180000 And that brings us to the third type, which will not be covering, but 0:18:25.180000 --> 0:18:26.720000 I'll explain it nonetheless. 0:18:26.720000 --> 0:18:29.560000 And that is out out of band SQL injection, right? 0:18:29.560000 --> 0:18:33.600000 Out of band is a small variation on what we've just taken look at with 0:18:33.600000 --> 0:18:35.120000 in band and blind. 0:18:35.120000 --> 0:18:39.220000 The only difference is the response or the return of data. 0:18:39.220000 --> 0:18:43.000000 So out of band SQL injection is the least common type of SQL injection 0:18:43.000000 --> 0:18:47.220000 attack and involves an attack exploiting a vulnerability in a web application 0:18:47.220000 --> 0:18:51.120000 to extract data from a database using a different communication channel 0:18:51.120000 --> 0:18:53.400000 other than the web application itself. 0:18:53.400000 --> 0:18:58.020000 Unlike in band SQL injection, where the attacker can observe the result 0:18:58.020000 --> 0:19:03.220000 of the injected SQL query in the application's response, out of band SQL 0:19:03.220000 --> 0:19:06.820000 injection does not require the attacker to receive any response from the 0:19:06.820000 --> 0:19:10.800000 application. So we're not relying on the response from the database being 0:19:10.800000 --> 0:19:13.920000 displayed or being sent back by the web application. 0:19:13.920000 --> 0:19:16.300000 We're now using an alternate communication channel. 0:19:16.300000 --> 0:19:19.260000 So as you can tell, you might be asking yourself, well, where is this 0:19:19.260000 --> 0:19:20.600000 data being sent? 0:19:20.600000 --> 0:19:24.080000 Well, the attacker can leverage various techniques to extract data from 0:19:24.080000 --> 0:19:28.440000 the database, such as sending HTTP requests to an external server controlled 0:19:28.440000 --> 0:19:33.400000 by the attacker or using DNS queries to extract data. 0:19:33.400000 --> 0:19:37.360000 All right, so this is what an out of band SQL injection attack looks like. 0:19:37.360000 --> 0:19:40.820000 So an out of band attack is classified by having two different communication 0:19:40.820000 --> 0:19:44.800000 channels, one to launch the attack or one way you inject the actual payload 0:19:44.800000 --> 0:19:49.240000 and the other to gather the results based on the query you specified or 0:19:49.240000 --> 0:19:51.840000 the query that was injected. 0:19:51.840000 --> 0:19:55.880000 For example, the attack channel could be a web request or an injection 0:19:55.880000 --> 0:19:58.620000 in the web application input. 0:19:58.620000 --> 0:20:03.240000 And the data gathering channel could be monitoring HTTP or DNS requests 0:20:03.240000 --> 0:20:05.460000 made to a service you control. 0:20:05.460000 --> 0:20:10.500000 So this involves using an SQLite payload that will not just execute a 0:20:10.500000 --> 0:20:14.340000 query to dump data, but one, and this is where the database management 0:20:14.340000 --> 0:20:19.360000 system specific functionality or understanding what database is running 0:20:19.360000 --> 0:20:25.160000 will becomes very useful, because you could execute or inject a SQL payload 0:20:25.160000 --> 0:20:29.380000 that requests for data and then tells the database to send it. 0:20:29.380000 --> 0:20:34.440000 We remember we're asking the database itself to send it to another web 0:20:34.440000 --> 0:20:36.820000 server or another endpoint that we control. 0:20:36.820000 --> 0:20:39.560000 And that's where we receive the results of the injection. 0:20:39.560000 --> 0:20:44.080000 So we inject the SQL payload into an input point on the web application, 0:20:44.080000 --> 0:20:47.340000 it knows what to do with it, it sends an SQL query to the database, the 0:20:47.340000 --> 0:20:52.620000 database sees the SQL query and it looks valid and says, okay, it's asking 0:20:52.620000 --> 0:20:57.360000 me to dump this, the data from this table and to send it and databases 0:20:57.360000 --> 0:21:05.640000 can do this. The web application wants me to send it to another endpoint. 0:21:05.640000 --> 0:21:07.260000 All right, so I'll do that. 0:21:07.260000 --> 0:21:10.360000 It executes the SQL query and sends it to another endpoint. 0:21:10.360000 --> 0:21:12.540000 And that's the endpoint we control. 0:21:12.540000 --> 0:21:18.020000 And we receive the responses or the results of our of the execution of 0:21:18.020000 --> 0:21:21.520000 the SQL query or the SQL payload that we injected. 0:21:21.520000 --> 0:21:28.180000 So these are the three types and the four subtypes of the various SQL 0:21:28.180000 --> 0:21:30.200000 injection vulnerabilities that exists. 0:21:30.200000 --> 0:21:33.360000 And I'll just go back to the table, because I think that's quite important 0:21:33.360000 --> 0:21:35.200000 just to summarize where we are. 0:21:35.200000 --> 0:21:39.880000 As I said, we'll be focusing on two main types and the four subtypes, 0:21:39.880000 --> 0:21:43.460000 where we'll take a look at in-band SQL injection and blind will not be 0:21:43.460000 --> 0:21:46.460000 covering out of band because it's just a small variation and it's very 0:21:46.460000 --> 0:21:48.120000 hard to orchestrate. 0:21:48.120000 --> 0:21:52.440000 But within in-band we'll be taking a look at error-based SQL injection, 0:21:52.440000 --> 0:21:56.260000 union-based SQL injection and then within blind SQL injection, we'll take 0:21:56.260000 --> 0:22:00.040000 a look at Boolean-based SQL injection and time-based SQL injection. 0:22:00.040000 --> 0:22:03.420000 All right, so that brings us to the end of this video. 0:22:03.420000 --> 0:22:07.060000 Now that we have an understanding or you've got an introduction to SQL 0:22:07.060000 --> 0:22:11.340000 injection of vulnerabilities, you've taken look at a basic anatomy of 0:22:11.340000 --> 0:22:15.360000 what a SQL injection attack looks like and you're familiar with the various 0:22:15.360000 --> 0:22:19.920000 types and subtypes of SQL injection vulnerabilities, we can now turn our 0:22:19.920000 --> 0:22:25.320000 attention to the building blocks or the most important components that 0:22:25.320000 --> 0:22:27.740000 make up the attack from a technical perspective. 0:22:27.740000 --> 0:22:32.460000 And that is databases themselves, more specifically databases and database 0:22:32.460000 --> 0:22:37.500000 management systems, as well as relational databases and no SQL databases 0:22:37.500000 --> 0:22:39.660000 and the differences between the two. 0:22:39.660000 --> 0:22:44.380000 And then we'll also turn our attention to SQL or the structured query 0:22:44.380000 --> 0:22:49.100000 language, how to write SQL code or SQL queries, how to do various things 0:22:49.100000 --> 0:22:54.860000 with SQL so you understand what payloads to use and that will essentially 0:22:54.860000 --> 0:22:58.500000 take us to the conclusion of the intro section of this course. 0:22:58.500000 --> 0:23:02.280000 We'll then turn our attention to the actual practical stuff, we'll be 0:23:02.280000 --> 0:23:08.400000 identifying and exploiting these various types of SQL injection vulnerabilities. 0:23:08.400000 --> 0:23:11.360000 With that being said, that's going to be it for this video and I will 0:23:11.360000 --> 0:23:13.320000 be seeing you in the next video.