It's Coming From Inside the House: An Inside-Out Approach to Node.js Application Security (OpenSourceNorth)

Getting application security right often requires that developers have a deeper than average understanding of the security domain. In what other industry is this the case? We don't have to be M.D.s to get a medical diagnosis; we don't have to be auto mechanics to get our cars fixed, yet we in security wag our fingers at "iD10t errors" and build grand mousetraps to catch "so obvious" developer missteps, when they may not know what they need to add, change or remove from their applications to make it "secure" in the first place. Furthermore, patterns to address these issues don't always fit the requirements of the application short or long term, resulting in solutions that only address part of the problem, or worse, are omitted altogether because they are too cumbersome to implement.

My answer to this is _spartan–a node application created for developers of node.js applications, not security people. _spartan allows developers to create security policies which address their node app's (whether it be Desktop, Web, Mobile, IoT or API) specific requirements; it installs & configures the modules to match the policy and; it generates the boilerplate code that developers can import directly into their applications.

Transcript

1. @ysmithND i t ’ s coming from inside the house AN INSIDE-OUT APPROACH TO NODEJS APPLICATION SECURITY yolonda smith
2. @ysmithND HOUSEKEEPING WHAT WE’LL COVER TODAY ▸ about me ▸ the common refrain ▸ we’re making this too hard (still) ▸ hot takes ▸ an experiment : can we make ‘security’ easier? ▸ the result : _spartan ▸ let’s solve a problem with _spartan : digital skimmers ▸ summary & recommendations
3. @ysmithND about me CYBER OPERATIONS OFFICER, USAF
4. @ysmithND about me CYBER OPERATIONS OFFICER, USAF RECOVERING PRODUCT MANAGER
5. @ysmithND about me CYBER OPERATIONS OFFICER, USAF RECOVERING PRODUCT MANAGER LEAD INFOSEC ANALYST
6. @ysmithND the common refrain “That’s handled somewhere else [downstream/ upstream/some other made up place]” “Is this really that big of a problem? What’s the likelihood that anyone will ever find this?” “Where does it say we have to do that?”
7. @ysmithND the common refrain
8. @ysmithND we’re making this too hard (still)
9. @ysmithND WE’RE MAKING THIS TOO HARD THE (PERCEIVED) PROBLEM • Bread-crumb security • Have to be a domain expert to know what questions to ask OR • Asking a security question turns into a brain dump/lecture • Lots of guidance, not a lot of practical application • Security solutions become awkward bolt-ons OR require concessions in application performance & features to make it work.
10. @ysmithND WE’RE MAKING THIS TOO HARD hot takes ▸ Shouldn’t need domain expertise needed to get basics done ▸ Security things for other security people ▸ Security metrics should dovetail to match those of the business ▸ Security with the application not around the application
11. @ysmithND a n e x p e r i m e n t HOW CAN WE MAKE THIS EASIER
12. @ysmithND AN EXPERIMENT can we make product security easier? “Easier” => • Provides a means to offer intuitive, basic end-to-end security coverage… • …natively in the most popular development language… • …which works as part of the application, not around it… • …tailored to the application’s requirements AND • flexible enough to adjust when the application changes
13. @ysmithND ___ ___ _ ___ _____ _ _ _ / __| | _ \ /_\ |_ \ |_ _| /_\ | \ | | ___ \__ \ | _/ / _ \ | / | | / _ \ | .` | |___| |___/ |_ | /_/ \_ \ |_ |_\ |_| /_ / \_\ |_ | \_| I N T R O DUC I N G
14. @ysmithND THE RESULT : SPARTAN what is it? ▸ Node.js application designed as a security library for other node.js applications of various types ▸ Writes human-readable security spec & pre- configured modules for immediate integration in new and existing node apps ▸ mocha-chai => unit testing ▸ Coveralls => test coverage ▸ TravisCI-ready Spartan sec urity
15. @ysmithND ABOUT SPARTAN how it works • Application Types • Web, Desktop, Mobile, IoT, Kiosk, API • Users (developers) configure security policy by answering a few questions. In return they get • security.json => ‘the security spec’ or ‘policy’ of the application • security.js => the collection of submodules that are generated and preconfigured from the interpreted policy • security/ => customized modules that security.js points to. • Developer simply has to ‘include’ the module in their code like this: ‘let security = require(‘./security’)’
16. @ysmithND
17. @ysmithND WHY THO? why spartan? ▸ Allows engineers and product owners to make deliberate, traceable security risk decisions ▸ Decrease cost of application O&M* && increase velocity of development ▸ Simplifies & standardizes secure application design ▸ No hunting-and-pecking for packages/middleware ▸ Serves as security design spec for new/incoming developers * O&M = Operation & Maintenance
18. @ysmithND NO, BUT FOR REAL Y THO? What happens after the zombies breach the front door? Application is the brains* spartan makes the brains taste like garbage *Zombies like brains Client CDN/PoP WAF/Firewall Load Balancer/Proxy Container/Cluster Application Dependencies Supply Chain Source Code
19. @ysmithND d e m o n s t r a t i o n YOU CAN PLAY TOO! node npm git* Your fave text editor/IDE terminal
20. @ysmithND d e m o n s t r a t i o n YOU CAN PLAY TOO! node npm git* terminal VSCode
21. @ysmithND npm init -y Optional : git init
22. @ysmithND npm install -g spartan-shield yarn add spartan-shield
23. @ysmithND $ _spartan -h @ysmithND
24. @ysmithND l e t ’ s p l a y a g a m e NEUTRALIZING DIGITAL SKIMMERS WITH _SPARTAN
25. @ysmithND RECAP digital skimmers? • Like ATM-skimmers, except with code • Exploit 3rd party vendor’s javascript code • Malicious code goes everywhere the vendor’s code appears 5 Additional Resources: RiskIQ => https://www.riskiq.com/blog/external-threat-management/inside-magecart/ ZDNet => https://www.zdnet.com/article/how-magecart-groups-are-stealing-your- card-details-from-online-stores/
26. @ysmithND @ysmithND
27. @ysmithND @ysmithND
28. @ysmithND @ysmithND
29. @ysmithND NEUTRALIZING DIGITAL SKIMMERS WHAT ARE THE OPTIONS? 1. JSONP…please, God, no… 2. Regenerate js for every page load ▸ Shorten cache period 3. Minimize the amount of 3P javascript running on sensitive pages 4. Limit the context where 3P javascript can run (e.g. sandbox) and what permissions it has (CORS) 5. Track changes in javascript that we do allow ▸ Make sure we know when failures occur
30. @ysmithND q u i c k d e m o THIS IS FINE…EVERYTHING IS FINE
31. @ysmithND UNSOLICITED ADVICE summary (for developers) 1. DO know what you have, understand its value and watch it a. This includes infrastructure 2. DO make security decisions deliberately 3. DON’T rely on the pen-test to catch all of the security issues 4. DO devote at least one sprint/epic on secure design & code review 5. DO make sure that you have a means of detecting attempts to circumvent your controls
32. @ysmithND UNSOLICITED ADVICE summary (for security types) 1. We can make security more accessible to developers by putting ourselves in developers’ shoes 2. _spartan is how I thought about it—what steps will you take? 3. DO sit in on the design sprints => you don’t have to know how to code to write a story/ requirement 4. DO make it a point to learn the key business success metrics…identify how security initiatives can support/contribute
33. @ysmithND • All things skimmer: • https://otx.alienvault.com/pulse/5ba3c739f1b1ed67ed7764c1 • https://gwillem.gitlab.io/tag/skimming/ • https://gwillem.gitlab.io/2018/09/18/abs-cbn.com-hacked/ • MOAR spartan • https://docs.spartan-security.io resources & references
34. @ysmithND q u e s t i o n s
35. @ysmithND i t ’ s coming from inside the house AN INSIDE-OUT APPROACH TO NODEJS APPLICATION SECURITY
36. @ysmithND @ysmithND/@ysmithND darkmsph1t.github.io yolonda.io yolonda-smith f i g h t m e
37. @ysmithND B A C K U P
38. @ysmithND WHY NODE A NOD TO NODE ▸ About ▸ Mesh of Chrome V8 Javascript Engine, Event loop + low-level I/O API ▸ “Javascript outside the browser”/“Javascript Everywhere” ▸ Key Benefits ▸ Event driven architecture ▸ Fast, asynchronous I/O processing (non-blocking) ▸ Highly extensible thanks to community-driven package manager, npm ▸ Adoption ▸ Netflix, Walmart, Uber, Paypal, LinkedIn, Medium, NASA, IBM ▸ Optimized for web apps, though growing use in non-web applications
39. @ysmithND
40. @ysmithND DESIGN VISION Inquirer Update Init {security.json} (policy) security.js (boilerplate) Interpreter {Answers} Transformer Force Delete No-overwrite Default {Confirmation} modules modules modules modules {security-default.json} (default policy) Set-As-Default
41. @ysmithND concept of operations CACHE DATABASE SESSIONS SECURITY HEADERS FORMS CONNECTION SECRETS CLIENT ACCESS CONTROL CSP CACHE CORS APP DEPENDENCIES