WEBVTT 0:00:03.580000 --> 0:00:06.160000 Hello everyone and welcome. 0:00:06.160000 --> 0:00:11.100000 In this video we're going to be taking a look at some advanced SQL map 0:00:11.100000 --> 0:00:13.860000 or SQL map usage. 0:00:13.860000 --> 0:00:20.680000 And as I mentioned in the previous video, where you know, after we go 0:00:20.680000 --> 0:00:25.140000 through the theoretical section, where I sort of cover a couple of important 0:00:25.140000 --> 0:00:31.760000 options regarding, you know, SQL map usage and functionality, we're going 0:00:31.760000 --> 0:00:36.680000 to be essentially taking a look at everything we learned in the previous 0:00:36.680000 --> 0:00:41.500000 video. We're focusing on the essentials of SQL map and what will cover 0:00:41.500000 --> 0:00:48.140000 the theoretical section of this video in the form of or using a real world 0:00:48.140000 --> 0:00:49.640000 web application. 0:00:49.640000 --> 0:00:53.260000 So there is going to be a practical lab section once we're done with the 0:00:53.260000 --> 0:00:54.280000 theoretical section. 0:00:54.280000 --> 0:00:59.280000 But with that being said, let's get started by taking a look at some advanced 0:00:59.280000 --> 0:01:02.500000 SQL map options or functionality. 0:01:02.500000 --> 0:01:10.140000 So the first option or functionality that I want to touch on is the ability 0:01:10.140000 --> 0:01:20.300000 to specify the SQL injection technique that you want to test for, which 0:01:20.300000 --> 0:01:22.820000 consequently affects the payloads that are used. 0:01:22.820000 --> 0:01:28.060000 So what that means is that with SQL map, you can actually, for example, 0:01:28.060000 --> 0:01:35.860000 if you've sort of conclusively, or I would say maybe 80%, you know, you've 0:01:35.860000 --> 0:01:40.380000 manually confirmed that there let's say is a blind SQL injection vulnerability, 0:01:40.380000 --> 0:01:45.900000 you can actually tell SQL map, hey, leave everything else or, you know, 0:01:45.900000 --> 0:01:51.300000 don't test or don't or do not use any other technique. 0:01:51.300000 --> 0:01:55.900000 I've already found it just use Boolean based blind, right? 0:01:55.900000 --> 0:01:58.180000 So how would you go about doing that? 0:01:58.180000 --> 0:02:05.340000 Well, SQL map allows you to specify a specific technique or even combine 0:02:05.340000 --> 0:02:10.000000 them using the technique option or switch. 0:02:10.000000 --> 0:02:15.340000 And this option allows you to specify which SQL injection techniques SQL 0:02:15.340000 --> 0:02:18.060000 map should use during its tests. 0:02:18.060000 --> 0:02:22.540000 Now, by default, this is very important to understand, which means when 0:02:22.540000 --> 0:02:27.440000 you don't specify the technique option, SQL map attempts all techniques 0:02:27.440000 --> 0:02:29.560000 in a sequence. Okay. 0:02:29.560000 --> 0:02:34.860000 However, as I mentioned earlier, if you want to focus on a specific or 0:02:34.860000 --> 0:02:39.900000 on specific techniques for efficiency, which is usually the case or targeting, 0:02:39.900000 --> 0:02:44.480000 you can use this option to be again, very specific. 0:02:44.480000 --> 0:02:51.300000 And this again is fairly common when you've already identified, you know, 0:02:51.300000 --> 0:03:03.380000 with a certain amount of accuracy, what type of SQL option, and then you 0:03:03.380000 --> 0:03:07.140000 say technique equals and then the code. 0:03:07.140000 --> 0:03:11.620000 So each SQL injection technique has a code and that's how it is specified. 0:03:11.620000 --> 0:03:18.200000 And the codes are all in, you know, single letters, uppercase, and I've 0:03:18.200000 --> 0:03:19.580000 sort of added a table. 0:03:19.580000 --> 0:03:22.460000 So you can see we start off with B. 0:03:22.460000 --> 0:03:27.020000 This is, I believe, if the documentation for SQL map is correct, the sequence 0:03:27.020000 --> 0:03:33.820000 in which they are attempted or tested, if the technique option is not 0:03:33.820000 --> 0:03:39.580000 specified and you run the default, you know, you just run a default SQL 0:03:39.580000 --> 0:03:43.540000 map scan. So we have B for Boolean based blind. 0:03:43.540000 --> 0:03:48.640000 So this evaluates true or false conditions in queries to infer information. 0:03:48.640000 --> 0:03:50.780000 We then have E, which is error based. 0:03:50.780000 --> 0:03:55.100000 This uses database error messages to retrieve information. 0:03:55.100000 --> 0:03:59.120000 And then we have you for union based this, you know, exploits the union 0:03:59.120000 --> 0:04:05.040000 SQL operator to extract data as for stacked queries, where, you know, 0:04:05.040000 --> 0:04:09.120000 your SQL map essentially executes multiple SQL statements in one query. 0:04:09.120000 --> 0:04:15.100000 This is if it's supported by the DBMS, or even yeah, by the DBMS. 0:04:15.100000 --> 0:04:16.600000 And then you have time based blind. 0:04:16.600000 --> 0:04:20.280000 So this measures response time delays to infer true or false conditions. 0:04:20.280000 --> 0:04:23.580000 And then Q for inline queries. 0:04:23.580000 --> 0:04:27.660000 So this uses sub queries for extraction, which is less common. 0:04:27.660000 --> 0:04:31.400000 But this is what you have at your disposal, which is pretty cool if you 0:04:31.400000 --> 0:04:37.960000 ask me. So this is an example of how I would tell SQL map, hey, I've already 0:04:37.960000 --> 0:04:43.540000 found or I'm pretty sure firstly, I've found a SQL injection vulnerability. 0:04:43.540000 --> 0:04:49.580000 But B or and secondly, I know that it's Boolean based blind. 0:04:49.580000 --> 0:04:55.540000 So in this case, you can see the example of the scenario is just still 0:04:55.540000 --> 0:04:58.780000 SQL map to focus on Boolean based blind testing. 0:04:58.780000 --> 0:05:03.140000 So SQL map, the URL, and then technique, or the technique option or switch, 0:05:03.140000 --> 0:05:07.020000 and it's equal to uppercase B for Boolean based blind. 0:05:07.020000 --> 0:05:12.500000 So what happens here is that SQL map sends payloads like and one equals 0:05:12.500000 --> 0:05:16.960000 one. So your typical Boolean operations for true for which essentially 0:05:16.960000 --> 0:05:21.580000 evaluates to true and one equals two, which evaluates to false because 0:05:21.580000 --> 0:05:26.440000 one is not equals to two, again, depending on what your stance on that 0:05:26.440000 --> 0:05:31.140000 is. But this is done to determine if the application evaluates conditions 0:05:31.140000 --> 0:05:36.680000 based on input. All right, we then have another example where we're now 0:05:36.680000 --> 0:05:41.000000 testing for our telling SQL map to test for, you know, error based. 0:05:41.000000 --> 0:05:44.420000 So SQL map, you the URL technique is equal to e. 0:05:44.420000 --> 0:05:47.780000 And what happens is that SQL map injects payloads that trigger error messages, 0:05:47.780000 --> 0:05:55.700000 for example, this is, you know, you know, you can actually see this is 0:05:55.700000 --> 0:06:01.600000 one of the payloads here that is typically used for to test for error 0:06:01.600000 --> 0:06:04.000000 based SQL injection vulnerabilities. 0:06:04.000000 --> 0:06:13.080000 You then have, this is now the most important part here of this, of this 0:06:13.080000 --> 0:06:16.020000 video. And that's the level and risk options. 0:06:16.020000 --> 0:06:23.740000 And those fall under a category of options within SQL maps documentation 0:06:23.740000 --> 0:06:27.200000 or help menu called detection options, right? 0:06:27.200000 --> 0:06:36.320000 So these are very useful or identification and testing. 0:06:36.320000 --> 0:06:44.600000 They're really not that useful or, you know, they don't really don't have 0:06:44.600000 --> 0:06:44.960000 any exploitation. 0:06:44.960000 --> 0:06:49.600000 So I want you to start making this distinction within your mind that certain 0:06:49.600000 --> 0:06:55.100000 options are used, you know, to do certain things, but also they used in 0:06:55.100000 --> 0:07:01.560000 different stages, you know, and detection, the detection options, more 0:07:01.560000 --> 0:07:04.860000 specifically level and risk are very important. 0:07:04.860000 --> 0:07:10.120000 So SQL maps level and risk options allow testers to control the intensity 0:07:10.120000 --> 0:07:13.040000 and type of tests performed. 0:07:13.040000 --> 0:07:17.840000 Now there's threads, you know, which is essentially used for performance, 0:07:17.840000 --> 0:07:22.700000 we'll actually explore that in the lab. 0:07:22.700000 --> 0:07:25.540000 I don't really, I don't really need to explain that to you. 0:07:25.540000 --> 0:07:29.920000 It's sort of similar to end maps, timing templates, you know, it speeds 0:07:29.920000 --> 0:07:34.680000 it up, use more threads to increase the speed of operations. 0:07:34.680000 --> 0:07:36.560000 In this case, these are very different. 0:07:36.560000 --> 0:07:37.980000 So level and risk. 0:07:37.980000 --> 0:07:42.560000 So these options can be used and are used to customize the behavior of 0:07:42.560000 --> 0:07:47.820000 SQL map to match the scope and more importantly, the sensitivity of a 0:07:47.820000 --> 0:07:49.600000 penetration test. 0:07:49.600000 --> 0:07:51.840000 So what exactly does this mean? 0:07:51.840000 --> 0:07:54.180000 Well, let's start off with the level option, right? 0:07:54.180000 --> 0:07:59.380000 So this determines the depth of SQL maps testing by increasing the number 0:07:59.380000 --> 0:08:00.840000 of parameters tested. 0:08:00.840000 --> 0:08:03.200000 When I say parameters, what do I mean? 0:08:03.200000 --> 0:08:06.660000 And keep in mind what category this falls under detection? 0:08:06.660000 --> 0:08:08.580000 So detection parameters. 0:08:08.580000 --> 0:08:13.740000 Well, what these levels allow you to do is they allow you to tell SQL 0:08:13.740000 --> 0:08:20.060000 map the type or I should say the number of parameters that are tested 0:08:20.060000 --> 0:08:26.200000 or that actually have payloads injected into. 0:08:26.200000 --> 0:08:30.840000 So the default level, when you don't specify the level option, there is 0:08:30.840000 --> 0:08:35.300000 a default that SQL map falls, falls back on. 0:08:35.300000 --> 0:08:36.380000 That's level one. 0:08:36.380000 --> 0:08:42.380000 So what level one infers is minimal and basic testing that is limited 0:08:42.380000 --> 0:08:44.580000 to get or post parameters. 0:08:44.580000 --> 0:08:48.380000 Okay, so the standard parameters you'd see in a get request or a post 0:08:48.380000 --> 0:08:53.380000 request. Now, when you set the level to two, and by the way, we'll actually 0:08:53.380000 --> 0:09:00.820000 explore it when we get there, there are more levels than one, two, and 0:09:00.820000 --> 0:09:05.700000 three, two and three being the more useful, four and five. 0:09:05.700000 --> 0:09:11.140000 So there's, you know, one to five, four and five are sort of augmentations 0:09:11.140000 --> 0:09:13.340000 of level three, really. 0:09:13.340000 --> 0:09:16.620000 But let's, let's understand what level two is all about. 0:09:16.620000 --> 0:09:30.460000 So level two goes a step further by including HTTP headers, such as when 0:09:30.460000 --> 0:09:34.440000 these should be used, when the level option should be used, but more importantly, 0:09:34.440000 --> 0:09:36.440000 when specific levels should be used. 0:09:36.440000 --> 0:09:40.800000 So let's say when you're doing your testing, let's say, you know, manual 0:09:40.800000 --> 0:09:47.040000 testing, your testing, your standard parameters in, you know, get or post 0:09:47.040000 --> 0:09:52.100000 requests, like, you know, username, password, it's not really working. 0:09:52.100000 --> 0:09:55.400000 But now you want to start testing HTTP headers. 0:09:55.400000 --> 0:10:00.000000 A good candidate is the cookies or let's say user agent strings. 0:10:00.000000 --> 0:10:06.280000 Well, that can be tested using SQL map by specifying the level as level 0:10:06.280000 --> 0:10:12.080000 two. And now you're going beyond, you know, you're going beyond your standard 0:10:12.080000 --> 0:10:14.400000 get post parameters. 0:10:14.400000 --> 0:10:20.120000 And you then have level three, which obviously involves testing additional 0:10:20.120000 --> 0:10:25.600000 parameters. Like refer us, this is, you know, sort of a next gen, if you 0:10:25.600000 --> 0:10:29.760000 will, custom headers and custom headers is very, very cool. 0:10:29.760000 --> 0:10:34.780000 Because, you know, if if we discovered that a web application was using 0:10:34.780000 --> 0:10:40.040000 some custom headers, and you wanted to test them for injection vulnerabilities, 0:10:40.040000 --> 0:10:42.580000 using level three, you can sort of do that. 0:10:42.580000 --> 0:10:45.800000 And you know, it becomes even much better or much faster, much more efficient 0:10:45.800000 --> 0:10:50.020000 when you actually specify the payload or not the payload, the parameter 0:10:50.020000 --> 0:10:54.460000 that or the parameter name that you actually want to inject with the parameter 0:10:54.460000 --> 0:10:58.600000 name would be the name of the custom header. 0:10:58.600000 --> 0:11:05.000000 And, you know, adding on to custom headers, other possible injection points. 0:11:05.000000 --> 0:11:10.340000 Now, as I said, four and five are really just augmentations of level three. 0:11:10.340000 --> 0:11:14.500000 So sort of adding on to that, will not get into that here. 0:11:14.500000 --> 0:11:16.580000 But that's the level option. 0:11:16.580000 --> 0:11:19.060000 So there's a couple of examples that I've listed here. 0:11:19.060000 --> 0:11:23.720000 So to sort of explain what exactly is going on. 0:11:23.720000 --> 0:11:28.200000 So level one, which is the default, you actually don't need to specify 0:11:28.200000 --> 0:11:32.160000 it. If you don't specify the level option, SQL map will run with level 0:11:32.160000 --> 0:11:37.200000 one. And in the case of this URL here, you can see there's an parameter 0:11:37.200000 --> 0:11:41.700000 in the URL. It could also be in the body, but in this case, it's in the 0:11:41.700000 --> 0:11:45.600000 URL. The parameter name is the infamous ID. 0:11:45.600000 --> 0:11:47.860000 The value is just set to one. 0:11:47.860000 --> 0:11:55.880000 In this case, SQL map without us telling it using the p option to test 0:11:55.880000 --> 0:12:07.260000 the parameter or inject payloads in the value of the parameter the ID 0:12:07.260000 --> 0:12:09.860000 parameter is the one we want to inject. 0:12:09.860000 --> 0:12:17.040000 And again, if we don't specify any level, then it's going to, as you can 0:12:17.040000 --> 0:12:20.540000 see here, only the ID parameter in the URL is tested is not going to go 0:12:20.540000 --> 0:12:25.000000 beyond that, which also means, and the reason I want to use these examples 0:12:25.000000 --> 0:12:34.820000 is explicitly, if you actually let me use example two and then on the 0:12:34.820000 --> 0:12:38.960000 level two example before I dive into what I wanted to say. 0:12:38.960000 --> 0:12:45.780000 So level two, SQL map also tests headers like cookie user agent and referral. 0:12:45.780000 --> 0:12:48.560000 So in this case, the URL is still the same. 0:12:48.560000 --> 0:12:53.820000 The ID parameter is also there in the URL. 0:12:53.820000 --> 0:12:56.200000 The level is now set to two. 0:12:56.200000 --> 0:13:08.420000 If no other options are specified, now SQL map beyond just the ID parameter 0:13:08.420000 --> 0:13:15.620000 will also test other parameters, namely headers, HTTP headers like the 0:13:15.620000 --> 0:13:17.320000 cookie user agent and referral. 0:13:17.320000 --> 0:13:22.180000 However, what I wanted to point out a couple of seconds ago is if you 0:13:22.180000 --> 0:13:28.580000 wanted to specify the parameter as, let's say a head, a specific header 0:13:28.580000 --> 0:13:33.920000 that you wanted to inject into, that would sort of override if that makes 0:13:33.920000 --> 0:13:40.360000 sense. So the level option is really just therefore identification when 0:13:40.360000 --> 0:13:48.280000 you're not entirely sure whether you're essentially looking for vulnerable 0:13:48.280000 --> 0:13:51.600000 endpoints or inputs, if that makes sense, wherever they may be. 0:13:51.600000 --> 0:13:54.460000 And then of course, level three, SQL map expands testing to additional 0:13:54.460000 --> 0:13:58.080000 inputs, such as custom headers or hidden fields. 0:13:58.080000 --> 0:14:00.520000 Okay, we then have the risk option. 0:14:00.520000 --> 0:14:05.020000 Now this is also very important, actually more important than the level 0:14:05.020000 --> 0:14:09.300000 I should say, actually no less important. 0:14:09.300000 --> 0:14:13.120000 So the risk option specifies the aggressiveness of SQL maps testing and 0:14:13.120000 --> 0:14:18.580000 the likelihood of causing negative impacts, negative impacts being examples 0:14:18.580000 --> 0:14:22.200000 being server crashes, not noticeable logs. 0:14:22.200000 --> 0:14:25.760000 So we have three levels here, one, two, and three. 0:14:25.760000 --> 0:14:29.320000 So one being the default, which means is the one SQL map falls back on 0:14:29.320000 --> 0:14:34.020000 if you don't specify explicitly a different risk level. 0:14:34.020000 --> 0:14:41.320000 So, and I shouldn't use the word level, it should just be option, because 0:14:41.320000 --> 0:14:47.880000 I don't want you to mistake the level level, as I explained here, and 0:14:47.880000 --> 0:14:49.340000 the risk option. 0:14:49.340000 --> 0:14:54.220000 So the first one is low risk, only non-destructive tests are performed 0:14:54.220000 --> 0:14:55.560000 to his medium risk. 0:14:55.560000 --> 0:15:00.600000 This includes queries that could introduce minus server impacts. 0:15:00.600000 --> 0:15:04.400000 And three is high risk, which includes potentially disruptive actions 0:15:04.400000 --> 0:15:07.380000 like stack queries or time intensive operations. 0:15:07.380000 --> 0:15:13.340000 So what am I referring to, or what does risk really mean when you increase 0:15:13.340000 --> 0:15:21.960000 the level? Well, what it means is that what it relates to is, generally 0:15:21.960000 --> 0:15:26.520000 speaking, how much of an impact do you want to have on the database that 0:15:26.520000 --> 0:15:30.620000 you're essentially injecting queries into? 0:15:30.620000 --> 0:15:42.420000 So do you just want a simple POC, which would, you know, level two, for 0:15:42.420000 --> 0:15:46.660000 example, this starts, as you can see, includes queries that could introduce 0:15:46.660000 --> 0:15:47.880000 minus server impact. 0:15:47.880000 --> 0:15:53.320000 So what that means is queries that would actually take, you know, would 0:15:53.320000 --> 0:15:58.960000 be resource and network intensive to execute, but also back and forth 0:15:58.960000 --> 0:16:02.860000 transmission of the actual data. 0:16:02.860000 --> 0:16:08.300000 The same goes for three, where you now are getting into potentially disruptive 0:16:08.300000 --> 0:16:17.500000 actions. An example of that are stacked queries or time intensive operations. 0:16:17.500000 --> 0:16:23.200000 And the reason this is important and why I sort of outlined earlier on 0:16:23.200000 --> 0:16:30.400000 the importance of understanding what level the level and risk options 0:16:30.400000 --> 0:16:35.360000 do is because when performing a real world pen test, you want to be very 0:16:35.360000 --> 0:16:41.260000 cognizant of the fact that you can actually cause some delays just in 0:16:41.260000 --> 0:16:43.580000 the way the web application works. 0:16:43.580000 --> 0:16:48.600000 So, you know, if you're taking up resource power or the abstract queries, 0:16:48.600000 --> 0:16:55.800000 that as you know, our DBMS is process queries in batches. 0:16:55.800000 --> 0:17:01.000000 So imagine if you're sending like a ton of queries or stacked queries, 0:17:01.000000 --> 0:17:04.920000 it's going to the database is going to have to complete processing those 0:17:04.920000 --> 0:17:08.640000 queries before, you know, the legitimate customers or use of the websites 0:17:08.640000 --> 0:17:09.880000 have their queries. 0:17:09.880000 --> 0:17:14.540000 Anyway, you're getting my point potential denial of service or slow down, 0:17:14.540000 --> 0:17:15.760000 if that makes sense. 0:17:15.760000 --> 0:17:18.300000 Now that's, you know, quite uncommon. 0:17:18.300000 --> 0:17:22.320000 But again, it all depends on the nuances of the environment you're testing. 0:17:22.320000 --> 0:17:27.520000 It may not be a, you know, a web application that has a lot of traffic. 0:17:27.520000 --> 0:17:32.020000 And as a result, there may not be any scalability built into the infrastructure 0:17:32.020000 --> 0:17:34.560000 or the architecture of the web application. 0:17:34.560000 --> 0:17:39.560000 What I mean by that simply put is it may be a small service or a small 0:17:39.560000 --> 0:17:42.820000 web application that are not popular. 0:17:42.820000 --> 0:17:46.340000 That just serves only a couple of hundred or a thousand people. 0:17:46.340000 --> 0:17:49.980000 That's where you're likely to cause to actually cause the most damage 0:17:49.980000 --> 0:17:54.740000 for large organizations with web applications that have, you know, load 0:17:54.740000 --> 0:17:57.680000 balancing, etc. Probably not. 0:17:57.680000 --> 0:18:00.620000 But it's always important to keep that in mind. 0:18:00.620000 --> 0:18:03.060000 So here, you know, some examples of the usage. 0:18:03.060000 --> 0:18:07.900000 So in the case of the default, which is level one SQL map runs non-intrusive 0:18:07.900000 --> 0:18:15.820000 payloads. And this is sort of what I wanted to highlight. 0:18:15.820000 --> 0:18:24.400000 In terms of the relation between, in this case, the risk, but more importantly, 0:18:24.400000 --> 0:18:29.900000 what the risk and the payload that is being injected. 0:18:29.900000 --> 0:18:37.480000 So I'm trying to sort of explain why different risk levels or options 0:18:37.480000 --> 0:18:45.340000 would affect, you know, the performance or would affect or cause disruptions 0:18:45.340000 --> 0:18:46.540000 on the database. 0:18:46.540000 --> 0:18:50.940000 So level one, SQL map runs non-intrusive payloads like Boolean based tests 0:18:50.940000 --> 0:18:52.580000 or simple union queries. 0:18:52.580000 --> 0:18:56.980000 An example, you know, that's how it would be specified in the case of 0:18:56.980000 --> 0:19:04.840000 level two. SQL map adds moderately intrusive tests such as time based 0:19:04.840000 --> 0:19:08.160000 payloads or larger union queries, which actually makes sense because when 0:19:08.160000 --> 0:19:18.040000 you deal with time based SQL injection payload, remember the database, 0:19:18.040000 --> 0:19:20.780000 you may actually tell it to sleep for a bit of time. 0:19:20.780000 --> 0:19:23.400000 That's actually affecting the whole database. 0:19:23.400000 --> 0:19:27.040000 So I hope you're starting to understand how that can actually be quite 0:19:27.040000 --> 0:19:31.100000 annoying for legitimate users using the web application that actually 0:19:31.100000 --> 0:19:35.180000 is interacting or uses the database that you're attacking or injecting 0:19:35.180000 --> 0:19:40.080000 payloads into. And then level three, SQL map executes high risk payloads, 0:19:40.080000 --> 0:19:44.920000 including stack queries and resource intensive time based injections. 0:19:44.920000 --> 0:19:48.340000 So I think you've got the picture. 0:19:48.340000 --> 0:19:53.640000 Certain payloads will affect the database either by, you know, in the 0:19:53.640000 --> 0:20:01.340000 form of stacked, stack queries or resource intensive time based injections 0:20:01.340000 --> 0:20:06.080000 where you actually will not dive into that right now. 0:20:06.080000 --> 0:20:09.000000 But you know, you get the idea of sleeping is one, you could actually 0:20:09.000000 --> 0:20:15.420000 have a huge arithmetic sum that you're using to sort of judge or to test 0:20:15.420000 --> 0:20:22.320000 for time based SQL injection vulnerabilities. 0:20:22.320000 --> 0:20:27.880000 So the other thing I want to point out here before we conclude on the 0:20:27.880000 --> 0:20:32.480000 theoretical section is combining level and risk options. 0:20:32.480000 --> 0:20:34.820000 And this is typically how you'll see it again. 0:20:34.820000 --> 0:20:38.640000 If you've used SQL map before, you already know that you can combine them. 0:20:38.640000 --> 0:20:43.380000 So this is an example of a very stupid scan to be running in the first 0:20:43.380000 --> 0:20:44.820000 place or to begin with. 0:20:44.820000 --> 0:20:49.700000 Of course, if you end up determining that you can, or it's okay generally, 0:20:49.700000 --> 0:20:52.500000 then you can go ahead and actually use this. 0:20:52.500000 --> 0:20:54.160000 So level three, risk three. 0:20:54.160000 --> 0:20:58.200000 So what's happening here is that, or what does this scan mean? 0:20:58.200000 --> 0:21:02.000000 Is that SQL map tests all possible injection points, including headers, 0:21:02.000000 --> 0:21:03.840000 cookies, and additional parameters. 0:21:03.840000 --> 0:21:07.400000 And secondly, it executes high risk payloads like stack queries, which 0:21:07.400000 --> 0:21:11.940000 may alter the database or stress the server. 0:21:11.940000 --> 0:21:21.440000 And this is where I want to sort of quite poignantly make this clear that 0:21:21.440000 --> 0:21:25.400000 the risk parameter lets you fine tune how dangerous your injections can 0:21:25.400000 --> 0:21:31.620000 be. And I must stress this that you use this parameter or this option 0:21:31.620000 --> 0:21:37.200000 when needed only after carefully studying the web application you are 0:21:37.200000 --> 0:21:41.820000 testing. Generally speaking, launching SQL map with both a high level 0:21:41.820000 --> 0:21:47.900000 and risk and letting it automatically test for injection points is extremely, 0:21:47.900000 --> 0:21:51.080000 in fact, not very extremely unprofessional. 0:21:51.080000 --> 0:21:55.480000 And it'll probably generate issues on the client's infrastructure. 0:21:55.480000 --> 0:22:00.020000 What I'm trying to say is start off with manual and then go into SQL map 0:22:00.020000 --> 0:22:04.760000 and then slowly tweak the scan based on info you've already found and 0:22:04.760000 --> 0:22:06.280000 what you're finding. 0:22:06.280000 --> 0:22:11.200000 Just running a SQL map scan right out of the box and just providing a 0:22:11.200000 --> 0:22:15.800000 URL risk three, level three is not the right thing to do. 0:22:15.800000 --> 0:22:18.300000 It's not a professional thing to do. 0:22:18.300000 --> 0:22:22.400000 So again, I'm just giving you this advice now. 0:22:22.400000 --> 0:22:26.760000 I've seen a lot of disasters during pen test before, not of course, you 0:22:26.760000 --> 0:22:31.980000 know, as a result of my actions, but be very careful with a tool like 0:22:31.980000 --> 0:22:36.580000 SQL map. It's extremely powerful, as you'll see. 0:22:36.580000 --> 0:22:41.120000 One final thing before I actually is good that I added it in here is the 0:22:41.120000 --> 0:22:46.280000 fact that and this is one of the most useful features is that I mentioned 0:22:46.280000 --> 0:22:52.520000 it earlier. You can actually use intercepted requests with SQL map. 0:22:52.520000 --> 0:22:57.220000 So you can actually tell SQL map to use an intercepted request and you 0:22:57.220000 --> 0:23:02.160000 can then against, you know, you can tell SQL map what payload, sorry, 0:23:02.160000 --> 0:23:09.180000 not payload, what parameter you want to inject or test for injection. 0:23:09.180000 --> 0:23:12.840000 And it will actually see how to use it, but this is how it works. 0:23:12.840000 --> 0:23:20.280000 So SQL map r-lowcase r, the request file, and then the parameter, so p 0:23:20.280000 --> 0:23:24.060000 and that's if you want to be specific, which I recommend. 0:23:24.060000 --> 0:23:28.760000 And as you can see here, after saving an intercepted request, either with 0:23:28.760000 --> 0:23:34.060000 burp, zap, whatever works, SQL map allows you to specify it as a scan 0:23:34.060000 --> 0:23:39.220000 option. Okay, so with that being said, that's the end of the theoretical 0:23:39.220000 --> 0:23:45.180000 section. I think I've given you enough info, enough theoretical info to 0:23:45.180000 --> 0:23:49.820000 sort of, you know, give you a better view of what you're dealing with 0:23:49.820000 --> 0:23:52.940000 or what just how extensive SQL map is. 0:23:52.940000 --> 0:23:55.460000 It's now time to get into the practical stuff.