Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

It's Coming From Inside the House: An Inside-Ou...

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.

ysmithND

May 22, 2019
Tweet

More Decks by ysmithND

Other Decks in Technology

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 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?”
  4. @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.
  5. @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
  6. @ysmithND a n e x p e r i m

    e n t HOW CAN WE MAKE THIS EASIER
  7. @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
  8. @ysmithND ___ ___ _ ___ _____ _ _ _ /

    __| | _ \ /_\ |_ \ |_ _| /_\ | \ | | ___ \__ \ | _/ / _ \ | / | | / _ \ | .` | |___| |___/ |_ | /_/ \_ \ |_ |_\ |_| /_ / \_\ |_ | \_| I N T R O DUC I N G
  9. @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
  10. @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’)’
  11. @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
  12. @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
  13. @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
  14. @ysmithND d e m o n s t r a

    t i o n YOU CAN PLAY TOO! node npm git* terminal VSCode
  15. @ysmithND l e t ’ s p l a y

    a g a m e NEUTRALIZING DIGITAL SKIMMERS WITH _SPARTAN
  16. @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/
  17. @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
  18. @ysmithND q u i c k d e m o

    THIS IS FINE…EVERYTHING IS FINE
  19. @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
  20. @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
  21. @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
  22. @ysmithND i t ’ s coming from inside the house

    AN INSIDE-OUT APPROACH TO NODEJS APPLICATION SECURITY
  23. @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
  24. @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
  25. @ysmithND concept of operations CACHE DATABASE SESSIONS SECURITY HEADERS FORMS

    CONNECTION SECRETS CLIENT ACCESS CONTROL CSP CACHE CORS APP DEPENDENCIES