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