WEBVTT 00:00:01.040 --> 00:00:01.460 Right now, 00:00:01.460 --> 00:00:03.990 I'm in the sqlmap root directory, and the main entry 00:00:03.990 --> 00:00:06.840 point to sqlmap is the sqlmap.py file. 00:00:06.850 --> 00:00:09.330 Let's run that without any parameters to take a look at the version 00:00:09.330 --> 00:00:12.860 we're using. In the banner, it shows that we're using version 00:00:12.870 --> 00:00:16.050 1.4.9.23, and this is a development version. 00:00:17.740 --> 00:00:19.670 And now let's start putting together a sqlmap command line. 00:00:20.080 --> 00:00:22.450 The first thing we need to do is to specify our target 00:00:22.450 --> 00:00:25.060 URL. We do this with the ‑u option. 00:00:25.940 --> 00:00:29.500 Now let's grab the URL from the page that we were on in the DVWA 00:00:29.500 --> 00:00:34.140 application. We'll paste the URL in, and make sure you put it in between 00:00:34.140 --> 00:00:37.140 double quotes. Now if we were to run this as it is, 00:00:37.140 --> 00:00:40.880 sqlmap will do its best to test each of the query parameters in the URL. 00:00:40.890 --> 00:00:42.100 Oftentimes though, 00:00:42.110 --> 00:00:46.220 we may not want to test all of them and test a specific one. In this case, 00:00:46.220 --> 00:00:49.630 we know that the id parameter is vulnerable, so let's just tell 00:00:49.630 --> 00:00:52.280 sqlmap to test that one only. And we can do this with a ‑p 00:00:52.280 --> 00:00:56.980 command. And then we specify the name of the parameter, and 00:00:56.980 --> 00:00:57.950 let's go ahead and run this. 00:00:58.340 --> 00:01:00.770 You'll see that sqlmap has stopped to ask us a question. 00:01:01.140 --> 00:01:03.640 Sqlmap has a batch mode where it will not stop when 00:01:03.640 --> 00:01:05.250 it needs input and use defaults. 00:01:05.750 --> 00:01:07.970 This is very handy when scanning a large application when 00:01:07.970 --> 00:01:09.660 you know exactly the behavior you want. 00:01:10.140 --> 00:01:12.570 For now though, we're going to step through each of the questions. 00:01:13.340 --> 00:01:16.140 This first question that it's asking us is if it wants us to follow a 00:01:16.140 --> 00:01:20.240 redirection to the login page. Because we didn't specify any cookies, we're 00:01:20.240 --> 00:01:24.060 sending unauthenticated requests. Because our requests are unauthenticated, the 00:01:24.060 --> 00:01:26.470 application is redirecting them to the login page. 00:01:26.840 --> 00:01:29.960 You should always ensure that sqlmap is testing against a page you think it is. 00:01:29.980 --> 00:01:32.960 I've spent more time than I'd like to admit troubleshooting failed attempts, 00:01:33.340 --> 00:01:35.180 only to realize that I missed a header or cookie, 00:01:35.190 --> 00:01:36.610 so it was never making it through. 00:01:36.630 --> 00:01:39.050 Let's go back to the application and grab the cookie from our 00:01:39.050 --> 00:01:42.890 active session. Since we only need to copy the cookie, we can 00:01:42.890 --> 00:01:44.450 keep it simple and use our web browser. 00:01:44.840 --> 00:01:48.660 All modern browsers have some form of developer tools built in. In Firefox, 00:01:48.660 --> 00:01:51.560 right‑click anywhere on the page and select Inspect Element. 00:01:52.010 --> 00:01:53.860 This will open the developer tools window. 00:01:54.240 --> 00:01:56.070 I'm just going to increase this to give us some more room. 00:01:57.840 --> 00:02:01.970 Now, if you click over here on the Network tab, we'll click the Reload button. 00:02:03.040 --> 00:02:06.550 This will refresh the page and log all the application requests and responses. 00:02:07.240 --> 00:02:10.520 Click on the first request to view all of its details. Under the 00:02:10.520 --> 00:02:13.330 Headers tab, we can scroll all the way to the bottom to see all 00:02:13.330 --> 00:02:17.960 of the request headers. Toggling this Raw option will make the 00:02:17.960 --> 00:02:19.170 cookie easier to copy. 00:02:19.840 --> 00:02:21.070 So we'll copy this cookie. 00:02:22.040 --> 00:02:24.560 Now we have the last piece of information to exploit this flaw. 00:02:25.240 --> 00:02:28.490 We specify cookies in sqlmap using the cookie parameter. 00:02:28.560 --> 00:02:31.070 And just like the URL, don't forget to put your cookie in 00:02:31.070 --> 00:02:34.890 between double quotes. Now, when we run sqlmap, we see us 00:02:34.890 --> 00:02:37.070 hitting the right page. After only a few tests, it has 00:02:37.070 --> 00:02:39.460 identified that id parameter is vulnerable. 00:02:39.840 --> 00:02:43.790 It's also able to tell what the back‑end database is. In this case, it says 00:02:43.790 --> 00:02:49.310 MySQL, but it's actually MariaDB, which is a MySQL fork. Now it's asking us 00:02:49.310 --> 00:02:51.220 if we want to skip test for other databases. 00:02:51.610 --> 00:02:53.690 The creators designed initial payloads for testing 00:02:53.690 --> 00:02:55.050 with different databases in mind. 00:02:55.440 --> 00:02:58.570 This enables sqlmap to determine if the parameter is vulnerable, 00:02:58.580 --> 00:03:00.280 as well as what the database is. 00:03:00.640 --> 00:03:02.760 It doesn't make sense to test with payloads that may, 00:03:02.760 --> 00:03:04.950 for example, only work with SQL Server. 00:03:05.940 --> 00:03:08.760 So we'll go with the default here and skip the other database tests. 00:03:09.440 --> 00:03:09.750 Okay, 00:03:09.750 --> 00:03:12.560 so now sqlmap is asking us if we want to extend the level and risk 00:03:12.560 --> 00:03:15.050 values. These are both set to to 1 by default. 00:03:15.440 --> 00:03:18.560 In this case, we're going to go with no and keep them both at the lowest setting. 00:03:19.040 --> 00:03:21.860 You can see that sqlmap uses a variety of payloads for testing. 00:03:22.240 --> 00:03:25.060 Once sqlmap determines that a parameter is vulnerable, it stops 00:03:25.060 --> 00:03:27.070 testing further until we tell it to keep going. 00:03:27.840 --> 00:03:29.870 Let's say no to stop testing and see what the final 00:03:29.870 --> 00:03:33.320 results are. For each vulnerable parameter, 00:03:33.320 --> 00:03:35.570 sqlmap will display the payloads that were successful. 00:03:35.930 --> 00:03:37.860 Each payload has a type and title. 00:03:38.240 --> 00:03:41.340 The actual injected payload is also displayed. At the end of 00:03:41.340 --> 00:03:43.330 the output, we see that sqlmap has already grabbed 00:03:43.330 --> 00:03:45.000 information about the server for us, 00:03:45.440 --> 00:03:48.350 the operating system, application technology, as well 00:03:48.350 --> 00:03:49.550 as the database type and version.