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