WEBVTT - This file was automatically generated by VIMEO 1 00:00:00.900 --> 00:00:03.900 Welcome back to cross-site scripting session and 2 00:00:03.900 --> 00:00:06.500 the second part. We will exploit a cross-site scripting 3 00:00:06.500 --> 00:00:09.500 vulnerability in our Target application. We 4 00:00:09.500 --> 00:00:12.400 will jump straight to our intentionally vulnerable application and 5 00:00:12.400 --> 00:00:15.600 then move on to the mitigation part as 6 00:00:15.600 --> 00:00:18.400 discussed. In the previous part. We will test the product search 7 00:00:18.400 --> 00:00:21.100 feature and understand how it works. And whether it is 8 00:00:21.100 --> 00:00:22.900 vulnerable to cross-site scripting 9 00:00:24.200 --> 00:00:27.300 Let's pop up developer tools to inspect a network traffic. 10 00:00:36.600 --> 00:00:39.500 Note that our search keyword now also appears in 11 00:00:39.500 --> 00:00:41.900 the URL and in the pages body. 12 00:00:48.900 --> 00:00:51.600 The network, we can see request to search and 13 00:00:51.600 --> 00:00:54.100 point with the Q parameter, but it 14 00:00:54.100 --> 00:00:56.100 does not include our search keyword. 15 00:01:05.200 --> 00:01:08.300 In fact, the response returns all products and 16 00:01:08.300 --> 00:01:10.200 then they are filtered client site. 17 00:01:17.100 --> 00:01:21.100 If we find a vulnerability then it will be a client access 18 00:01:20.200 --> 00:01:22.500 as discussed before. 19 00:01:23.700 --> 00:01:25.500 Let's have a look at Pages dumb. 20 00:01:40.400 --> 00:01:43.300 Using another search keyword. We see that the Dom node 21 00:01:43.300 --> 00:01:44.200 is updated. 22 00:01:51.700 --> 00:01:54.600 Let's use the x axis pillowed. We used. As example 23 00:01:54.600 --> 00:01:56.200 in the first part of this session. 24 00:02:17.300 --> 00:02:20.200 The payload also appears in the URL, but this 25 00:02:20.200 --> 00:02:23.500 time, it isn't visible next to the search results title. 26 00:02:23.800 --> 00:02:26.100 Nevertheless. We can find it in the 27 00:02:26.100 --> 00:02:26.600 dome. 28 00:02:30.200 --> 00:02:33.500 The model box was not triggered. Meaning that our payload 29 00:02:33.500 --> 00:02:36.500 was not executed. Some Frameworks have 30 00:02:36.500 --> 00:02:39.100 X access prevention mechanisms. And this may be the 31 00:02:39.100 --> 00:02:42.600 case in such cases. We should try to bypass such 32 00:02:42.600 --> 00:02:44.700 mechanisms, testing different payloads. 33 00:02:46.500 --> 00:02:49.800 This is the original payload. Let's try something different 34 00:02:49.700 --> 00:02:52.300 this time. We will use an 35 00:02:52.300 --> 00:02:55.800 image tag with an empty Source, attribute. Meaning 36 00:02:55.800 --> 00:02:58.500 that loading image will fail in 37 00:02:58.500 --> 00:03:01.500 case of error and model box with the text X 38 00:03:01.500 --> 00:03:03.000 access should be shown. 39 00:03:07.500 --> 00:03:09.600 Let's copy and paste it in the search box. 40 00:03:15.300 --> 00:03:17.100 Here it is. Our model box. 41 00:03:21.200 --> 00:03:23.900 As you can see, the payload is also in the URL. 42 00:03:26.600 --> 00:03:29.200 It doesn't appear in the pages body, but it 43 00:03:29.200 --> 00:03:30.400 was added to the Dom. 44 00:03:32.900 --> 00:03:35.200 Since the payload is in the URL, if we 45 00:03:35.200 --> 00:03:38.100 send it to another user, then it will be executed in 46 00:03:38.100 --> 00:03:39.200 the users browser. 47 00:03:52.300 --> 00:03:55.600 Let's go a step further, first. We need to know what 48 00:03:55.600 --> 00:03:59.000 information is stored in the browser when we are authenticated. 49 00:04:37.600 --> 00:04:40.600 We have several cookies and 50 00:04:40.600 --> 00:04:43.600 one item in the local storage. The 51 00:04:43.600 --> 00:04:46.600 token is also stored as a cookie in 52 00:04:46.600 --> 00:04:50.600 both are used for authentication purposes. The 53 00:04:50.600 --> 00:04:53.400 value is a Json web token, which we can decode and 54 00:04:53.400 --> 00:04:56.800 see what's inside. As long as the payload section, is not encrypted. 55 00:05:19.700 --> 00:05:22.500 In this case, we can see the email password and 56 00:05:22.500 --> 00:05:24.500 role among several other details. 57 00:05:28.900 --> 00:05:31.400 Let's now change our X access payload to 58 00:05:31.400 --> 00:05:35.200 show tokens value. In the model box, instead of the word xss. 59 00:05:51.100 --> 00:05:54.100 Instead of typing the payload in the search input field. We 60 00:05:54.100 --> 00:05:57.000 can craft a malicious URL to send to our victims. 61 00:06:15.500 --> 00:06:19.200 Assuming Juice Shop admin receives and visits this URL. Then 62 00:06:18.200 --> 00:06:21.500 the model box should show the value of admins 63 00:06:21.500 --> 00:06:22.000 token. 64 00:06:25.600 --> 00:06:28.200 Instead of opening a model box, attackers can 65 00:06:28.200 --> 00:06:31.500 use other techniques to receive the value on the servers controlled 66 00:06:31.500 --> 00:06:32.000 by them. 67 00:06:33.100 --> 00:06:36.300 Assuming this is what happened. Let's see, what an attacker can 68 00:06:36.300 --> 00:06:38.400 do with the token on each one browser. 69 00:06:55.600 --> 00:06:58.700 As you can see, there's no active session in attackers browser. 70 00:07:11.800 --> 00:07:14.900 The browser doesn't have a cookie called token. So 71 00:07:14.900 --> 00:07:17.300 we will create one with the value stolen from 72 00:07:17.300 --> 00:07:18.200 victims browser. 73 00:07:27.200 --> 00:07:29.300 We have to do the same in the local storage. 74 00:07:44.500 --> 00:07:45.900 Now, if you reload the page. 75 00:07:52.600 --> 00:07:55.000 We are authenticated as Joyce shop. Admin. 76 00:08:18.500 --> 00:08:21.800 This is called session hijacking. One of x-axis possible 77 00:08:21.800 --> 00:08:24.200 consequences. And from now on we can 78 00:08:24.200 --> 00:08:27.600 act on admins behalf. Next we 79 00:08:27.600 --> 00:08:30.200 will discuss what makes the application vulnerable and 80 00:08:30.200 --> 00:08:31.200 how to prevent it.