WEBVTT - This file was automatically generated by VIMEO

1
00:00:02.700 --> 00:00:05.600
 Welcome back to the server side request forgery session.

2
00:00:06.700 --> 00:00:09.500
 In this second part, we will exploit server-side request

3
00:00:09.500 --> 00:00:13.800
 forgery in our intentionally. Vulnerable application. We

4
00:00:13.800 --> 00:00:16.600
 will jump straight to our intentionally vulnerable application, and

5
00:00:16.600 --> 00:00:18.800
 then move on to the mitigation part.

6
00:00:22.400 --> 00:00:25.100
 As discussed in the previous part nowadays. It is

7
00:00:25.100 --> 00:00:28.600
 common allowing users to provide a URL to fetch a resource as

8
00:00:28.600 --> 00:00:31.100
 an alternative to file uploads. This is a

9
00:00:31.100 --> 00:00:34.500
 feature. We usually find as part of the user profile settings to

10
00:00:34.500 --> 00:00:37.200
 choose a profile picture. Let's sign up

11
00:00:37.200 --> 00:00:40.000
 for an account and see if George shop offers such a feature.

12
00:01:31.900 --> 00:01:34.700
 And here it is. The feature we were looking for.

13
00:01:34.200 --> 00:01:37.200
 Let's play a bit with it to understand how it

14
00:01:37.200 --> 00:01:37.700
 works.

15
00:02:02.300 --> 00:02:05.600
 Based on what we can see here. In the Dom, the server, fetch

16
00:02:05.600 --> 00:02:08.400
 the image based on the given URL and stored it

17
00:02:08.400 --> 00:02:11.500
 locally. Let's see what happens if the URL

18
00:02:11.500 --> 00:02:12.600
 points to nowhere.

19
00:02:42.900 --> 00:02:45.400
 In this case, the application used given URL, is

20
00:02:45.400 --> 00:02:48.300
 this only based on this Behavior, we

21
00:02:48.300 --> 00:02:51.300
 can use this feature to understand what internal services are

22
00:02:51.300 --> 00:02:52.500
 running in the server.

23
00:03:11.800 --> 00:03:14.300
 Since no local resource was created. No,

24
00:03:14.300 --> 00:03:17.600
 internal service is listening on Port 80. Let's

25
00:03:17.600 --> 00:03:18.400
 try another one.

26
00:03:35.100 --> 00:03:38.500
 Again, no, internal service. Listening on Port. 80

27
00:03:38.500 --> 00:03:40.900
 8. Let's try it once more.

28
00:04:05.700 --> 00:04:08.500
 This time a local resource was created. Meaning

29
00:04:08.500 --> 00:04:11.700
 there's an internal service listening on Port 3000.

30
00:04:19.400 --> 00:04:22.300
 The application backend server expects, given URL, to

31
00:04:22.300 --> 00:04:25.300
 point to an image file, but URL, we provided is

32
00:04:25.300 --> 00:04:28.100
 unlikely to return an image. Let's download the

33
00:04:28.100 --> 00:04:30.700
 local resource in play with its extension.

34
00:04:46.500 --> 00:04:49.400
 Despite the file extension. Let's check. It's mime type.

35
00:05:01.200 --> 00:05:04.800
 In fact, what's inside? The file is HTML. What

36
00:05:04.800 --> 00:05:07.900
 would be much more likely to be returned by an HTTP service?

37
00:05:07.400 --> 00:05:09.700
 Listening on random port?

38
00:05:24.500 --> 00:05:27.600
 Based on the content. What we have is the Juice Shop homepage

39
00:05:27.600 --> 00:05:30.300
 market. Now. We have an idea of

40
00:05:30.300 --> 00:05:33.500
 Juice Shop internals since the public address,

41
00:05:33.500 --> 00:05:36.500
 used the default HTTP Port, but internally,

42
00:05:36.500 --> 00:05:39.200
 the mark-up is returned by a service listening on

43
00:05:39.200 --> 00:05:42.200
 Port 3000. We can assume that

44
00:05:42.200 --> 00:05:45.400
 there's a reverse proxy in the middle and Juice Shop. Back-end

45
00:05:45.400 --> 00:05:49.000
 server is likely to run inside the container. It

46
00:05:48.100 --> 00:05:51.300
 may not sound that impressive but you can keep

47
00:05:51.300 --> 00:05:54.000
 trying other port numbers to scan, what services?

48
00:05:54.300 --> 00:05:57.000
 Running internally as well as different resources.

49
00:05:58.300 --> 00:06:01.200
 Keep in mind that the services you may Reach exploiting This

50
00:06:01.200 --> 00:06:04.600
 vulnerability. They believe that it's the Jewish shop back-end

51
00:06:04.600 --> 00:06:08.000
 server, who is making the requests sometimes,

52
00:06:07.400 --> 00:06:10.600
 because internal Services tend to trust another

53
00:06:10.600 --> 00:06:13.700
 internal Services relying on the request origin.

54
00:06:13.900 --> 00:06:16.700
 You may end up accessing sensitive, internal data.

55
00:06:17.900 --> 00:06:20.200
 In our next video, we will discuss what makes

56
00:06:20.200 --> 00:06:22.700
 the application vulnerable and how to prevent it.