WEBVTT - This file was automatically generated by VIMEO 1 00:00:01.400 --> 00:00:03.300 Welcome to cross-site scripting session. 2 00:00:06.300 --> 00:00:09.700 India's first part, we will focus on threat analysis. We 3 00:00:09.700 --> 00:00:13.300 will take our time to discuss, cross-site scripting details, then 4 00:00:12.400 --> 00:00:15.100 we will discuss how the system can be 5 00:00:15.100 --> 00:00:18.700 harmed, then, backed off, successful, exploitation, and 6 00:00:18.700 --> 00:00:21.100 give you some insights to identify who may want to 7 00:00:21.100 --> 00:00:24.700 harm your system. X access for cross-site scripting is 8 00:00:24.700 --> 00:00:27.200 a type of injection in which malicious scripts are 9 00:00:27.200 --> 00:00:31.400 injected into otherwise Bennigan's interested websites. We 10 00:00:31.400 --> 00:00:34.400 have already discussed injection flaws, but cross-site scripting 11 00:00:34.400 --> 00:00:35.600 was so prevalent. And 12 00:00:35.800 --> 00:00:38.500 Civic that it was given its own category in 13 00:00:38.500 --> 00:00:41.300 the last top 10. It has remained in 14 00:00:41.300 --> 00:00:44.200 the top 10 for several editions. Although it has 15 00:00:44.200 --> 00:00:47.600 dropped from 3rd to 7th in the 2017 top 16 00:00:47.600 --> 00:00:50.600 10. It is still the second most prevalent issue 17 00:00:50.600 --> 00:00:54.400 affecting around two-thirds of all applications. Let's 18 00:00:54.400 --> 00:00:57.400 see how it works. In this picture. We're 19 00:00:57.400 --> 00:01:00.400 searching for banana juice. We first 20 00:01:00.400 --> 00:01:03.700 type the keyword banana in the search field. The 21 00:01:03.700 --> 00:01:05.500 page was reloaded and the results. 22 00:01:05.700 --> 00:01:08.100 Matching our search criteria rendered on 23 00:01:08.100 --> 00:01:11.400 the screen. The Red Arrows point to places 24 00:01:11.400 --> 00:01:14.300 where our keyword appears on the page. Let's 25 00:01:14.300 --> 00:01:18.800 see this in terms of HTTP requests and responses, after 26 00:01:18.800 --> 00:01:21.700 typing our search keyword. Banana, an 27 00:01:21.700 --> 00:01:24.900 HTTP request is made to the server client issues, 28 00:01:24.900 --> 00:01:27.300 a get request and our keyword is 29 00:01:27.300 --> 00:01:30.200 sent as a query string parameter Q. When 30 00:01:30.200 --> 00:01:33.700 the server receives the request, it reads the query string parameter 31 00:01:33.900 --> 00:01:35.600 runs the database query to retrieve 32 00:01:35.700 --> 00:01:38.400 Records matching, our search criteria and 33 00:01:38.400 --> 00:01:41.800 then computes the final HTML output to be rendered client 34 00:01:41.800 --> 00:01:45.200 site with all matching records. Then 35 00:01:44.200 --> 00:01:47.400 the server responds to the client sending the 36 00:01:47.400 --> 00:01:50.600 final HTML to be rendered. Note that 37 00:01:50.600 --> 00:01:53.200 our keyword is also outputted as part of 38 00:01:53.200 --> 00:01:57.600 the HTML and this is where troubles begin. What 39 00:01:57.600 --> 00:02:00.300 If instead searching for banana, we decide to 40 00:02:00.300 --> 00:02:03.100 search for an HTML tag from the 41 00:02:03.100 --> 00:02:05.600 request point of view, everything Remains the Same. 42 00:02:05.700 --> 00:02:08.400 Same the server may not find any matching 43 00:02:08.400 --> 00:02:11.300 records in the database but is still outputs our 44 00:02:11.300 --> 00:02:14.700 searching keywords next to search results. Title, has 45 00:02:14.700 --> 00:02:17.100 highlighted with the red background, when 46 00:02:17.100 --> 00:02:20.400 the browser receives the HTML to render. It doesn't know that the 47 00:02:20.400 --> 00:02:23.700 highlighted part was provided as part of the request. It 48 00:02:23.700 --> 00:02:26.200 just knows that the server sends these HTML to 49 00:02:26.200 --> 00:02:29.100 be rendered. The HTML tags script has a 50 00:02:29.100 --> 00:02:32.400 special meaning, and the code inside the tag is executed that 51 00:02:32.400 --> 00:02:35.600 JavaScript popping up the model box saying X. 52 00:02:36.200 --> 00:02:39.600 In this scenario, sharing the URL with other users will 53 00:02:39.600 --> 00:02:42.400 trigger the same behavior in their browsers. Meaning 54 00:02:42.400 --> 00:02:46.000 that we can run arbitrary code remotely. There 55 00:02:45.200 --> 00:02:49.000 are two main types of X access server. 56 00:02:48.100 --> 00:02:51.600 X access is exactly what we have discussed 57 00:02:51.600 --> 00:02:54.700 until now, user-supplied data. Our 58 00:02:54.700 --> 00:02:57.600 search keyword is included in an HTML 59 00:02:57.600 --> 00:02:59.400 response generated by the server. 60 00:03:00.300 --> 00:03:03.600 In the described scenario. Our search keyword is not stored 61 00:03:03.600 --> 00:03:06.300 anywhere in the server. It is sent as part 62 00:03:06.300 --> 00:03:09.400 of the request and returned in the response due 63 00:03:09.400 --> 00:03:13.100 to this fact, it is called reflected server access 64 00:03:12.500 --> 00:03:15.600 if it was stored somewhere such 65 00:03:15.600 --> 00:03:18.500 as, in a database and later included in 66 00:03:18.500 --> 00:03:22.100 another response, such as a product reviews, then 67 00:03:21.100 --> 00:03:26.600 it would be called start accesses. The 68 00:03:26.600 --> 00:03:29.100 other type is client xss in 69 00:03:29.100 --> 00:03:29.900 this case, and 70 00:03:30.100 --> 00:03:33.300 To data such as a user supplied data is used to update the 71 00:03:33.300 --> 00:03:36.700 Dom using an unsafe, JavaScript call. Imagine 72 00:03:36.700 --> 00:03:39.400 that web application uses an API to perform product 73 00:03:39.400 --> 00:03:42.200 search. In this case, the server responds with 74 00:03:42.200 --> 00:03:45.400 a Json object, including the list of matching products when 75 00:03:45.400 --> 00:03:48.400 the API responses arrives, the web application copies, the 76 00:03:48.400 --> 00:03:51.100 content in the search input Fields appending it to 77 00:03:51.100 --> 00:03:54.500 the Dom next to the search results title, and then 78 00:03:54.500 --> 00:03:57.500 the list of matching products in this scenario, 79 00:03:57.500 --> 00:03:59.900 the X access payload was not part of sir. 80 00:04:00.200 --> 00:04:03.500 A response instead. It was gathered from client-side input 81 00:04:03.500 --> 00:04:05.100 field, and appended to the dawn. 82 00:04:06.300 --> 00:04:09.800 There's also reflected and start client access, but 83 00:04:09.800 --> 00:04:13.800 you're better reading about it in the WASP website. Let's 84 00:04:13.800 --> 00:04:15.600 discuss about attack vectors. 85 00:04:16.800 --> 00:04:19.700 Let's put things simple regarding X access 86 00:04:19.700 --> 00:04:22.100 attack. Vectors. You just have to 87 00:04:22.100 --> 00:04:26.400 focus on user controlled data, regardless its source, URL 88 00:04:26.400 --> 00:04:29.200 parameters and form. Data may be the first things to 89 00:04:29.200 --> 00:04:32.300 come to your mind, but there's a lot more. You 90 00:04:32.300 --> 00:04:36.000 should realize that users control the HTTP request and 91 00:04:35.500 --> 00:04:38.300 so request, headers and cookies may 92 00:04:38.300 --> 00:04:40.700 also be sources of hostile data. 93 00:04:41.700 --> 00:04:44.300 Browsers. Local storage is another typical attack 94 00:04:44.300 --> 00:04:47.300 Vector since malicious actors may be able to tamper with 95 00:04:47.300 --> 00:04:47.600 it. 96 00:04:49.100 --> 00:04:52.700 If your application expects file uploads, such as photos 97 00:04:52.900 --> 00:04:56.000 and then you reading the photos metadata, then 98 00:04:55.100 --> 00:04:58.100 it can also be used as an attack vector. 99 00:04:59.100 --> 00:05:03.000 Finally, a less obvious source of all style data, external 100 00:05:02.700 --> 00:05:06.000 Services. If the application retrieves 101 00:05:05.300 --> 00:05:08.300 data from other services, for example, by 102 00:05:08.300 --> 00:05:11.100 means of apis malicious actors, may 103 00:05:11.100 --> 00:05:14.600 decide to go after those third party Services, indirectly 104 00:05:14.600 --> 00:05:16.100 compromising your application. 105 00:05:17.300 --> 00:05:20.000 Any data source is a potential attack vector. 106 00:05:21.200 --> 00:05:24.700 Keep in mind that attackers will be able to execute code remotely on 107 00:05:24.700 --> 00:05:25.900 victims browsers. 108 00:05:27.100 --> 00:05:30.900 The first thing attackers will look for is a session tokens. If 109 00:05:30.900 --> 00:05:33.900 they can actual trade such token from a victim's browser, 110 00:05:33.200 --> 00:05:36.100 chances are they will be able to use it in 111 00:05:36.100 --> 00:05:39.300 another browser to impersonate the victim. This 112 00:05:39.300 --> 00:05:41.200 is called session hijacking. 113 00:05:42.700 --> 00:05:45.600 Even if session hijacking is not possible, attackers 114 00:05:45.600 --> 00:05:48.600 will be able to use JavaScript to automate tasks 115 00:05:48.600 --> 00:05:51.100 to scrape user data from the Dom or to do 116 00:05:51.100 --> 00:05:56.700 some actions on victims behalf. Such as fraud one transactions, being 117 00:05:56.700 --> 00:05:59.500 able to execute code remotely in specific Pages. 118 00:05:59.600 --> 00:06:02.700 Such as the login page may give attackers access 119 00:06:02.700 --> 00:06:05.400 to credentials. There are other techniques 120 00:06:05.400 --> 00:06:10.100 to trick the browser and password managers to lie credentials among 121 00:06:09.200 --> 00:06:12.400 other impacts attackers will always 122 00:06:12.600 --> 00:06:15.500 Able to exploit the trust relationship between the victim and 123 00:06:15.500 --> 00:06:18.200 the website Warner driving the former to 124 00:06:18.200 --> 00:06:21.700 download and install malware. Technical skills 125 00:06:21.700 --> 00:06:24.400 are required to identify and exploit the cross-site scripting 126 00:06:24.400 --> 00:06:27.800 vulnerability. Nevertheless. There are automated tools 127 00:06:27.800 --> 00:06:30.600 to assist this task and plenty of information about 128 00:06:30.600 --> 00:06:31.400 the subject. 129 00:06:32.500 --> 00:06:36.300 Threat agents, maybe after specific to victims targeting 130 00:06:35.300 --> 00:06:38.500 an application administrator may allow attackers 131 00:06:38.500 --> 00:06:41.700 to gain control over a privileged account and access sensitive 132 00:06:41.700 --> 00:06:43.400 data or shut down the system. 133 00:06:44.500 --> 00:06:47.100 On the other hand attackers may be interested in 134 00:06:47.100 --> 00:06:50.200 the particular individual. Let's say a VIP. 135 00:06:51.300 --> 00:06:54.500 If your application manages sensitive data, such as health 136 00:06:54.500 --> 00:06:58.000 records, a success xss exploitation 137 00:06:57.100 --> 00:07:00.600 may give attackers access to sensitive information 138 00:07:00.600 --> 00:07:02.000 regarding that individual. 139 00:07:03.200 --> 00:07:06.900 Xs/s. Can also be used for widespread attacks. It 140 00:07:06.900 --> 00:07:09.600 happens already in the past, creating a warm effect 141 00:07:09.500 --> 00:07:12.700 to identify threats agents. Consider, 142 00:07:12.700 --> 00:07:15.700 who may wants to gain control over your application and 143 00:07:15.700 --> 00:07:18.700 how sensitive is the information your application managers, 144 00:07:18.900 --> 00:07:20.600 and who may want to access it. 145 00:07:22.100 --> 00:07:25.200 You'll find this table in the last top 10. Pause 146 00:07:25.200 --> 00:07:27.500 the video and take your time to carefully, read it. 147 00:07:28.900 --> 00:07:31.600 The next part, we will exploit X access on 148 00:07:31.600 --> 00:07:33.600 our intentionally vulnerable application.