WEBVTT 0:00:13.660000 --> 0:00:17.680000 Exploiting time-based SQL injection vulnerabilities. 0:00:17.680000 --> 0:00:22.000000 In this video, we're going to get an introduction as to what time-based 0:00:22.000000 --> 0:00:26.980000 SQL injection vulnerabilities are, how they can be identified, and how 0:00:26.980000 --> 0:00:28.060000 they can be exploited. 0:00:28.060000 --> 0:00:33.380000 And one thing to keep in mind is this is, of course, a subtype of blind 0:00:33.380000 --> 0:00:38.880000 SQL injection, and it really doesn't differ that much from its counterpart, 0:00:38.880000 --> 0:00:42.520000 which, as you know, is Boolean -based SQL injection. 0:00:42.520000 --> 0:00:47.460000 The only difference is what you're monitoring in terms of the functionality 0:00:47.460000 --> 0:00:49.100000 of the web application. 0:00:49.100000 --> 0:00:54.320000 So with Boolean-based blind SQL injection, we were pretty much monitoring 0:00:54.320000 --> 0:01:00.260000 the actual functionality of the website, and what information or the way 0:01:00.260000 --> 0:01:04.000000 it responded back after we injected an SQL query. 0:01:04.000000 --> 0:01:08.960000 And we were sort of using that to infer whether our SQL query or our payload 0:01:08.960000 --> 0:01:11.000000 was injected successfully. 0:01:11.000000 --> 0:01:14.620000 With time-based SQL injection vulnerabilities, it's pretty much the same 0:01:14.620000 --> 0:01:19.220000 process. However, now, instead of monitoring the functionality and the 0:01:19.220000 --> 0:01:25.120000 responses of the actual website with regards to the payloads or the queries 0:01:25.120000 --> 0:01:28.940000 that we're injecting, we're now turning our attention to monitoring the 0:01:28.940000 --> 0:01:34.520000 response times of the actual web application that is vulnerable or could 0:01:34.520000 --> 0:01:36.340000 potentially be vulnerable. 0:01:36.340000 --> 0:01:40.000000 And you may be asking yourself, how do we go about doing this or how does 0:01:40.000000 --> 0:01:41.340000 time come into play? 0:01:41.340000 --> 0:01:44.280000 Well, this is something that we have already explored, I think, in the 0:01:44.280000 --> 0:01:49.360000 Finding SQL injection vulnerabilities manually video, where we took a 0:01:49.360000 --> 0:01:53.560000 look at the sleep command, the sleep SQL command that essentially delays 0:01:53.560000 --> 0:02:02.920000 the execution of the query or the response of the database with regards 0:02:02.920000 --> 0:02:07.200000 to our query. And we're essentially using that or injecting time-based 0:02:07.200000 --> 0:02:12.520000 parameters into our payload to essentially invoke or to get the database 0:02:12.520000 --> 0:02:17.740000 to either delay the execution or the response of the results for a certain 0:02:17.740000 --> 0:02:20.820000 amount of time. And the reason why we're doing that is so that we can 0:02:20.820000 --> 0:02:25.920000 actually tell if the query that we injected was executed successfully. 0:02:25.920000 --> 0:02:30.920000 So we're essentially saying, OK, the best way we can prove whether this 0:02:30.920000 --> 0:02:36.540000 site is vulnerable to SQL injection is through or is by leveraging the 0:02:36.540000 --> 0:02:41.460000 technique of telling the database to delay the execution or to delay the 0:02:41.460000 --> 0:02:48.420000 sending of the response or the results, therefore telling us or inferring 0:02:48.420000 --> 0:02:52.880000 that a SQL injection vulnerability exists or doesn't. 0:02:52.880000 --> 0:02:58.020000 So the point being is if you inject an SQL query and you tell the database 0:02:58.020000 --> 0:03:03.380000 to sleep for five seconds and you monitor the response and you see that 0:03:03.380000 --> 0:03:08.320000 it obeys that or that the response takes longer or matches the time parameter 0:03:08.320000 --> 0:03:12.600000 you specified in this case five seconds, then you know that your SQL query 0:03:12.600000 --> 0:03:14.660000 or payload was injected successfully. 0:03:14.660000 --> 0:03:17.700000 If it doesn't, they could be an issue with the syntax of your payload, 0:03:17.700000 --> 0:03:24.660000 but in most cases it means that it wasn't injected by the actual database. 0:03:24.660000 --> 0:03:27.140000 So really, really cool vulnerability. 0:03:27.140000 --> 0:03:30.820000 I'm a huge fan of time-based SQL injection vulnerabilities. 0:03:30.820000 --> 0:03:36.600000 So this video is really going to provide you with an introduction to time 0:03:36.600000 --> 0:03:40.220000 -based SQL injection vulnerabilities and will show you how to identify 0:03:40.220000 --> 0:03:41.480000 and exploit them. 0:03:41.480000 --> 0:03:44.820000 And of course, how to go about monitoring their response times based on 0:03:44.820000 --> 0:03:47.180000 the types of payloads you use. 0:03:47.180000 --> 0:03:53.200000 So as usual, let's revisit the SQL injection types and subtypes hierarchy 0:03:53.200000 --> 0:03:55.220000 tree to see where we are currently. 0:03:55.220000 --> 0:04:00.780000 So we've already covered in-band SQL injection and the consequent subtypes 0:04:00.780000 --> 0:04:02.840000 that fall under in-band SQL injection. 0:04:02.840000 --> 0:04:07.280000 We've also covered Boolean-based SQL injection, which falls under blind 0:04:07.280000 --> 0:04:11.720000 SQL injection. And we're now taking a look at the final subtype or technique, 0:04:11.720000 --> 0:04:13.960000 which is time-based SQL injection. 0:04:13.960000 --> 0:04:18.300000 So that begs the question, what is time-based SQL injection? 0:04:18.300000 --> 0:04:21.960000 Time-based SQL injection is a technique that is used to exploit vulnerabilities 0:04:21.960000 --> 0:04:26.660000 in a web application's database layer by manipulating the SQL queries 0:04:26.660000 --> 0:04:27.820000 to introduce delays. 0:04:27.820000 --> 0:04:33.880000 So we're trying to induce delays, and the fact that a delay occurs after 0:04:33.880000 --> 0:04:39.100000 injection proves that the query was executed by the database consequently 0:04:39.100000 --> 0:04:42.400000 proving that it is vulnerable to SQL injection. 0:04:42.400000 --> 0:04:45.080000 If it doesn't, then we know that either there's something wrong with our 0:04:45.080000 --> 0:04:49.600000 payload or the site isn't vulnerable to SQL injection, in this case, time 0:04:49.600000 --> 0:04:50.820000 -based SQL injection. 0:04:50.820000 --> 0:04:55.900000 So this type of attack relies on the ability to inject malicious SQL code 0:04:55.900000 --> 0:05:00.060000 that causes the application to pause or delay its response, revealing 0:05:00.060000 --> 0:05:03.000000 information about the database structure or data. 0:05:03.000000 --> 0:05:07.080000 The basic idea behind time-based SQL injection is to inject SQL statements 0:05:07.080000 --> 0:05:11.240000 that force the application to wait for a certain period of time before 0:05:11.240000 --> 0:05:14.980000 responding. The attacker can then infer information about the database 0:05:14.980000 --> 0:05:18.220000 by measuring the delay in the application's response. 0:05:18.220000 --> 0:05:21.940000 So if you tell the database within your query to sleep for five seconds, 0:05:21.940000 --> 0:05:26.140000 and you monitor the response, and you see that it actually returns the 0:05:26.140000 --> 0:05:29.820000 response or the web application response after five seconds, which is 0:05:29.820000 --> 0:05:34.760000 actually quite long, then you know, hey, my payload is was executed successfully. 0:05:34.760000 --> 0:05:38.160000 And of course, you can increase that duration, which is the great thing. 0:05:38.160000 --> 0:05:41.880000 So you can increase it to an absurd number, so 30 seconds. 0:05:41.880000 --> 0:05:45.700000 And if you get the response after 30 seconds, then you know for sure that 0:05:45.700000 --> 0:05:47.540000 your payload was executed. 0:05:47.540000 --> 0:05:52.260000 And this is sort of the essence of blind SQL injection. 0:05:52.260000 --> 0:05:55.400000 You're not really focused on the behavior of the web application with 0:05:55.400000 --> 0:06:02.420000 regards to how it handles results from the database, whether they be true 0:06:02.420000 --> 0:06:07.620000 or false. You're really focused on, you know, manipulating or getting 0:06:07.620000 --> 0:06:12.480000 the database to execute the query based on your own parameters, in this 0:06:12.480000 --> 0:06:17.060000 case, utilizing time-based parameters to essentially prove to you that, 0:06:17.060000 --> 0:06:22.400000 yes, this was executed by the database or, you know, vice versa to essentially 0:06:22.400000 --> 0:06:26.300000 prove that it wasn't executed by the database. 0:06:26.300000 --> 0:06:29.800000 So the key thing is that the attacker can infer information about the 0:06:29.800000 --> 0:06:33.520000 database by measuring the delay in the application's response. 0:06:33.520000 --> 0:06:36.900000 And here's an example of a time -based SQL injection attack. 0:06:36.900000 --> 0:06:40.580000 And let's assume we have a vulnerable login form, where a user provides 0:06:40.580000 --> 0:06:44.620000 the username and password, and the application performs an SQL query to 0:06:44.620000 --> 0:06:45.840000 validate the credentials. 0:06:45.840000 --> 0:06:49.900000 This is very common, always like revisiting the infamous login form. 0:06:49.900000 --> 0:06:54.400000 So the query is as follows, select all columns from the table called users, 0:06:54.400000 --> 0:06:58.860000 where the username is equal to, and then the value of the username parameter 0:06:58.860000 --> 0:07:03.400000 is passed in here as a string that is denoted by the single quotes, the 0:07:03.400000 --> 0:07:07.780000 double single quotes, and then there's also verification of the password 0:07:07.780000 --> 0:07:10.720000 or the value of the password parameter. 0:07:10.720000 --> 0:07:15.220000 So an attacker could exploit this vulnerability by injecting malicious 0:07:15.220000 --> 0:07:17.680000 SQL code that introduces a delay. 0:07:17.680000 --> 0:07:22.080000 For example, the attacker might provide the following input as the username. 0:07:22.080000 --> 0:07:25.760000 So you add the single quote here to terminate the string literal. 0:07:25.760000 --> 0:07:28.680000 That's because the parameter, username parameter is usually treated as 0:07:28.680000 --> 0:07:32.800000 a string. And then we utilize a logical operator or a Boolean operation, 0:07:32.800000 --> 0:07:36.900000 but in this case, we're essentially saying, yeah, you can go ahead and 0:07:36.900000 --> 0:07:39.640000 execute or try and find this user. 0:07:39.640000 --> 0:07:43.640000 Or if that fails, you can go ahead and run this command, which is sleep. 0:07:43.640000 --> 0:07:47.360000 So it'll tell the database to sleep for five seconds before, you know, 0:07:47.360000 --> 0:07:51.180000 the next request or before returning the response and then, you know, 0:07:51.180000 --> 0:07:53.780000 receiving the next set of queries. 0:07:53.780000 --> 0:07:58.480000 And then of course, we use the comment, the comment symbol here. 0:07:58.480000 --> 0:08:03.140000 Or essentially start up a comment to essentially ensure that the consequent 0:08:03.140000 --> 0:08:06.280000 query that checks the password is not executed. 0:08:06.280000 --> 0:08:12.500000 So, you know, you would be, this looks like a typical Boolean based SQL 0:08:12.500000 --> 0:08:15.420000 injection attack where we bypass the login. 0:08:15.420000 --> 0:08:19.520000 But in this case, of course, if we're dealing with blind SQL injection 0:08:19.520000 --> 0:08:23.860000 vulnerabilities, and it's not vulnerable to, you know, your typical Boolean 0:08:23.860000 --> 0:08:26.480000 based SQL injection attacks. 0:08:26.480000 --> 0:08:32.500000 Or payloads, then we can utilize the sleep timer here to essentially verify 0:08:32.500000 --> 0:08:36.540000 whether the query is being executed at all or not. 0:08:36.540000 --> 0:08:39.240000 And there's multiple payloads that you can utilize. 0:08:39.240000 --> 0:08:41.800000 And I'll hopefully I'll be able to show you quite a few of them. 0:08:41.800000 --> 0:08:46.540000 So the point is that the injected code, single quote, or sleep for five 0:08:46.540000 --> 0:08:51.400000 seconds and the comment symbol here modifies the original query to select 0:08:51.400000 --> 0:08:55.200000 all columns from the table called users where the username equals two. 0:08:55.200000 --> 0:08:59.260000 And then single quote terminates the string literal, or you can just sleep 0:08:59.260000 --> 0:09:00.400000 for five seconds. 0:09:00.400000 --> 0:09:04.440000 And the password is of course, and the consequent query that checks the 0:09:04.440000 --> 0:09:07.240000 password is not executed because of the comment here. 0:09:07.240000 --> 0:09:11.020000 In this particular case, the sleep function is causing the database to 0:09:11.020000 --> 0:09:15.200000 pause execution for five seconds before responding. 0:09:15.200000 --> 0:09:19.560000 If the application takes noticeably longer to respond, it indicates that 0:09:19.560000 --> 0:09:22.020000 the injected query is causing a delay. 0:09:22.020000 --> 0:09:25.480000 The attacker can then infer that the injection point is vulnerable to 0:09:25.480000 --> 0:09:27.080000 time based SQL injection. 0:09:27.080000 --> 0:09:30.640000 Of course, this value can be changed to whatever exorbitant number you 0:09:30.640000 --> 0:09:34.520000 want, so that at least you can verify it on your end. 0:09:34.520000 --> 0:09:38.520000 With that being said, this video has a lab environment attached to it. 0:09:38.520000 --> 0:09:42.080000 The lab environment will not provide you with your own calilinic system. 0:09:42.080000 --> 0:09:43.720000 So you'll need to utilize your own. 0:09:43.720000 --> 0:09:48.400000 We do require the use of a web proxy like burbsweet or OASP zap. 0:09:48.400000 --> 0:09:51.600000 The reason for that is because we're going to be modifying requests and 0:09:51.600000 --> 0:09:55.760000 then viewing the responses and consequently the response times to validate 0:09:55.760000 --> 0:10:03.040000 or to essentially identify and consequently exploit blind or in this particular 0:10:03.040000 --> 0:10:05.560000 case time based SQL injection vulnerability. 0:10:05.560000 --> 0:10:09.200000 So you can choose to watch the practical section before going through 0:10:09.200000 --> 0:10:11.800000 the lab or after it's entirely up to you. 0:10:11.800000 --> 0:10:13.720000 All you need to do is fire up the lab. 0:10:13.720000 --> 0:10:17.180000 It'll provide you with a link to the target web application, which is 0:10:17.180000 --> 0:10:19.660000 a real world web application. 0:10:19.660000 --> 0:10:23.320000 And I'm going to be utilizing my own calilinics VM because I have all 0:10:23.320000 --> 0:10:25.360000 the required tools in there. 0:10:25.360000 --> 0:10:29.940000 If you have a zap or burbsweet installed on Windows or your host operating 0:10:29.940000 --> 0:10:32.380000 system, that'll work just fine. 0:10:32.380000 --> 0:10:35.300000 With that being said, let me switch over into my calilinic system and 0:10:35.300000 --> 0:10:38.720000 we can get started. 0:10:38.720000 --> 0:10:42.780000 All right, I am back in my calilinics VM and I'm going to be utilizing 0:10:42.780000 --> 0:10:45.380000 burbsweet as my web proxy of choice. 0:10:45.380000 --> 0:10:48.380000 I'm just going to fire it up and I'm going to be utilizing the burbsweet 0:10:48.380000 --> 0:10:53.380000 browser just because it's already been pre-configured to proxy traffic 0:10:53.380000 --> 0:10:55.360000 through burbsweet. 0:10:55.360000 --> 0:11:02.080000 And I don't want to go ahead and configure my own browsers proxy configuration. 0:11:02.080000 --> 0:11:06.480000 We'll need a web proxy because again, as I said, we're going to be intercepting 0:11:06.480000 --> 0:11:10.800000 and again, then modifying requests and then essentially viewing the response 0:11:10.800000 --> 0:11:14.580000 times. So I'll head over into proxy and disable intercept for the time 0:11:14.580000 --> 0:11:17.580000 being and open up the Chromium browser here. 0:11:17.580000 --> 0:11:21.920000 There we are. And I'm going to paste in the link that the lab provided 0:11:21.920000 --> 0:11:31.660000 to me. And there we go. 0:11:31.660000 --> 0:11:33.140000 Web application. 0:11:33.140000 --> 0:11:41.020000 I can't really read Spanish, but it looks like this means username or 0:11:41.020000 --> 0:11:45.360000 authentication. And this is the demo instance. 0:11:45.360000 --> 0:11:48.560000 So you can access the demo by logging in as the user admin and password, 0:11:48.560000 --> 0:11:50.140000 which is actually great here. 0:11:50.140000 --> 0:11:54.500000 So the application input that's vulnerable to time-based SQL injection 0:11:54.500000 --> 0:12:00.760000 is this login form here where we have a username and password form. 0:12:00.760000 --> 0:12:04.340000 So, you know, for example, the typical thing you do at this point in time, 0:12:04.340000 --> 0:12:08.540000 if you know, if you're testing for SQL injection vulnerabilities is to 0:12:08.540000 --> 0:12:12.100000 try the single quote, obviously this would work because the username or 0:12:12.100000 --> 0:12:15.740000 the login parameter is going to be treated as a string based on the nature 0:12:15.740000 --> 0:12:17.520000 of the data that is going to be sent. 0:12:17.520000 --> 0:12:20.320000 It's not likely that that's going to be an integer. 0:12:20.320000 --> 0:12:24.120000 So we can use the single quote here and we hit enter and it's going to 0:12:24.120000 --> 0:12:25.860000 say that the password is required. 0:12:25.860000 --> 0:12:27.460000 I can translate a little bit here. 0:12:27.460000 --> 0:12:32.300000 So I'll just put in the single quote and a test password like, for example, 0:12:32.300000 --> 0:12:36.460000 you know, just random, random string there, hit enter. 0:12:36.460000 --> 0:12:38.560000 And we don't get an error. 0:12:38.560000 --> 0:12:42.440000 All right. So we're clearly not dealing with error based SQL injection. 0:12:42.440000 --> 0:12:44.180000 It may have been successful. 0:12:44.180000 --> 0:12:45.800000 However, we weren't able to tell. 0:12:45.800000 --> 0:12:49.740000 So we can try something a little bit more sophisticated like the infamous 0:12:49.740000 --> 0:12:54.960000 or one equals one and a password can just be password 456. 0:12:54.960000 --> 0:12:57.140000 And we hit log in. 0:12:57.140000 --> 0:12:59.260000 And yeah, we don't get any error. 0:12:59.260000 --> 0:13:04.500000 The web application is less than telling with regards to how it works 0:13:04.500000 --> 0:13:08.140000 and whether what we injected was successfully injected. 0:13:08.140000 --> 0:13:11.760000 So this is sort of the essence of blind SQL injection, right? 0:13:11.760000 --> 0:13:15.120000 And of course we took a look at one aspect of that with Boolean based 0:13:15.120000 --> 0:13:17.960000 SQL injection in the previous video. 0:13:17.960000 --> 0:13:20.260000 But this is this requires a little bit more nuance. 0:13:20.260000 --> 0:13:23.000000 So I'm going to enable my. 0:13:23.000000 --> 0:13:29.440000 I'm going to enable intercept here and we can just put in, for example, 0:13:29.440000 --> 0:13:30.740000 admin and password. 0:13:30.740000 --> 0:13:33.620000 We don't really need the real credentials and log in. 0:13:33.620000 --> 0:13:34.380000 So there we are. 0:13:34.380000 --> 0:13:37.380000 We have the get actually this is a post request. 0:13:37.380000 --> 0:13:39.380000 No parameters passed in the URL. 0:13:39.380000 --> 0:13:43.280000 However, the parameters and their values are passed in the body of the 0:13:43.280000 --> 0:13:45.540000 HTTP post request here. 0:13:45.540000 --> 0:13:49.160000 So we can send this to the repeater where we can modify the request and 0:13:49.160000 --> 0:13:52.220000 then send it and then view the response rapidly. 0:13:52.220000 --> 0:13:57.380000 So in here, what we could do now is of course, try and, you know, put 0:13:57.380000 --> 0:14:01.360000 in our payload or whatever you typically be required to do. 0:14:01.360000 --> 0:14:06.960000 So what we could do to invoke sleep here or the first payload we can try 0:14:06.960000 --> 0:14:11.900000 out with regards to blind SQL injection is to get the database to sleep 0:14:11.900000 --> 0:14:14.400000 for five seconds before responding. 0:14:14.400000 --> 0:14:19.960000 So we can say or sleep for five seconds and we'll use the pound symbol 0:14:19.960000 --> 0:14:24.400000 here because that seems to work or maybe not, but we'll perform URL encoding. 0:14:24.400000 --> 0:14:29.360000 So control plus you on your keyboard and we'll let's send and let's take 0:14:29.360000 --> 0:14:30.920000 a look at the response. 0:14:30.920000 --> 0:14:36.660000 In this particular case, it looks like it's taking a little bit longer, 0:14:36.660000 --> 0:14:38.680000 actually, than five seconds. 0:14:38.680000 --> 0:14:40.740000 So very, very interesting. 0:14:40.740000 --> 0:14:45.240000 This may be an issue with the use of the or command here. 0:14:45.240000 --> 0:14:48.720000 So in essence, what we're saying is if the username is not found, which 0:14:48.720000 --> 0:14:52.540000 we have not provided one, can you run this particular command here? 0:14:52.540000 --> 0:14:57.320000 So sleep for five seconds until, you know, and then you can respond or 0:14:57.320000 --> 0:14:59.180000 until the next request. 0:14:59.180000 --> 0:15:03.920000 However, this usually causes issues in MySQL databases. 0:15:03.920000 --> 0:15:05.040000 Primarily, there we are. 0:15:05.040000 --> 0:15:08.280000 So if you take a look at the bottom right here, burps with this one of 0:15:08.280000 --> 0:15:11.580000 the great features of burps with and also as Pzap is at the bottom, it 0:15:11.580000 --> 0:15:14.080000 tells you the response time in milliseconds. 0:15:14.080000 --> 0:15:18.780000 So one second is equal to a thousand milliseconds, which means 35,000 0:15:18.780000 --> 0:15:22.820000 milliseconds equals to 35 seconds and some change. 0:15:22.820000 --> 0:15:25.580000 So that obviously took more than five seconds. 0:15:25.580000 --> 0:15:29.820000 The reason it did that is again, essentially comes down to the actual 0:15:29.820000 --> 0:15:35.260000 logical operator we used here, where we essentially said, you know, if 0:15:35.260000 --> 0:15:37.840000 one fails, don't worry, you can run the other one. 0:15:37.840000 --> 0:15:45.120000 And, you know, if we can say, for example, and one equals one or one equals 0:15:45.120000 --> 0:15:55.660000 two, I just want to see what this would give us. 0:15:55.660000 --> 0:15:59.460000 Executed after five seconds, hopefully based on this logic, but that should 0:15:59.460000 --> 0:16:00.940000 be 5000 milliseconds. 0:16:00.940000 --> 0:16:03.580000 In this case, 260 milliseconds. 0:16:03.580000 --> 0:16:08.240000 So what we can do is let's set that to an operation that will always evaluate 0:16:08.240000 --> 0:16:14.180000 to true. So one equals one, as we already know, and you are a link code 0:16:14.180000 --> 0:16:15.980000 this and send that over. 0:16:15.980000 --> 0:16:20.080000 So in this case, it's going to execute this and then the sleep for five 0:16:20.080000 --> 0:16:23.800000 seconds and then it is going to also execute this. 0:16:23.800000 --> 0:16:29.360000 So again, it should take about, you know, 35,000 milliseconds or 35 seconds. 0:16:29.360000 --> 0:16:32.040000 And I'm just going to wait for it to actually provide me the response 0:16:32.040000 --> 0:16:36.120000 and I'll show you how we can actually verify this correctly because at 0:16:36.120000 --> 0:16:39.320000 this point, realistically speaking, we know that the sleep command is 0:16:39.320000 --> 0:16:41.180000 working or the sleep function is working. 0:16:41.180000 --> 0:16:46.420000 The only issue with it is it usually again waits for the next request, 0:16:46.420000 --> 0:16:47.020000 the get request. 0:16:47.020000 --> 0:16:50.800000 So I think I can actually prove this to you here. 0:16:50.800000 --> 0:16:58.080000 There we are. So 35,000, 35,000 milliseconds, which is 35 seconds. 0:16:58.080000 --> 0:17:04.300000 So I'll just get rid of this here and we can just say, or sleep for five 0:17:04.300000 --> 0:17:09.220000 seconds, right? And before we send it out, let me just, you are a link 0:17:09.220000 --> 0:17:14.180000 code this and I'll also go into proxy and for that request there.