This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
Further Reading:
Introducing Security Alerts on GitHub, by Miju Han
OWASP Insecure Components
OWASP Dependency Check tool
Node Security Platform
-
Snyk.io - Snyk helps you use open source and stay secure by continuously finding and fixing vulnerabilities in your dependencies.
-
NPM-check - Check for outdated, incorrect, and unused dependencies.
- Bithound.io (like Snyk) - Comprehensive code and dependency analysis for Node.js
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
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
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up