WEBVTT - This file was automatically generated by VIMEO 1 00:00:02.800 --> 00:00:05.600 Welcome to the third and last part of the server-side request 2 00:00:05.600 --> 00:00:08.100 forgery session in this part. We 3 00:00:08.100 --> 00:00:10.800 will discuss server-side request forgery, mitigation. 4 00:00:12.200 --> 00:00:15.800 We will start discussing what makes an application vulnerable. Since 5 00:00:15.800 --> 00:00:18.400 I've asked Jude Shop is open source. We will spot 6 00:00:18.400 --> 00:00:21.100 the vulnerable source code. Then we will 7 00:00:21.100 --> 00:00:25.600 discuss how to avoid such a vulnerabilities applications 8 00:00:25.600 --> 00:00:28.600 that allow users to provide URLs to be retrieved from 9 00:00:28.600 --> 00:00:31.500 remote locations such as profile. Pictures are 10 00:00:31.500 --> 00:00:34.400 likely to be vulnerable to server-side request forgery. 11 00:00:35.300 --> 00:00:38.000 Other common scenario is when users are allowed to 12 00:00:38.500 --> 00:00:41.300 provide webhook handlers or a callback URLs that 13 00:00:41.300 --> 00:00:44.800 the server is supposed to contact. When some event occurs 14 00:00:44.700 --> 00:00:47.300 note that not always users have 15 00:00:47.300 --> 00:00:50.600 to provide complete URLs, Sometimes some user provided 16 00:00:50.600 --> 00:00:53.700 data. For instance, in a URL parameter or 17 00:00:53.700 --> 00:00:56.500 submitted on a form, may end up appended to 18 00:00:56.500 --> 00:00:59.100 an internal or external system base URL. 19 00:01:00.200 --> 00:01:04.000 Also note that some URL parsers do not handle URLs 20 00:01:03.800 --> 00:01:06.300 properly and that can be exploited by 21 00:01:06.300 --> 00:01:09.700 attackers to coerce the application to issue requests to 22 00:01:09.700 --> 00:01:11.300 unexpected locations. 23 00:01:12.800 --> 00:01:15.100 Let's see. What makes Juice Shop vulnerable. 24 00:01:18.400 --> 00:01:21.700 We've exploited server-side request forgery on a profile 25 00:01:21.700 --> 00:01:24.300 route. Let's find its implementation. 26 00:01:34.300 --> 00:01:36.500 This looks like a good candidate. 27 00:01:42.300 --> 00:01:46.100 On line 17, we have the user provided URL. 28 00:01:52.200 --> 00:01:55.800 And here we have the server-side request to 29 00:01:55.800 --> 00:01:58.800 fetch the image. As you can see, there 30 00:01:58.800 --> 00:02:01.300 is no validation upon the user provided URL. 31 00:02:02.800 --> 00:02:05.100 Let's put how the response is handled. 32 00:02:08.700 --> 00:02:11.900 In case the remote server returns some content. The 33 00:02:11.900 --> 00:02:14.700 local file extension is computed based 34 00:02:14.700 --> 00:02:17.500 on the user provided URL. If it 35 00:02:17.500 --> 00:02:20.300 is on the list, otherwise, it 36 00:02:20.300 --> 00:02:21.700 use a default extension. 37 00:02:37.300 --> 00:02:40.400 In this case, the file is named after our user ID 38 00:02:40.700 --> 00:02:42.500 plus the computed file extension. 39 00:02:49.200 --> 00:02:52.500 If the remote server fails to return a response, then the user profile 40 00:02:52.500 --> 00:02:55.200 is updated and the profile image set with the 41 00:02:55.200 --> 00:02:59.100 user provided URL and changed. Let's 42 00:02:58.100 --> 00:03:00.900 discuss how to prevent this issue. 43 00:03:01.200 --> 00:03:04.800 In general, it is a good security practice 44 00:03:04.800 --> 00:03:07.900 to denial Network traffic and exceptionally, 45 00:03:07.900 --> 00:03:10.700 allow Communications between two systems affect 46 00:03:10.700 --> 00:03:14.000 strictly required system components 47 00:03:13.200 --> 00:03:17.000 that are supposed to access remote resources, should use 48 00:03:16.500 --> 00:03:19.300 a separate Network. When the 49 00:03:19.300 --> 00:03:22.400 application fetch remote resources based on user 50 00:03:22.400 --> 00:03:25.900 provided input, either complete URLs 51 00:03:25.900 --> 00:03:28.800 or just some parameters, such input 52 00:03:28.800 --> 00:03:31.100 should be properly sanitized, according to the 53 00:03:31.300 --> 00:03:34.100 context where it will be used in forcing the 54 00:03:34.100 --> 00:03:37.800 URL, schema port and destination based 55 00:03:37.800 --> 00:03:40.800 on the positive list of allowed values may 56 00:03:40.800 --> 00:03:43.900 prevent the application to contact. Unexpected locations 57 00:03:43.200 --> 00:03:46.500 response is returned by 58 00:03:46.500 --> 00:03:49.100 other systems, shouldn't be sent to the 59 00:03:49.100 --> 00:03:52.700 client services since they may include sensitive information and 60 00:03:52.800 --> 00:03:57.000 HTTP. Redirection should be disabled. This. 61 00:03:56.100 --> 00:04:00.000 Is it about server-side request forgery, although 62 00:03:59.100 --> 00:04:01.100 it was not part of the 63 00:04:01.300 --> 00:04:04.300 Stop 10 2017 since it was added to 64 00:04:04.300 --> 00:04:07.600 the 20 21 Edition and it was the only should not 65 00:04:07.600 --> 00:04:10.100 covered in this course. We decided to add it 66 00:04:10.100 --> 00:04:13.500 later on to keep you up with the most critical web application, 67 00:04:13.500 --> 00:04:17.000 security risks, as Next Step, consider 68 00:04:16.300 --> 00:04:19.500 reading the last top 10, 20, 21, and 69 00:04:19.500 --> 00:04:21.400 other relevant or wasp resources.