SFNode - Secure Coding with Node.js

As we all knew it would, JavaScript has finally overtaken the server. This departure from the client to the server introduces a number of security issues and problems that the language does not handle by default. This slide deck covers and demonstrates prevalent security vulnerabilities in Node.js applications as shown on February 4, 2016 during a SFNode meetup.

Transcript

1. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 1 Secure Coding with Node.js Seth Law @sethlaw
2. • Seth Law • VP of Research & Development @ nVisium • Developer/Contributor - Swift.nV, Django.nV, SiRATool, RAFT, goat.js • Hacker, AppSec Architect, Security Consultant • Soccer Hooligan Introduction
4. Your App
5. Hopefully, not your App
6. node.js + security = ???
8. • 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 Node.js
10. • Reporting a Bug • Information Disclosure nodejs.org docs
11. • blog.risingstack.com - Node.js 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 Other resources
12. Houston, we have a problem
13. • Injection • Broken Authentication & Session Management • Cross-Site Scripting • Insecure Direct Object References • Security Misconfiguration • Sensitive Data Exposure • Missing Function Level Access Control • Cross-Site Request Forgery • Using Components with Known Vulns • Invalidated Redirects and Forwards OWASP Top 10
14. • Injection • Broken Authentication & Session Management • Cross-Site Scripting • Insecure Direct Object References • Security Misconfiguration • Sensitive Data Exposure • Missing Function Level Access Control • Cross-Site Request Forgery • Using Components with Known Vulns • Invalidated Redirects and Forwards OWASP Top 10
15. • Vulnerabilities • Insecure Direct Object Reference • Cross Site Request Forgery (CSRF) • Business Logic Flaws • Defenses • Tools Agenda
16. • 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 Security Mindset
18. • waiting_room.jsp?group_id=7 • … • waiting_room.jsp?group_id=1 • … • 45 minutes advantage IDOR
19. ….and this is IDOR.
20. • So easy your technically incompetent neighbor has done it. • Seeing a rise in the number of instances. • Authorization • Knowledge of identifier values is the only thing required to access the associated record. Insecure Direct Object Reference
21. • In Node - stolen from Node Goat Insecure Direct Object Reference
22. • 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. Insecure Direct Object Reference
23. • A web application will process all requests that include authorization cookies, no questions asked. CSRF
24. Problem?
25. • AKA Session Riding • Is not enabled by default in Node.js app.use(express.csrf()); • Needs a little help app.use(function (req, res, next) { res.locals.csrftoken = req.session._csrf; next(); }); CSRF
26. • Inside the view <input type=hidden name=_csrf value=“{{csrftoken}}“></input> • Request is validated when Express sees the token in: • req.body._csrf • req.query._csrf • req.headers[‘x-csrf-token’] CSRF
27. • Issues (Express CSRF) • Uses Math.random and session secret • Multi-step process == mistakes • Order matters! Must be included after express.session • Express ignores tokens in GET, OPTIONS and HEAD requests • method-override anyone? CSRF
28. CSRF
29. Not so secret
30. CSRF
31. • Mitigation • Secret must be secret • Any sensitive form • Pay attention to RESTful APIs • Periodically check code for CSRF • QA tests? CSRF
32. • Is it possible to bypass steps? • Process validation • Where are decisions made? • What about Node.js’ asynchronous functions calls? • Especially when dealing with authorization decisions. Business Logic Flaws
33. Simple Trust Issues
34. • $109.95 is too much, right? Business Logic Flaws
35. Business Logic Flaws
37. • Mitigation • Don’t trust any user input… • Wait for asynchronous when making authorization decisions. • async library Business Logic Flaws
38. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 38 Defense
39. • Strategy - Integrate into the SDLC • Teach (seccasts.com) • Design • Test • Test • Test • Start over Defense
40. • Library Security • Security Middleware • Helmet.js • Kraken.js Defense
41. • 379 new modules/day NPM
42. Node Security Project
43. Malicious Packages
44. retire.js
45. RequireSafe
46. • Training tools • OWASP Node Goat - nodegoat.herokuapp.com • Damn Vulnerable Node Application (DVNA) - https:/ /github.com/quantumfoam/DVNA • goat.js - TBD Security Training
47. • Tools - Static Code Analysis • JSPrime • ScanJS • HP Fortify • IBM AppScan Source Defense
48. • JSPrime - Static Code Analysis Defense
49. • ScanJS - Static Code Analysis Defense
50. • ScanJS - Static Code Analysis Defense DEPRECATED
51. • Weaknesses • Geared towards single pages/files • Only effective at finding specific vulnerabilities • False Positives • Fortify/AppScan/Veracode Tools
52. • Implement Express/Helmet/Kraken • Check your source code repos for “secrets” • Test/check for IDOR. (Change 3 to a 4). • How is request.params being used in your application. • Run RequireSafe and require.js on your app • Google Node Goat and run through a couple tutorials. What can I do tomorrow?
53. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 53 Conclusion Security is hard, try harder
54. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com Questions? @sethlaw - Seth Law seth@nvisium.com 54