WEBVTT 00:00.620 --> 00:03.910 Hi and welcome back to the Knowledge Portal Video series. 00:03.920 --> 00:08.060 Today we are going to talk about Http trace request. 00:08.060 --> 00:15.020 Method Trace is generally used in the Http protocol for debugging related purposes. 00:15.680 --> 00:18.470 So let's look into what exactly trace is. 00:19.940 --> 00:20.930 Now. 00:20.930 --> 00:28.280 Generally, Internet is a very big network, so it can happen that you reside in India. 00:28.280 --> 00:34.400 So currently I reside in India, but the server that I'm querying to might reside in Russia or even 00:34.430 --> 00:35.120 us. 00:35.540 --> 00:42.560 So the request that I make it generally go can go through various proxy servers. 00:42.830 --> 00:47.750 In this example, there are two proxy servers to which the request is going. 00:47.870 --> 00:54.890 So when I make a request it goes to the first proxy server and from the first it goes to the second 00:54.890 --> 01:03.440 and from the second it goes to the destination server and same goes via the response. 01:03.440 --> 01:10.220 So from the destination server response comes to the cache proxy to the first cache proxy and back to 01:10.220 --> 01:11.570 the client. 01:12.830 --> 01:22.760 Now many times what happens is that whatever data that you send, a proxy cache can either modify the 01:22.760 --> 01:25.700 data or it can add its own headers. 01:25.700 --> 01:32.990 And due to that, the response that you get back is not what you are expecting of. 01:33.560 --> 01:36.470 Now, if we take a look at an example. 01:37.190 --> 01:45.590 So here you are sending a text file called as This is my data now it goes via multiple proxy links and 01:45.590 --> 01:48.080 maybe proxy is modifying the information. 01:48.080 --> 01:51.260 And here if you see this is our data. 01:51.260 --> 01:58.730 So mine is turned into R, so it can be possible that the data which is reaching the destination server 01:58.730 --> 02:02.910 is already modified by the middle links. 02:03.750 --> 02:09.210 Now how can a client know what exactly is reaching the server? 02:09.720 --> 02:13.860 And this is basically done through the Http trace method. 02:14.490 --> 02:22.350 Now what happens in Http trace method is whatever data the server receives or whatever the request, 02:22.350 --> 02:27.720 the Http request the server receives, the server will send the same request back to the client. 02:28.920 --> 02:32.850 Now this will be much more clearer if I show you an example. 02:32.850 --> 02:35.820 So I'll go to my favorite Linux machine this time. 02:38.160 --> 02:45.180 Now let me open the terminal and let's do a trace. 02:45.600 --> 02:53.760 So I'll do a trace on example.com and I'm getting a trace reply back. 02:53.760 --> 03:00.930 Now essentially what I'm getting over here is what I have sent through this particular curl request. 03:01.230 --> 03:08.400 So if you see the user agent is curl, so that means this is the request that we had sent it to the 03:08.400 --> 03:13.590 server and server responded with the same request. 03:14.610 --> 03:17.460 Now let's do one thing. 03:17.460 --> 03:23.940 Let's add a proxy server over here and let's modify it according to the example that we have seen. 03:24.030 --> 03:27.450 Now I have burpsuite over here, so I'll start a Burpsuite. 03:27.450 --> 03:29.340 I'll say Java jar Burpsuite. 03:44.040 --> 03:45.630 It's taking a bit of time. 03:45.630 --> 03:47.070 Yeah, and it's ready. 03:47.370 --> 03:47.940 Now. 03:47.940 --> 03:52.830 What we have is we have a proxy server between a client and the server. 03:53.310 --> 03:58.170 Now we'll play the same request, which is trace. 03:58.350 --> 04:01.920 Along with that, we'll say we'll add a proxy. 04:01.920 --> 04:06.600 I'll say 127001 colon 8080. 04:06.630 --> 04:10.080 This is where the burp suite listens to followed by example.com. 04:11.940 --> 04:15.340 Now this request is captured. 04:15.360 --> 04:19.320 Whatever request that I have sent from call is captured on the burp proxy. 04:19.320 --> 04:23.640 So if I go over here, this is the request that Curl has made. 04:23.850 --> 04:25.620 Now let's modify this. 04:25.650 --> 04:30.300 Let's say the proxy server has add a header and say. 04:33.000 --> 04:35.010 The evil.com. 04:35.490 --> 04:36.300 Ha ha ha. 04:36.600 --> 04:37.950 With the evil laugh. 04:38.250 --> 04:43.950 And let's forward this request to the example.com server. 04:45.300 --> 04:54.240 If I forward it back and in the response if we see the header has come the evil.com because the server 04:54.240 --> 05:03.870 which is running on the example.com has received this particular request and it responded with the same. 05:05.400 --> 05:10.140 So now it is possible for us to know that. 05:10.140 --> 05:16.760 What is the data that the interception proxy has added? 05:16.770 --> 05:23.310 So from here we can see that there is a header field, the evil.com that might possibly be added by 05:23.310 --> 05:25.050 the interception proxy. 05:25.620 --> 05:33.220 Now this is one of the reasons why the trace method was introduced where we can actually debug on what 05:33.220 --> 05:38.530 exactly we are sending from and what actually is received to the server. 05:39.310 --> 05:46.480 Now in the real world environment generally trace is disabled because it leads to a lot of security 05:46.480 --> 05:56.120 related issues and trace by default is disabled or it is not allowed in the nginx based web server. 05:56.140 --> 06:00.850 So if you want to try trace, then you need to have an Apache based instances. 06:01.720 --> 06:02.800 So this is it. 06:02.800 --> 06:04.150 About this lecture. 06:05.050 --> 06:10.240 I hope this has been informative for you and I'd really encourage you to try this out once more. 06:10.240 --> 06:12.550 Again, thank you very much for watching.