Securing JavaScript

Web Directions Code, 2019-06-20

Read these slides on your own device:

Who is this guy?

Laurie Voss

Chief Data Officer & co-founder, npm Inc.

@seldo

What are we talking about?

  • The modern JavaScript landscape
  • Threat models for JavaScript
  • Major incident case studies
  • Using npm more securely
  • What's next for JavaScript security

Disclaimer 1:

This talk is kind of a downer

Sorry.

Disclaimer 2:

I curse like a drunken sailor

I'm not actually sorry.

JavaScript is the most popular programming language in the world

11 million JavaScript developers worldwide

99% of JavaScript

developers use npm

1 million packages

JavaScript: biggest on GitHub

JavaScript: biggest on Stack Overflow

12 billion weekly downloads

26,000% growth since 2014

of the code in a modern web app is downloaded from npm

97%

  • A modern web app will use > 2,000 packages
  • A big company will use > 25,000 packages

Β Open source JavaScript is a huge win

But it's not free.

npm is a security company

npm survey: are you concerned about security?

Security practices

What is a security failure?

A thing that steals data?

A thing that takes your site down?

Anything that can allow a malicious act to hurt users is a security failure

Even if nobody gets hurt.

I cannot teach you how to write secure code

At least, not for this kind of money.

Secure code is the same across all languages:

  • Defense in depth
  • Input validation
  • Provenance

Threat models

  1. Angry bears 🐻
  2. Denial of service
  3. Malicious packages
  4. Accidental vulnerabilities
  5. Social engineering
  6. Compliance failures

Angry bears

Drop bears: the silent killer

Denial of Service

Registry uptime 2016-present:

99.98%

But... left-pad!

Malicious packages

Malicious packages are less than 0.1% of publishes

and less than 0.005% of packages (because we delete them)

Accidental vulnerabilities

33% of npm installs include vulnerable packages

~99% of vulnerable JavaScript is from outdated dependencies

Accidentally vulnerable packages are the biggest threat to JavaScript security

Case study:

the financial industry

Big 8 banks

a security analysis

  • 23 million downloads
  • 22,563 unique packages
  • 824 vulnerabilities (3% of packages)
  • 55 critical vulnerabilities (7% of vulnerabilities)

I don't want to be alarmist but this is alarming

Social engineering

You ship code

from thousands of strangers to production every day

Compliance failures

29% of JavaScript devs can't use certain licenses

WTFPL:

it's funny but nobody likes it

The banks are at it again

100% compliance failure

at 8 of the world's biggest banks

Why is this so hard?

JavaScript snuck up on enterprises

You can't just hope

nobody notices how much JavaScript you're using

Security in JavaScript is different

You can't use

manual processes

for 25,000 packages

Blacklists and whitelists

will not work for you

The scale of JavaScript demands automation of security and compliance

JavaScript threats: a summary

  • Bears: πŸ™„
  • Uptime: 😐
  • Malicious code: πŸ˜•
  • Accidental vulnerabilities: 😳
  • Social engineering: 😱
  • Compliance failures: 🀯

Security case studies:

  1. left-pad
  2. eslint
  3. event-stream
  4. electron-native-notify

Case 1: left-pad

Please do not bother to write down the URL above. These slides are at slides.com/seldo/securing-javascript

It padded. Left.

Kik

Somebody already had a package called kik

Package name transfers are usually very friendly!

A policy failure

Azer took his toys

and went home

He turned out to have a LOT of toys.

The WTFPL

Ok, the purpose of this license is simple
and you just
DO WHAT THE FUCK YOU WANT TO.

This is the full text of the WTFPL.

Un-unpublishing

String.prototype.padStart()

supported by Node.js and every browser except Internet Explorer

Reliability is security

New unpublish policy

left-pad was an uptime problem

Case 2: eslint

Credentials harvester

It didn't work

2FA is not enough

Lesson 1: Supply chain attacks are real

We hadn't seen one before!

Lesson 2:

2FA needs enforcement

eslint was a design failure

Case 3: event-stream

The event-stream attack

  1. Gain credibility by helping
  2. Gain legitimate control of package
  3. Add malicious payload

Lesson 1:

11 million developers are a great detection system

Lesson 2: Maintainer burnout is an attack vector

event-stream

was a social failure

Case 4: electron-native-notify

Another helpful black hat

  1. Create useful package
  2. Submit PR adding useful package
  3. Package is integrated into victim
  4. Add malicious payload in minor update

Lesson: contributors can be malicious

"I'm definitely not a threat."

What is npm doing

about all of this?

Team A | Team B

The unpublish policy

The registry is immutable...ish

npm audit

335,775,921 audits last 30 days

npm audit

often tells you to run npm

npm audit fix

Semantic Versioning (SemVer)

1.5.3

Breaking

(major)

Feature

(minor)

Fix

(patch)

npm audit fix

follows SemVer

npm best practices:

audit in tests

npm config set audit-level severe

2FA

  • 7% of maintainers have 2FA enabled
  • > 50% of downloads are 2FA protected
  • 2FA enforcement is available
  • 2FA enrollment grew 360% in 6 month

Automatic token revocation

From the npm Registry and GitHub

Author package signing?

Registry-signed packages

The Report Vulnerability button

The npm Security Team

Automated threat detection

Single Sign-On (SSO)

npm Enterprise

  • yourco.npme.io
  • Share and discover internal JS
  • Full search
  • Package pages and online docs
  • SSO (Google, Okta, Auth0, etc.)
  • Security and compliance reporting

Future steps

✨ mAcHiNe LeArNiNg ✨

Fuck static analysis

What about the blockchain?

Do not get me started about the blockchain.

Social engineering

Improving social signals

Maintainer burnout

is a problem you can fix

Security is hard

Your paranoia is justified

They really are out to get you.

I ❀️ you

@seldo

laurie@npmjs.com

Slides available:

Securing JavaScript

By seldo

Securing JavaScript

  • 1,093

More from seldo