In this video we're going to take a look at the use of insecure components in web 0:00 applications. 0:04 The use of insecure components, or third-party packages or 0:05 libraries, is one of the most wide-spread flaws today. 0:08 Don't worry though, it's also one of the easier flaws to manage 0:11 in modern web applications with the right care. 0:14 When an application uses insecure components with known vulnerabilities, or 0:17 even non-public vulnerabilities known to certain attackers, 0:20 the application is in a bad spot. 0:23 These vulnerabilities often allow bypassing many or 0:26 all of the prior defense mechanisms we have discussed. 0:29 Since developers usually put their full trust into the third-party libraries used 0:32 in their application. 0:36 In most web frameworks, developers rely on a package ecosystem. 0:38 These packages could accidentally or even maliciously contain insecure code. 0:42 In the early days of the web, the visitor counters on webpages were often computed 0:46 with a tiny JavaScript library, which many developers pulled from a public website or 0:50 open source project. 0:55 However, these visitor counters were taken advantage of and 0:56 malicious code was inserted into them. 1:00 Affecting the sites of thousands of developers, since no vetting or 1:02 inspection was done to check the loaded scripts. 1:05 In Node.js specifically, NPM packages can create and 1:08 run scripts during installation and usage of the package. 1:11 They can read, write, update, or delete files in the system, or 1:15 even execute binary files. 1:19 Furthermore, they can collect sensitive data and 1:21 send it to remote servers in the case of many error inspection or login packages. 1:23 For all of this functionality, developers expect their lives to be made easier. 1:28 But as seen in the case of visitor counters, this isn't always the case. 1:32 Fortunately for us, there are ways to prevent this issue in practice. 1:35 [SOUND] First, you should try to find packages that include static code 1:38 analysis, which can help find some issues automatically. 1:42 [SOUND] Packages that have unit tests are also good choices, 1:44 as their functionality is explicitly enumerated with tests. 1:48 [SOUND] Code from packages should also be reviewed for places where weird things 1:51 could be occurring, like back doors to send users data to an attacker's server. 1:55 Believe it or not, that happens more often than you would hope. 1:59 [SOUND] Locking package versions is also useful, 2:02 as we discussed in the misconfiguration video. 2:04 [SOUND] Finally, not only can you do the proper research and 2:06 vetting of packages before use. 2:10 But companies and services provide tools to keep an eye on your application's 2:11 dependencies for published vulnerabilities. 2:15 Many of these preventions are straight forward, but some need more explaining. 2:18 For example, developers should always vet their packages for their popularity. 2:22 What other packages rely on it, the author, and 2:26 if any prior vulnerabilities were discovered in the package. 2:30 By building trust in the package, you can prevent falling into 2:34 using packages likely to be unmaintained or poorly written. 2:36 Furthermore, many third party tools exist to help detect 2:40 insecure package usage in projects. 2:43 Recently, GitHub has announced a feature that will scan code depositories, and 2:46 raise an issue if insecure packages are being used. 2:49 Other companies provide similar tools like Snyk.io and the Node Security Platform. 2:53 Both of these tools come highly recommended from the community, and 2:58 can detect issues in both Node.js packages and beyond, in the case of Snyk. 3:01 In our application we happen to be using an insure version of the Marked npm 3:06 package, which is a markdown parser with over 14,000 stars on GitHub. 3:09 In the version used by our application, there's a critical XSS vulnerability 3:14 that isn't patched, but was discovered and reported online. 3:18 From the dashboard, 3:22 we can go to the Memos page Here, we see we can enter memos with Markdown. 3:23 As an attacker, input forms are always worth testing, as we've seen over and 3:28 over again. 3:33 As it turns out, the version of the Marked library that 3:34 is being used in our application has an XSS vulnerability. 3:37 We can see that by checking out public pages on the issue. 3:41 This page describes an issue where the library is vulnerable to XSS 3:44 when attackers use HTML encoding combined with JavaScript code snippets. 3:48 Let's try to exploit the Memos page ourself by trying to insert an XSS 3:53 payload where we have encoded a special character as HTML. 3:56 Now anyone clicking on that link believes they'll see the company benefits, but 4:14 instead they could have an arbitrary script executed within their browser. 4:19 The string we inserted is just a straightforward JavaScript 4:24 alert function that's properly encoded. 4:27 However, Marked did not stop this from going through. 4:29 This could be much worse, 4:32 since a real attacker could have had that link send our cookies to their server. 4:33 And then take over our account, like we saw earlier in the XSS video 4:37