WEBVTT 00:00:00.540 --> 00:00:03.780 Sqlmap keeps an ongoing session file that it uses to track 00:00:03.780 --> 00:00:06.060 results and where it is in various processes. 00:00:07.140 --> 00:00:09.570 We'll clear our session and have sqlmap start from scratch by 00:00:09.570 --> 00:00:12.270 adding the flush‑session option to are command line. 00:00:13.840 --> 00:00:16.540 The level parameter controls a number of tests that sqlmap will use. 00:00:16.540 --> 00:00:19.210 It'll also change where sqlmap will insert payloads. 00:00:19.210 --> 00:00:23.190 By default, sqlmap will test all GET and POST query parameters. 00:00:23.190 --> 00:00:26.430 At level two, sqlmap will test values and cookies, 00:00:26.430 --> 00:00:29.460 and at level three, it includes values in the User‑Agent header. 00:00:30.140 --> 00:00:31.100 The higher the level, 00:00:31.230 --> 00:00:33.770 the better the chance of detecting more difficult injections. 00:00:34.620 --> 00:00:36.680 Increasing the risk parameter will include payloads 00:00:36.680 --> 00:00:38.130 that may have dangerous side effects. 00:00:38.500 --> 00:00:39.160 For example, 00:00:39.170 --> 00:00:41.150 setting the risk value to 2 will include heavy 00:00:41.150 --> 00:00:43.120 time‑based queries in a list of tests. 00:00:43.640 --> 00:00:46.970 Setting it to 3 will include payloads that contain OR injections. 00:00:47.740 --> 00:00:48.950 Both of these may have side effects, 00:00:48.950 --> 00:00:51.250 depending on the exact nature of the underlying query. 00:00:52.740 --> 00:00:53.510 For instance, 00:00:53.520 --> 00:00:56.790 an OR injection in a SQL updating statement may end up 00:00:56.790 --> 00:00:58.470 updating all the entries in a table. 00:00:58.940 --> 00:01:01.520 A time‑heavy injection may cause instability in 00:01:01.520 --> 00:01:03.770 databases with inadequate configurations. 00:01:04.290 --> 00:01:07.450 Be careful with these, and only use higher values after extra testing. 00:01:07.680 --> 00:01:11.270 With that said, let's go for it and set the level to 5 and the risk to 30. 00:01:12.240 --> 00:01:14.960 Sqlmap will now be testing with its full set of payloads. 00:01:16.140 --> 00:01:17.600 Since we flushed a session file, 00:01:17.600 --> 00:01:20.160 sqlmap doesn't remember our answers to these questions. 00:01:20.540 --> 00:01:22.970 We'll run through them just like we did in the previous demo. 00:01:24.320 --> 00:01:27.670 Comparing these results with the results from earlier, we see an added payload. 00:01:28.640 --> 00:01:33.500 Sqlmap added a boolean‑based blind payload containing an OR clause to the 00:01:33.500 --> 00:01:36.470 list of payloads that this SQL injection is vulnerable to. 00:01:37.240 --> 00:01:41.670 Using sqlmap, we can perform an extensive test of our target application. 00:01:42.240 --> 00:01:44.540 We can use the crawl option to find injection points that we 00:01:44.540 --> 00:01:48.090 may have missed. Adjusting the level and risk parameters 00:01:48.090 --> 00:01:49.450 will give us even more coverage. 00:01:50.140 --> 00:01:52.680 This is something that I'd only do at the end of an assessment 00:01:52.680 --> 00:01:57.480 and if I'm testing in a non‑production environment. We instruct 00:01:57.480 --> 00:02:00.180 sqlmap to crawl the application using a crawl option and 00:02:00.180 --> 00:02:02.920 specify how deep to go. Now, 00:02:02.920 --> 00:02:06.520 instead of providing the URL with the query parameters and 00:02:06.530 --> 00:02:10.660 specifying that we only want the id parameter tested, let's remove 00:02:11.140 --> 00:02:13.360 the query parameters and the ‑p parameter. 00:02:15.240 --> 00:02:16.960 We're removing these parameters since we want to 00:02:16.960 --> 00:02:18.660 verify that our options are correct. 00:02:19.210 --> 00:02:22.770 If they are, sqlmap should detect a form on the page and submit it for us. 00:02:23.440 --> 00:02:24.550 When it submits the form, 00:02:24.550 --> 00:02:26.970 it'll see the id query parameter and pick it up for testing. 00:02:26.970 --> 00:02:29.480 We'll leave the other options just like they are. 00:02:29.660 --> 00:02:32.790 I mentioned the form submission. By default, sqlmap will not 00:02:32.790 --> 00:02:34.870 submit any forms during its crawl process. 00:02:35.540 --> 00:02:39.260 We have to specify that we want that to happen by using the forms parameter. 00:02:40.540 --> 00:02:42.430 Now be cautious with this as you may never know what is 00:02:42.430 --> 00:02:44.100 exactly going on in the back end. 00:02:44.110 --> 00:02:45.440 It's not uncommon, for instance, 00:02:45.440 --> 00:02:48.160 to have a Contact Us form that is sending emails to someone. 00:02:48.740 --> 00:02:51.010 The last thing you want is an irritated person on the phone 00:02:51.010 --> 00:02:53.240 because they woke up to thousands of junk emails. 00:02:53.360 --> 00:02:54.470 There's also another catch here. 00:02:54.940 --> 00:02:58.450 During the crawl process, sqlmap is most likely going to hit a logout endpoint. 00:02:58.680 --> 00:03:00.550 If it does, our session will end. 00:03:01.440 --> 00:03:03.680 We can tell sqlmap to ignore the logout page by 00:03:03.680 --> 00:03:05.520 using the crawl‑exclude parameter. 00:03:05.690 --> 00:03:08.550 This parameter takes a regular expression for pages to ignore. 00:03:08.770 --> 00:03:12.960 We'll add the logout page, as well as the security page to this exclusion list. 00:03:13.940 --> 00:03:16.320 The security page has a form that changes the 00:03:16.320 --> 00:03:17.960 security level that we used earlier. 00:03:18.540 --> 00:03:21.140 We don't want the security level changing while we're performing a 00:03:21.140 --> 00:03:24.640 scan. Even though we're specifying the security level in the 00:03:24.640 --> 00:03:28.670 cookie, we'll exclude this page to be on the safe side. We'll say 00:03:28.670 --> 00:03:30.050 no to checking the sitemap here. 00:03:31.340 --> 00:03:33.750 If your application has one, sqlmap can parse it and 00:03:33.750 --> 00:03:34.970 add the results to the crawl scope. 00:03:36.240 --> 00:03:37.480 We'll stick with one thread here, 00:03:37.490 --> 00:03:40.260 but you'll probably want to use more for real‑world testing. 00:03:41.240 --> 00:03:43.000 Do we want to normalize crawling results? 00:03:44.040 --> 00:03:47.390 The normalization process means that sqlmap will treat URLs 00:03:47.390 --> 00:03:49.720 the same except for extra information. 00:03:49.730 --> 00:03:50.550 For example, 00:03:50.550 --> 00:03:54.720 if one URL has a slash at the end and another doesn't. Normalizing the paths 00:03:54.720 --> 00:03:58.160 will make this the same URL instead of two. This is generally a good practice 00:03:58.160 --> 00:04:00.260 to do this, so we'll go along with sqlmap here. 00:04:00.840 --> 00:04:02.880 Here we have the option to save the list of URLs 00:04:02.880 --> 00:04:04.770 that sqlmap identifies to a file. 00:04:05.240 --> 00:04:07.880 This is very handy for testing and to make sure there's nothing 00:04:07.880 --> 00:04:10.880 from the crawl that is being left out or that is there that 00:04:10.880 --> 00:04:14.850 shouldn't be. So now sqlmap is going to confirm that you want 00:04:14.850 --> 00:04:16.560 to test each form in URL. 00:04:17.140 --> 00:04:19.029 We'll say no to testing these for right now so we can see 00:04:19.029 --> 00:04:20.350 what the rest of the run looks like. 00:04:21.040 --> 00:04:23.400 This output is worth reviewing to make sure there isn't anything 00:04:23.400 --> 00:04:26.070 else we should exclude from our scan. For instance, 00:04:26.070 --> 00:04:28.260 in the above output, there's the setup page. 00:04:28.980 --> 00:04:31.460 This page offers the ability to reset the database. 00:04:31.840 --> 00:04:34.340 If the database is reset, it will end our active session, 00:04:34.340 --> 00:04:37.600 preventing us from finishing the scan. I would add this page to the 00:04:37.600 --> 00:04:40.200 crawl‑exclude list before continuing with testing. 00:04:40.400 --> 00:04:43.850 I take a careful and deliberate approach when using sqlmap during an assessment. 00:04:44.240 --> 00:04:47.750 Sqlmap provides these checks to ensure that it is doing what we intend it to. 00:04:48.240 --> 00:04:50.260 It's worth taking the extra time to streamline our 00:04:50.260 --> 00:04:52.360 testing and reduce any side effects.