In this video we're going to take a look at the use of insecure components in web

applications.

The use of insecure components, or third-party packages or

libraries, is one of the most wide-spread flaws today.

Don't worry though, it's also one of the easier flaws to manage

in modern web applications with the right care.

When an application uses insecure components with known vulnerabilities, or

even non-public vulnerabilities known to certain attackers,

the application is in a bad spot.

These vulnerabilities often allow bypassing many or

all of the prior defense mechanisms we have discussed.

Since developers usually put their full trust into the third-party libraries used

in their application.

In most web frameworks, developers rely on a package ecosystem.

These packages could accidentally or even maliciously contain insecure code.

In the early days of the web, the visitor counters on webpages were often computed

with a tiny JavaScript library, which many developers pulled from a public website or

open source project.

However, these visitor counters were taken advantage of and

malicious code was inserted into them.

Affecting the sites of thousands of developers, since no vetting or

inspection was done to check the loaded scripts.

In Node.js specifically, NPM packages can create and

run scripts during installation and usage of the package.

They can read, write, update, or delete files in the system, or

even execute binary files.

Furthermore, they can collect sensitive data and

send it to remote servers in the case of many error inspection or login packages.

For all of this functionality, developers expect their lives to be made easier.

But as seen in the case of visitor counters, this isn't always the case.

Fortunately for us, there are ways to prevent this issue in practice.

[SOUND] First, you should try to find packages that include static code

analysis, which can help find some issues automatically.

[SOUND] Packages that have unit tests are also good choices,

as their functionality is explicitly enumerated with tests.

[SOUND] Code from packages should also be reviewed for places where weird things

could be occurring, like back doors to send users data to an attacker's server.

Believe it or not, that happens more often than you would hope.

[SOUND] Locking package versions is also useful,

as we discussed in the misconfiguration video.

[SOUND] Finally, not only can you do the proper research and

vetting of packages before use.

But companies and services provide tools to keep an eye on your application's

dependencies for published vulnerabilities.

Many of these preventions are straight forward, but some need more explaining.

For example, developers should always vet their packages for their popularity.

What other packages rely on it, the author, and

if any prior vulnerabilities were discovered in the package.

By building trust in the package, you can prevent falling into

using packages likely to be unmaintained or poorly written.

Furthermore, many third party tools exist to help detect

insecure package usage in projects.

Recently, GitHub has announced a feature that will scan code depositories, and

raise an issue if insecure packages are being used.

Other companies provide similar tools like Snyk.io and the Node Security Platform.

Both of these tools come highly recommended from the community, and

can detect issues in both Node.js packages and beyond, in the case of Snyk.

In our application we happen to be using an insure version of the Marked npm

package, which is a markdown parser with over 14,000 stars on GitHub.

In the version used by our application, there's a critical XSS vulnerability

that isn't patched, but was discovered and reported online.

From the dashboard,

we can go to the Memos page Here, we see we can enter memos with Markdown.

As an attacker, input forms are always worth testing, as we've seen over and

over again.

As it turns out, the version of the Marked library that

is being used in our application has an XSS vulnerability.

We can see that by checking out public pages on the issue.

This page describes an issue where the library is vulnerable to XSS

when attackers use HTML encoding combined with JavaScript code snippets.

Let's try to exploit the Memos page ourself by trying to insert an XSS

payload where we have encoded a special character as HTML.

Now anyone clicking on that link believes they'll see the company benefits, but

instead they could have an arbitrary script executed within their browser.

The string we inserted is just a straightforward JavaScript

alert function that's properly encoded.

However, Marked did not stop this from going through.

This could be much worse,

since a real attacker could have had that link send our cookies to their server.

And then take over our account, like we saw earlier in the XSS video