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