WEBVTT 0:00:12.980000 --> 0:00:17.320000 Exploiting Boolean-based SQL Injection Vulnerabilities. 0:00:17.320000 --> 0:00:21.180000 Now that we have a basic understanding or a fundamental understanding 0:00:21.180000 --> 0:00:26.680000 as to how Boolean-based SQL injection vulnerabilities work, we're going 0:00:26.680000 --> 0:00:31.860000 to take a practical look at how to identify and exploit blind Boolean 0:00:31.860000 --> 0:00:35.200000 -based SQL injection vulnerabilities in the wild. 0:00:35.200000 --> 0:00:39.920000 So this will be more focused on my methodology and what I typically do 0:00:39.920000 --> 0:00:45.600000 in the tools that I run when identifying an exploiting blind Boolean-based 0:00:45.600000 --> 0:00:47.700000 SQL injection vulnerabilities. 0:00:47.700000 --> 0:00:51.220000 So this video has a lab environment attached to it. 0:00:51.220000 --> 0:00:54.340000 You can choose to watch the video and then go through the lab or vice 0:00:54.340000 --> 0:00:57.900000 versa, depending on whether or not you want a challenge. 0:00:57.900000 --> 0:01:04.160000 This lab environment will not provide you with a Kalilin Linux system. 0:01:04.160000 --> 0:01:06.080000 So you'll need to utilize your own. 0:01:06.080000 --> 0:01:10.820000 You will require the use of a web proxy if you want to perform effective 0:01:10.820000 --> 0:01:15.720000 testing. And this will also apply to the next video where we will be taking 0:01:15.720000 --> 0:01:21.020000 a look at time-based SQL injection vulnerabilities and attacks. 0:01:21.020000 --> 0:01:23.100000 So I'm going to fire up the lab environment. 0:01:23.100000 --> 0:01:25.900000 You'll be provided with a link to the target web application. 0:01:25.900000 --> 0:01:31.420000 It is a real-world web application and you'll get a tacit feel and understanding 0:01:31.420000 --> 0:01:37.680000 as to, you know, what or how blind Boolean -based SQL injection vulnerabilities 0:01:37.680000 --> 0:01:42.040000 look like and how they can be exploited or tested. 0:01:42.040000 --> 0:01:46.280000 So without further ado, I'm going to switch over into my own Kalilin X 0:01:46.280000 --> 0:01:52.320000 virtual machine, I'll fire up the lab and let's get started. 0:01:52.320000 --> 0:01:57.500000 All right, so I am back in my Kalilin XVM and I'm going to be utilizing 0:01:57.500000 --> 0:02:00.520000 Burbsweet as my web proxy of choice. 0:02:00.520000 --> 0:02:05.080000 You can utilize OSBZAP if you're more comfortable with that. 0:02:05.080000 --> 0:02:08.100000 We're pretty much just going to be utilizing the repeater. 0:02:08.100000 --> 0:02:11.660000 So I'm going to open up Burbsweet because I'm going to be utilizing the 0:02:11.660000 --> 0:02:15.860000 inbuilt Burbsweet browser because it's already configured to proxy all 0:02:15.860000 --> 0:02:20.300000 traffic to Burbsweet and we will require it to analyze requests. 0:02:20.300000 --> 0:02:23.800000 So I'm going to start a temporary project here and we're going to give 0:02:23.800000 --> 0:02:24.860000 this a couple of seconds. 0:02:24.860000 --> 0:02:27.760000 There we are. We'll head over into the proxy. 0:02:27.760000 --> 0:02:31.200000 Just going to disable intercept temporarily and we're going to open up 0:02:31.200000 --> 0:02:36.000000 the browser here and that's going to open up Chromium and I'm just going 0:02:36.000000 --> 0:02:39.460000 to paste in the link provided to me by the lab. 0:02:39.460000 --> 0:02:43.800000 As I said, in this case, you will require a web proxy. 0:02:43.800000 --> 0:02:46.660000 So again, you can run this on Windows as long as you have Burbsweet or 0:02:46.660000 --> 0:02:48.720000 OSBZAP. It'll work. 0:02:48.720000 --> 0:02:53.120000 So as you can see, this is the target web application that is vulnerable 0:02:53.120000 --> 0:02:57.920000 to Boolean-based blind SQL injection. 0:02:57.920000 --> 0:03:02.440000 As you can see, it is a content management system, a very simple one nonetheless, 0:03:02.440000 --> 0:03:10.100000 but one that will highlight what a blind SQL injection vulnerability looks 0:03:10.100000 --> 0:03:16.380000 like in the wild, more specifically one that is vulnerable to or one that 0:03:16.380000 --> 0:03:21.300000 can be exploited via Boolean-based SQL injection payloads and will not 0:03:21.300000 --> 0:03:25.140000 be targeting something as simple as the login form, what we want to pay 0:03:25.140000 --> 0:03:29.120000 attention to in this particular case are the blog posts. 0:03:29.120000 --> 0:03:32.700000 So if we take a look at the actual content management system or the blog 0:03:32.700000 --> 0:03:38.260000 itself, you can see that we have multiple posts here and it looks like 0:03:38.260000 --> 0:03:39.200000 there are quite a few. 0:03:39.200000 --> 0:03:43.540000 If we take a step back, you can see we have quite a few old ones. 0:03:43.540000 --> 0:03:50.380000 It just looks like these one, two, three, and four blog posts, two of 0:03:50.380000 --> 0:03:51.740000 which are missing images. 0:03:51.740000 --> 0:03:56.420000 So if we click on the first one here, I want you to pay attention to the 0:03:56.420000 --> 0:04:01.560000 URL. You can see that in this case, we have the URL of the website and 0:04:01.560000 --> 0:04:12.520000 then a page called identified via the parameter post is equal to and then 0:04:12.520000 --> 0:04:17.320000 the value of the actual post or the ID of the post, which means this is 0:04:17.320000 --> 0:04:25.360000 somewhat of a dynamic parameter in that post with an ID of one is this 0:04:25.360000 --> 0:04:29.440000 post here. And you can see under every post, we have the ability to leave 0:04:29.440000 --> 0:04:34.520000 a comment and some people have left a few comments here like hello, each 0:04:34.520000 --> 0:04:38.180000 day of my life is a story and now so, etc. 0:04:38.180000 --> 0:04:41.580000 So you can see that that is fairly simple to understand. 0:04:41.580000 --> 0:04:45.880000 Now, as per everything that we've learned in this course so far, we can 0:04:45.880000 --> 0:04:49.720000 see that this is the first time we're really dealing with an integer based 0:04:49.720000 --> 0:04:55.140000 parameter. And as a result, this is most likely going to involve integer 0:04:55.140000 --> 0:05:00.640000 based payloads, which means that we do not test for or we cannot utilize 0:05:00.640000 --> 0:05:06.700000 the single quote to terminate the string literal because this is an integer, 0:05:06.700000 --> 0:05:08.300000 as you can see here. 0:05:08.300000 --> 0:05:12.620000 Now what that means is that if we try and go to a post with an ID of two 0:05:12.620000 --> 0:05:17.420000 and we hit enter, it's going to take us to the next blog post here with 0:05:17.420000 --> 0:05:19.220000 that particular ID. 0:05:19.220000 --> 0:05:23.900000 All right, and the same goes if I go over to post three, you can see that 0:05:23.900000 --> 0:05:29.220000 it takes us to the post with that ID and we can continue doing this sequentially 0:05:29.220000 --> 0:05:31.520000 until we reach the end of the posts. 0:05:31.520000 --> 0:05:34.440000 In this case, it only looked like there were four posts. 0:05:34.440000 --> 0:05:38.080000 So if I try the fifth post, let's take a look at how the web application 0:05:38.080000 --> 0:05:44.480000 behaves. So if I enter a value that is invalid here, it takes us direct 0:05:44.480000 --> 0:05:47.480000 to a page which looks quite interesting. 0:05:47.480000 --> 0:05:52.400000 In this case, it looks like it's a blank page and the only other fields 0:05:52.400000 --> 0:05:57.680000 or elements left over are the leave comment is the leave comment model 0:05:57.680000 --> 0:06:02.400000 here that allows you to leave comments and then whatever was juxtaposed 0:06:02.400000 --> 0:06:05.940000 or aligned on the right of the page is moved to the bottom. 0:06:05.940000 --> 0:06:07.800000 So it's essentially a blank page. 0:06:07.800000 --> 0:06:10.840000 All right, so if we go back, I'll be able to verify that for you. 0:06:10.840000 --> 0:06:14.500000 So if we go to post four, you can see that whatever was on the right was 0:06:14.500000 --> 0:06:18.420000 pushed to the bottom and that's because there isn't a blog post with an 0:06:18.420000 --> 0:06:21.560000 ID of five because they're only four blog posts. 0:06:21.560000 --> 0:06:22.960000 So that's very interesting. 0:06:22.960000 --> 0:06:26.520000 The reason I'm doing this as I said is I'm trying to monitor the application's 0:06:26.520000 --> 0:06:32.820000 response to invalid data or, you know, in this particular case, the idea 0:06:32.820000 --> 0:06:37.300000 of a of the post parameter that doesn't exist, most likely doesn't exist 0:06:37.300000 --> 0:06:38.320000 in the database. 0:06:38.320000 --> 0:06:42.680000 Now in this case, we know that this application input is directly interacting 0:06:42.680000 --> 0:06:46.060000 with a database in some way or form. 0:06:46.060000 --> 0:06:49.220000 We're not too sure about the query, which actually makes sense because 0:06:49.220000 --> 0:06:51.660000 this is blind SQL injection. 0:06:51.660000 --> 0:06:56.100000 So the first thing we can do, as I say, is identify the application input, 0:06:56.100000 --> 0:07:00.160000 the injectable parameter, but now we need to test it and see, you know, 0:07:00.160000 --> 0:07:02.520000 whether we have any form of SQL injection. 0:07:02.520000 --> 0:07:06.900000 Now remember, this is blind Boolean based SQL injection and we're dealing 0:07:06.900000 --> 0:07:12.160000 with an integer here with regards to the value of the parameter. 0:07:12.160000 --> 0:07:16.180000 So that means we don't need to utilize the single quote to terminate the 0:07:16.180000 --> 0:07:19.480000 string literal. We can immediately go ahead and, you know, put in a logical 0:07:19.480000 --> 0:07:25.040000 operation here or a Boolean condition where you can say zero, one or the 0:07:25.040000 --> 0:07:28.900000 actual value or we say, or one equals one. 0:07:28.900000 --> 0:07:33.720000 And then we test out what comment works here based on the backend DBMS 0:07:33.720000 --> 0:07:35.760000 being used. So is it SQLite? 0:07:35.760000 --> 0:07:36.600000 Is it postgreSQL? 0:07:36.600000 --> 0:07:39.840000 Is it MySQL? We've already gone through this process. 0:07:39.840000 --> 0:07:43.060000 So I'll let enter and let's see what the output is. 0:07:43.060000 --> 0:07:45.400000 All right. So this is what I was talking about. 0:07:45.400000 --> 0:07:50.680000 I want you to pay close attention to what happens when we essentially 0:07:50.680000 --> 0:07:53.940000 inject a Boolean-based SQL injection payload. 0:07:53.940000 --> 0:07:58.320000 So in this case, what we've done is we've said post equals one and the 0:07:58.320000 --> 0:08:03.020000 value of, or rather, there is a post with an idea of one, which means 0:08:03.020000 --> 0:08:05.480000 that that evaluates to true. 0:08:05.480000 --> 0:08:08.220000 And then we're saying, or one equals one. 0:08:08.220000 --> 0:08:12.520000 All right. So what this means in this particular case, this is pretty 0:08:12.520000 --> 0:08:16.900000 inconsequential apart from the fact that all of the other blog posts are 0:08:16.900000 --> 0:08:18.320000 being listed here. 0:08:18.320000 --> 0:08:22.920000 This particular statement does not really confirm SQL injection. 0:08:22.920000 --> 0:08:27.800000 The reason I'm saying that is because we have this particular post ID 0:08:27.800000 --> 0:08:31.720000 exists. So if we were to change this to maybe post ID of five and then 0:08:31.720000 --> 0:08:36.540000 say, or one equals one, that would realistically confirm it. 0:08:36.540000 --> 0:08:40.520000 But we still don't know how the web application is going to respond to 0:08:40.520000 --> 0:08:42.280000 this. So I'll hit enter. 0:08:42.280000 --> 0:08:46.740000 And you can see in this particular case, it just returned the same result, 0:08:46.740000 --> 0:08:49.200000 all right, which is to be expected here. 0:08:49.200000 --> 0:08:52.860000 So, you know, we know that there isn't a post with an idea of five. 0:08:52.860000 --> 0:08:55.620000 So it will run the logical operation here. 0:08:55.620000 --> 0:08:57.700000 So or one equals one. 0:08:57.700000 --> 0:09:00.920000 And in this case, based on the query, it should display all of the other 0:09:00.920000 --> 0:09:03.720000 blog posts, which indeed it does. 0:09:03.720000 --> 0:09:09.340000 All right. Now this, as I said, is not yet a confirmation of SQL injection. 0:09:09.340000 --> 0:09:11.240000 And I'll explain why. 0:09:11.240000 --> 0:09:16.120000 All right. We can confirm this by tweaking our logical operation here. 0:09:16.120000 --> 0:09:19.920000 And what I'm going to do is I'm just going to go back to post one here. 0:09:19.920000 --> 0:09:24.440000 And I'll go into my web proxy, which is burp suite and turn on intercept. 0:09:24.440000 --> 0:09:26.940000 And I will just reload this page. 0:09:26.940000 --> 0:09:30.400000 All right. So this is what the request looks like. 0:09:30.400000 --> 0:09:31.760000 It is a get request. 0:09:31.760000 --> 0:09:35.900000 All right. And we can see that the parameter, the injectable parameter 0:09:35.900000 --> 0:09:38.900000 is in the URL and nothing else is in the body. 0:09:38.900000 --> 0:09:42.640000 So we can send this to the repeater where we can modify the request and 0:09:42.640000 --> 0:09:48.260000 view the responses based on specific parameters or tests we want to perform. 0:09:48.260000 --> 0:09:52.560000 So I'm just going to resize this so it matches a little bit better or 0:09:52.560000 --> 0:09:57.100000 it displays the actual HTTP request a little bit better. 0:09:57.100000 --> 0:10:00.480000 All right. So as I said, we were utilizing the or option. 0:10:00.480000 --> 0:10:06.060000 Now, what we want to do is not change the value of five, right? 0:10:06.060000 --> 0:10:07.200000 And I'll explain why. 0:10:07.200000 --> 0:10:13.120000 So if I change this to a five, you can see that it will essentially, in 0:10:13.120000 --> 0:10:16.420000 this particular case, let's render the output here. 0:10:16.420000 --> 0:10:19.900000 You can see that it, you know, gives us that blank page. 0:10:19.900000 --> 0:10:23.960000 And, you know, we have the comment model here as well as everything that 0:10:23.960000 --> 0:10:25.660000 was aligned to the right. 0:10:25.660000 --> 0:10:29.740000 So, you know, the search bar, the login form, the categories, etc. 0:10:29.740000 --> 0:10:32.440000 So let's try and run that operation one more time. 0:10:32.440000 --> 0:10:34.280000 Yes, so one equals one. 0:10:34.280000 --> 0:10:38.240000 And we need to URL encode this because it is being sent in the URL. 0:10:38.240000 --> 0:10:42.060000 So control you and we'll send this here. 0:10:42.060000 --> 0:10:43.640000 We take a look at the output. 0:10:43.640000 --> 0:10:47.880000 It looks like it is vulnerable to SQL injection based on how the web application 0:10:47.880000 --> 0:10:52.580000 responds. Of course, it doesn't respond with an error or data from the 0:10:52.580000 --> 0:10:57.680000 database because in this case, most likely the query is the query being 0:10:57.680000 --> 0:11:02.840000 used by the web application is pretty much going to is pretty much interacting 0:11:02.840000 --> 0:11:10.000000 with a particular table and is pulling data, you know, pertinent to blog 0:11:10.000000 --> 0:11:14.320000 posts, right? And in this particular case, the best way we can test all 0:11:14.320000 --> 0:11:18.780000 of this out is to play around with the logical operation. 0:11:18.780000 --> 0:11:22.320000 Yes, I'm just going to undo the URL and code here. 0:11:22.320000 --> 0:11:24.800000 And what if we say one equals two? 0:11:24.800000 --> 0:11:29.640000 All right, so this is now an operation that is going to be false in both 0:11:29.640000 --> 0:11:32.920000 cases, right? And we pretty much know what to expect. 0:11:32.920000 --> 0:11:37.200000 It should take us to that particular page that does not have any content 0:11:37.200000 --> 0:11:42.720000 in the body and just has the actual components that make up the web page. 0:11:42.720000 --> 0:11:48.240000 So the, you know, the comment form as well as the, you know, the login, 0:11:48.240000 --> 0:11:49.760000 the login form, etc. 0:11:49.760000 --> 0:11:53.700000 So login here, or I'll send that request here and you can see we pretty 0:11:53.700000 --> 0:11:54.600000 much get the same. 0:11:54.600000 --> 0:12:01.340000 So the key thing that I want you to note is that when there is an incorrect 0:12:01.340000 --> 0:12:07.820000 SQL query or a query that points that will provide a false response, the 0:12:07.820000 --> 0:12:12.640000 web application responds by taking us to a blank page with the rest of 0:12:12.640000 --> 0:12:14.580000 the components of the web page. 0:12:14.580000 --> 0:12:18.300000 All right, that's what looks like. 0:12:18.300000 --> 0:12:22.720000 That essentially is what's going on here with regards to how the web application 0:12:22.720000 --> 0:12:27.180000 is responding. Now we can confirm this, as I said, really well by saying 0:12:27.180000 --> 0:12:34.740000 something like one and then using the and operator, one and one is equal 0:12:34.740000 --> 0:12:38.600000 to one. And the reason we're doing this is we know that the post with 0:12:38.600000 --> 0:12:39.720000 an idea of one exists. 0:12:39.720000 --> 0:12:43.540000 So we're saying, okay, that exists. 0:12:43.540000 --> 0:12:46.180000 And I also want you to run this operation. 0:12:46.180000 --> 0:12:52.200000 Now, in this particular case, if either one of these operations fails 0:12:52.200000 --> 0:12:57.060000 with regards to returning a false value from the database or a false response 0:12:57.060000 --> 0:13:01.640000 from the database, we should be taken to this particular screen here based 0:13:01.640000 --> 0:13:03.580000 on the analysis we have performed. 0:13:03.580000 --> 0:13:08.800000 So we're essentially saying we're telling the web application, okay, post 0:13:08.800000 --> 0:13:11.500000 ID with one. Okay, we know that that exists. 0:13:11.500000 --> 0:13:16.880000 However, in order for this entire SQL query to be successful, both of 0:13:16.880000 --> 0:13:18.680000 these need to check out as true. 0:13:18.680000 --> 0:13:21.020000 And we know one equals one is always going to be true. 0:13:21.020000 --> 0:13:24.740000 So in this particular case, let's see what the output is or how the web 0:13:24.740000 --> 0:13:26.140000 application responds. 0:13:26.140000 --> 0:13:30.700000 So you are a little encode this here, and I'll send that over. 0:13:30.700000 --> 0:13:35.300000 And now in the response, you can see that now this is a proper confirmation 0:13:35.300000 --> 0:13:36.560000 of the SQL injection. 0:13:36.560000 --> 0:13:41.740000 The reason I'm saying that is because both of these operations need to 0:13:41.740000 --> 0:13:45.480000 be true. And now it doesn't display all of the other blog posts because 0:13:45.480000 --> 0:13:47.160000 everything is true. 0:13:47.160000 --> 0:13:51.900000 All right, now what if again, we change this to instead of one equals 0:13:51.900000 --> 0:13:56.440000 one, we change this to one equals two, which is going to be false and 0:13:56.440000 --> 0:14:01.900000 will therefore invalidate the entire query here, regardless of whether 0:14:01.900000 --> 0:14:07.960000 one is true or one is a legitimate idea of a real blog post. 0:14:07.960000 --> 0:14:12.520000 So the point being is and is very useful in these types of confirmation 0:14:12.520000 --> 0:14:18.320000 checks. The or is not really that useful because either one of the checks 0:14:18.320000 --> 0:14:24.680000 or operations needs to be correct in order for the entire query to be 0:14:24.680000 --> 0:14:27.320000 correct. So I'll give you an example here. 0:14:27.320000 --> 0:14:30.380000 So we'll say one and one equals two. 0:14:30.380000 --> 0:14:34.700000 So one will be true, which is the post idea of one, which does exist. 0:14:34.700000 --> 0:14:38.820000 However, this one here will be false because one is not equal to two. 0:14:38.820000 --> 0:14:43.040000 So I will highlight this and control you to URL and code it. 0:14:43.040000 --> 0:14:45.780000 And let's see what the application's response is. 0:14:45.780000 --> 0:14:47.280000 So there we are. 0:14:47.280000 --> 0:14:51.060000 It takes us to this blank page with the rest of the components of the 0:14:51.060000 --> 0:14:54.980000 web page. So based on what we've done thus far, we can we pretty much 0:14:54.980000 --> 0:14:59.480000 have an understanding of how the web application responds primarily if 0:14:59.480000 --> 0:15:06.440000 the SQL query or the web application returns a false returns the results 0:15:06.440000 --> 0:15:10.260000 as false or the results from the database are false. 0:15:10.260000 --> 0:15:14.540000 Now in this case, we've confirmed blind SQL injection because we were 0:15:14.540000 --> 0:15:20.460000 able to utilize the or one equals one option or logical operation there, 0:15:20.460000 --> 0:15:24.340000 firstly, to display all of the other blog posts on the same page. 0:15:24.340000 --> 0:15:30.300000 But now we're essentially verifying the Boolean operation or Boolean condition 0:15:30.300000 --> 0:15:34.860000 to test the logic and see whether it is accurate with regards to how the 0:15:34.860000 --> 0:15:36.600000 web application responds. 0:15:36.600000 --> 0:15:42.980000 So just to summarize or to go over it again, when you utilize and if you've 0:15:42.980000 --> 0:15:46.840000 ever done mathematics, and I think I can show you this here, we have or 0:15:46.840000 --> 0:15:49.580000 and and not. All right. 0:15:49.580000 --> 0:15:54.460000 So in the case of or we're essentially saying one of two in this particular 0:15:54.460000 --> 0:15:56.420000 case needs to be true. 0:15:56.420000 --> 0:16:00.960000 All right. So it will essentially evaluate the entire statement is true. 0:16:00.960000 --> 0:16:03.960000 So entire statement as true. 0:16:03.960000 --> 0:16:06.940000 And of course, never do this in the actual request or the body of the 0:16:06.940000 --> 0:16:11.220000 request. But and then in and we're essentially saying two out of two or 0:16:11.220000 --> 0:16:22.460000 as many need to be true in one out of two is true. 0:16:22.460000 --> 0:16:29.940000 The statement statement will return will essentially statement will equate 0:16:29.940000 --> 0:16:36.560000 to false because only one of the two operations has been met or conditions 0:16:36.560000 --> 0:16:41.360000 has been met. And in the case of not that one is not really applicable 0:16:41.360000 --> 0:16:45.200000 in this particular case, but you get the idea these are logical operations 0:16:45.200000 --> 0:16:50.420000 here. So we've actually confirmed this quite a lot based on the actual 0:16:50.420000 --> 0:16:52.460000 responses from the web application. 0:16:52.460000 --> 0:16:54.860000 And this is exactly what I was talking about. 0:16:54.860000 --> 0:16:58.880000 You're not going to get an error or confirmation of successful SQL injection 0:16:58.880000 --> 0:17:00.960000 or any data from the database. 0:17:00.960000 --> 0:17:04.940000 The web application will just respond in different ways. 0:17:04.940000 --> 0:17:07.000000 And of course, we can test this out as well. 0:17:07.000000 --> 0:17:11.460000 When we say, for example, a is equal to B, which is going to equate to 0:17:11.460000 --> 0:17:15.420000 false. We can just URL encode this and it should take us to this exact 0:17:15.420000 --> 0:17:17.240000 blank page here. 0:17:17.240000 --> 0:17:20.180000 That doesn't respond or give us any data. 0:17:20.180000 --> 0:17:22.400000 So I'll send that over. 0:17:22.400000 --> 0:17:24.060000 And there we are fantastic. 0:17:24.060000 --> 0:17:30.520000 However, now if we utilize the or option again and reverse the values 0:17:30.520000 --> 0:17:34.780000 of the parameter in a way that I can prove what I'm saying. 0:17:34.780000 --> 0:17:38.600000 So let's say we end up, you know, post ID of 10, right? 0:17:38.600000 --> 0:17:42.400000 Which we know doesn't exist based on initial testing. 0:17:42.400000 --> 0:17:47.640000 And we say, you know, and or in this particular case, or one equals one, 0:17:47.640000 --> 0:17:50.060000 we know that one equals one is going to be true. 0:17:50.060000 --> 0:17:51.680000 But this is not true here. 0:17:51.680000 --> 0:17:55.640000 So let's try and take a guess and let's see what will happen based on 0:17:55.640000 --> 0:17:57.140000 what we've just discussed. 0:17:57.140000 --> 0:18:01.760000 Based on what we've just discussed, this should display all blog posts. 0:18:01.760000 --> 0:18:09.640000 All right, you can see based on the test, not displaying the other blog 0:18:09.640000 --> 0:18:11.480000 posts, but they're linked here. 0:18:11.480000 --> 0:18:15.780000 So again, based on our testing, we can see that at this point, we actually 0:18:15.780000 --> 0:18:20.240000 don't even need this particular ID parameter to run our checks. 0:18:20.240000 --> 0:18:23.280000 So what we could say is just or one equals one. 0:18:23.280000 --> 0:18:26.260000 And let's test out, let's test this out and let's see what happens. 0:18:26.260000 --> 0:18:28.080000 So I'll send this over. 0:18:28.080000 --> 0:18:31.340000 And in this case, there's an error, right? 0:18:31.340000 --> 0:18:36.500000 And the reason for that might be because we don't have a delimiter there. 0:18:36.500000 --> 0:18:37.380000 Let's add that here. 0:18:37.380000 --> 0:18:38.920000 Let's see what happens. 0:18:38.920000 --> 0:18:40.740000 There we are still an error. 0:18:40.740000 --> 0:18:47.760000 So this is because of the or option, which is asking for is asking the 0:18:47.760000 --> 0:18:49.460000 database to run another operation. 0:18:49.460000 --> 0:18:55.000000 If we say and for example, in this particular case, I'll just get rid 0:18:55.000000 --> 0:19:01.240000 of this here. And if we say, you know, and one equals one, and let's URL 0:19:01.240000 --> 0:19:03.720000 encode this here, let's see what the response is. 0:19:03.720000 --> 0:19:06.580000 And again, I'm just running tests just to get a better understanding of 0:19:06.580000 --> 0:19:07.740000 what's going on. 0:19:07.740000 --> 0:19:11.140000 So in this case, it looks like it requires that parameter. 0:19:11.140000 --> 0:19:15.980000 What we can try and do instead of doing that is let's use the delimiter 0:19:15.980000 --> 0:19:21.440000 here. And let's send that over just to see whether it will process that 0:19:21.440000 --> 0:19:22.740000 second option here. 0:19:22.740000 --> 0:19:27.060000 So in this case, it looks like it needs a first value and then something 0:19:27.060000 --> 0:19:31.480000 after that. So you know, we could put in even an idea of 100, which again, 0:19:31.480000 --> 0:19:36.900000 doesn't exist. So if we send this over, you should see that it, you know, 0:19:36.900000 --> 0:19:38.080000 it takes us to the blank page. 0:19:38.080000 --> 0:19:44.940000 However, we can say or evaluate this option, one equals one. 0:19:44.940000 --> 0:19:49.740000 And if either one of them is true, then you know, this is going to be 0:19:49.740000 --> 0:19:54.640000 true. And in this case, it'll display, you know, in this particular case, 0:19:54.640000 --> 0:20:00.460000 what appears to be all of the blog posts within the blog posts table. 0:20:00.460000 --> 0:20:06.500000 So I can just control you to URL encode this and hit send. 0:20:06.500000 --> 0:20:08.640000 And it should display all blog posts. 0:20:08.640000 --> 0:20:09.380000 So there we are. 0:20:09.380000 --> 0:20:10.900000 Fantastic. All right. 0:20:10.900000 --> 0:20:15.280000 So we've been able to test out and confirm blind SQL injection by analyzing 0:20:15.280000 --> 0:20:18.100000 the behavior of the web application. 0:20:18.100000 --> 0:20:22.020000 And as I said, you're not limited to, you know, just running these very 0:20:22.020000 --> 0:20:24.300000 simple operations. 0:20:24.300000 --> 0:20:30.380000 What I wanted to show you specifically is how we can identify using Boolean 0:20:30.380000 --> 0:20:34.100000 based injection are the information regarding the database. 0:20:34.100000 --> 0:20:38.080000 So let's say we wanted to confirm and again, remember how the web application 0:20:38.080000 --> 0:20:41.580000 responds when an operation or Boolean operation is true. 0:20:41.580000 --> 0:20:44.180000 And now it responds when it's false. 0:20:44.180000 --> 0:20:48.640000 All right. So the point being is if I just undo this here, and I say one 0:20:48.640000 --> 0:20:58.080000 equals two, it should take us to that blank page. 0:20:58.080000 --> 0:21:01.180000 So whenever it's false, it takes us here. 0:21:01.180000 --> 0:21:06.000000 Okay. Now what if I wanted to run a quick check here where we can leave 0:21:06.000000 --> 0:21:12.940000 100 there and we can say or, and after this, we can utilize, in this particular 0:21:12.940000 --> 0:21:14.780000 case, we would need an end option. 0:21:14.780000 --> 0:21:18.660000 So we need to use the idea of a blog post that actually exists. 0:21:18.660000 --> 0:21:23.680000 So we'll use one and we'll say, and if we wanted to check the perform 0:21:23.680000 --> 0:21:30.120000 manual testing to identify the version at a high level of MySQL or the 0:21:30.120000 --> 0:21:33.800000 database that's running, in this case, we know it's MySQL. 0:21:33.800000 --> 0:21:36.760000 Of course, that enumeration can be performed. 0:21:36.760000 --> 0:21:41.000000 But we can essentially perform an additional operation where we check 0:21:41.000000 --> 0:21:46.560000 what the first character of the version of MySQL. 0:21:46.560000 --> 0:21:50.340000 And we can perform checks to see or identify which version it is. 0:21:50.340000 --> 0:21:53.520000 Right. So just the first version number. 0:21:53.520000 --> 0:21:57.840000 So, you know, version numbers in the case of in the case of MySQL and 0:21:57.840000 --> 0:22:02.120000 other software releases are, you know, 1.1.1.1. 0:22:02.120000 --> 0:22:06.400000 Right. In this particular case, we know that MySQL version three is still 0:22:06.400000 --> 0:22:11.300000 operational. So we might have 3.1, there could be a 4.0, there could be 0:22:11.300000 --> 0:22:16.460000 a 5.0. So based on these true or false responses, which we have now learned 0:22:16.460000 --> 0:22:24.480000 how to identify, we can pretty much run the following brackets will say 0:22:24.480000 --> 0:22:31.700000 version. And we want to check for the first, the first character, right? 0:22:31.700000 --> 0:22:36.700000 And we are going to say that's equals to and we can say, for example, 0:22:36.700000 --> 0:22:40.920000 in this particular case, we know that one is true. 0:22:40.920000 --> 0:22:43.740000 So there is a post to the idea of one. 0:22:43.740000 --> 0:22:49.060000 And in this particular case, remember, we are saying, can you please, 0:22:49.060000 --> 0:22:53.100000 in addition to, you know, checking for this particular blog post, can 0:22:53.100000 --> 0:22:55.000000 you also run this operation? 0:22:55.000000 --> 0:22:58.460000 And in this particular case, because of the end operator, both of them 0:22:58.460000 --> 0:22:59.880000 need to be true. 0:22:59.880000 --> 0:23:05.880000 So the point being, if the database or the backend DBMS is not MySQL version 0:23:05.880000 --> 0:23:08.820000 four, it will return as false. 0:23:08.820000 --> 0:23:12.000000 All right. And it'll take us to this particular page here. 0:23:12.000000 --> 0:23:16.460000 So if it's true, it will take us or display all blog posts. 0:23:16.460000 --> 0:23:20.340000 So it'll actually take us to the blog post one, sorry, not all blog posts. 0:23:20.340000 --> 0:23:24.000000 So we can control you to your land code this. 0:23:24.000000 --> 0:23:25.440000 And let's see what the response is.