Secure Coding with Node.js

This departure from the client to the server introduces a number of security issues and problems that the language does not handle by default.

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 • 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. January 20, 2015
11. • Reporting a Bug • Information Disclosure nodejs.org docs
12. • 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
13. Houston, we have a problem
15. • 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
16. • 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
18. • Vulnerabilities • Insecure Direct Object Reference • Mass Assignment • Cross Site Request Forgery (CSRF) • Business Logic Flaws • Defenses • Tools Agenda
19. • 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
20. • Why? • Disclaimer Vulnerabilities
22. • waiting_room.jsp?group_id=7 • … • waiting_room.jsp?group_id=1 • … • 45 minutes advantage IDOR
23. IDOR
24. • IDOR • 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
25. • Changing an identifier value. IDOR
26. • 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
27. • AKA Data-Binding Attacks • Active-record pattern abuse • Add parameters to request to modify data Mass Assignment
28. Mass Assignment
31. • Mitigation • Don’t trust user input • Only save/store expected parameters Mass Assignment
32. • AKA Session Riding, XSRF • A web application will process all requests that include authorization cookies, no questions asked. CSRF
33. Problem?
34. • Is not enabled by default app.use(express.csrf()); • Needs a little help app.use(function (req, res, next) { res.locals.csrftoken = req.session._csrf; next(); }); CSRF
35. • 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
36. • 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
37. CSRF
38. Not so secret
39. CSRF
40. • Mitigation • Secret must be secret • Any sensitive form • Pay attention to RESTful APIs • Periodically check code for CSRF • QA tests? CSRF
41. • 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
42. Vulnerabilities
43. • $109.95 is too much, right? Vulnerabilities
44. Vulnerabilities
46. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 46 Demo Control Flow (goat.js)
47. • Mitigation • Wait for asynchronous when making authorization decisions. • async library Business Logic Flaws
48. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 48 Defense
49. • Strategy - Integrate into the SDLC • Teach (seccasts.com) • Design • Test • Test • Test • Start over Defense
50. • Library Security • Security Middleware • Helmet.js • Kraken.js Defense
51. • 379 new modules/day NPM
52. Node Security Project
53. Malicious Packages
54. retire.js
55. RequireSafe
56. • crossdomain.xml • CSP (Content Security Policy) • X-Powered-By • HPKP • HSTS • ieNoOpen • noCache • noSniff • frame guard • xssFilter Helmet.js
57. • 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 Kraken.js - Lusca
58. • Tools - Static Code Analysis • JSPrime • ScanJS • HP Fortify • IBM AppScan Source Defense
59. • JSPrime - Static Code Analysis Defense
60. • ScanJS - Static Code Analysis Defense
61. • ScanJS - Static Code Analysis Defense DEPRECATED
62. • Weaknesses • Geared towards single pages/files • Only effective at finding specific vulnerabilities • False Positives • Fortify/AppScan/Veracode Tools
63. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com 63 Conclusion Security is hard, try harder
64. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com Questions? 64
65. Copyright © 2015 nVisium LLC · 590 Herndon Parkway Suite 120, Herndon VA 20170 · 571.353.7551 · www.nvisium.com Thank you @sethlaw - Seth Law seth@nvisium.com 65