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
- Angry bears 🐻
- Denial of service
- Malicious packages
- Accidental vulnerabilities
- Social engineering
- 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:
- left-pad
- eslint
- event-stream
- 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
- Gain credibility by helping
- Gain legitimate control of package
- 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
- Create useful package
- Submit PR adding useful package
- Package is integrated into victim
- 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: