Secure Coding in Node.
js
Advanced Edition
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 1
Introduction
• Seth Law
– VP of Research & Development @ nVisium
– Developer/Contributor of [Link], [Link],
SiRATool, RAFT, [Link]
– Hacker, AppSec Architect, Security Consultant
– Soccer Hooligan
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 2
Your App
Hopefully, not your App
[Link] + security = ???
[Link]
• Good
• The developer is in charge of the entire
HTTP interaction.
• Bad
• Your web server is only as secure as you
make it.
• Introduces trivial to exploit SSI depending
on programming techniques
Google + Security
70,000,000
60,000,000
50,000,000
40,000,000
Google + Security
30,000,000
20,000,000
10,000,000
0
[Link] Rails Django Flask Play Grails
October 5, 2015
[Link] docs
• Reporting a Bug
• Information Disclosure
Other resources
• [Link] - [Link] Security Checklist
• Config mgmt (Headers + data handling)
• Authentication
• Session Mgmt (Cookies + CSRF)
• Data Validation (XSS, SQLi, Command
Injection)
• Secure Transmission (SSL, HSTS)
• Denial of Service
• Error Handling
Houston, we have a problem
OWASP Top 10
• Injection • Sensitive Data
• Broken Authentication Exposure
& Session • Missing Function Level
Management Access Control
• Cross-Site Scripting • Cross-Site Request
• Insecure Direct Object Forgery
References • Using Components
• Security with Known Vulns
Misconfiguration • Invalidated Redirects
and Forwards
OWASP Top 10
• Injection • Sensitive Data
• Broken Authentication Exposure
& Session • Missing Function
Management Level Access Control
• Cross-Site Scripting • Cross-Site Request
• Insecure Direct Forgery
Object References • Using Components
• Security with Known Vulns
Misconfiguration • Invalidated Redirects
and Forwards
Agenda
• Vulnerabilities
• Insecure Direct Object Reference
• Mass Assignment
• Cross Site Request Forgery (CSRF)
• Business Logic Flaws
• Defenses
• Tools
Security Mindset
• All comes down to trust
• Trust you can defend against a reasonable
level of attacker skill set
• Trust you can recover from that which
you cannot prevent
• Your users can trust your product
• Your product does not trust its users
Vulnerabilities
• Why?
• Disclaimer
Insecure Direct Object Reference
• AKA IDOR
• Seeing a rise in the number of instances.
• Authorization
• Knowledge of identifier values is the only
thing required to access the associated
record.
IDOR
IDOR
• Changing an identifier value.
Insecure Direct Object Reference
• Mitigation
• Always check to see if a user has access to a resource
or function before operating on it.
• Access controls should be enforced at the controller
level, not the route level.
• This double checks access in the case that multiple
routes point to the same controller.
Mass Assignment
• AKA Data-Binding Attacks
• Active-record pattern abuse
• Add parameters to request to modify data
Mass Assignment
Mass Assignment
• Mitigation
• Don’t trust user input
• Only save/store expected parameters
CSRF
• AKA Session Riding, XSRF
• A web application will process all requests
that include authorization cookies, no
questions asked.
Problem?
CSRF
• Is not enabled by default
[Link]([Link]());
• Needs a little help
[Link](function (req, res, next) {
[Link] =
[Link]._csrf;
next();
});
CSRF
• Inside the view
<input type=hidden name=_csrf
value=“{{csrftoken}}“></input>
• Request is validated when Express sees the
token in:
• [Link]._csrf
• [Link]._csrf
• [Link][‘x-csrf-token’]
CSRF
• Issues (Express CSRF)
• Uses [Link] and session secret
• Multi-step process == mistakes
• Order matters! Must be included after
[Link]
• Express ignores tokens in GET, OPTIONS
and HEAD requests
• method-override anyone?
CSRF
Not so secret
CSRF
CSRF
• Mitigation
• Secret must be secret
• Any sensitive form
• Pay attention to RESTful APIs
• Periodically check code for CSRF
• QA tests?
Business Logic Flaws
• Is it possible to bypass steps?
• Process validation
• What about [Link]’ asynchronous
functions calls?
• Especially when dealing with authorization
decisions.
Demo
Control Flow ([Link])
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 42
Business Logic Flaws
• Mitigation
• Wait for asynchronous when making
authorization decisions.
• async library
Defense
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 44
Defense
• Strategy - Integrate into the SDLC
• Teach first ([Link])
• Design
• Test
• Test
• Test
• Start over
Defense
• Library Security
• Security Middleware
• [Link]
• [Link]
NPM
• 343 new modules/day
Node Security Project
Malicious Packages
[Link]
RequireSafe
[Link]
• [Link] • noSniff
• CSP (Content • frame guard
Security Policy) • xssFilter
• X-Powered-By
• HPKP
• HSTS
• ieNoOpen
• noCache
[Link] - Lusca
• Cross Site Request Forgery (CSRF)
• Content Security Policy (CSP)
• X-Frame-Options
• Platform for Privacy Preferences (P3P)
• HTTP Strict Transport Security (HSTS)
• X-XSS-Protection
Defense
• Tools - Static Code Analysis
• JSPrime
• ScanJS
• HP Fortify
• IBM AppScan Source
Defense
• JSPrime - Static Code Analysis
Defense
• ScanJS - Static Code Analysis
Defense
• ScanJS - Static Code Analysis
DEPRECATED
Tools
• Weaknesses
• Geared towards single pages/files
• Only effective at finding specific
vulnerabilities
• False Positives
• Fortify/AppScan/Veracode
Conclusion
Security is hard,
try harder
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 59
Questions?
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 60
Thank you
@sethlaw - Seth Law
seth@[Link]
Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · [Link] 61