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
   

   View Slide

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
   

   View Slide

3. @ysmithND
   about me
   CYBER OPERATIONS OFFICER, USAF
   

   View Slide

4. @ysmithND
   about me
   CYBER OPERATIONS OFFICER, USAF
   RECOVERING PRODUCT MANAGER
   

   View Slide

5. @ysmithND
   about me
   CYBER OPERATIONS OFFICER, USAF
   RECOVERING PRODUCT MANAGER
   LEAD INFOSEC ANALYST
   

   View Slide

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?”
   

   View Slide

7. @ysmithND
   the common refrain
   

   View Slide

8. @ysmithND
   we’re making this too hard
   (still)
   

   View Slide

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.
   

   View Slide

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
    

    View Slide

11. @ysmithND
    a n e x p e r i m e n t
    HOW CAN WE MAKE THIS EASIER
    

    View Slide

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
    

    View Slide

13. @ysmithND
    ___ ___ _ ___ _____ _ _ _
    / __| | _ \ /_\ |_ \ |_ _| /_\ | \ | |
    ___ \__ \ | _/ / _ \ | / | | / _ \ | .` |
    |___| |___/ |_ | /_/ \_ \ |_ |_\ |_| /_ / \_\ |_ | \_|
    I N T R O DUC I N G
    

    View Slide

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
    

    View Slide

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’)’
    

    View Slide

16. @ysmithND
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. @ysmithND
    d e m o n s t r a t i o n
    YOU CAN PLAY TOO!
    node npm git*
    terminal VSCode
    

    View Slide

21. @ysmithND
    npm init -y
    Optional : git init
    

    View Slide

22. @ysmithND
    npm install -g spartan-shield
    yarn add spartan-shield
    

    View Slide

23. @ysmithND
    $ _spartan -h
    @ysmithND
    

    View Slide

24. @ysmithND
    l e t ’ s p l a y a g a m e
    NEUTRALIZING DIGITAL SKIMMERS WITH _SPARTAN
    

    View Slide

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/
    

    View Slide

26. @ysmithND
    @ysmithND
    

    View Slide

27. @ysmithND
    @ysmithND
    

    View Slide

28. @ysmithND
    @ysmithND
    

    View Slide

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
    

    View Slide

30. @ysmithND
    q u i c k d e m o
    THIS IS FINE…EVERYTHING IS FINE
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

34. @ysmithND
    q u e s t i o n s
    

    View Slide

35. @ysmithND
    i t ’ s coming from inside
    the house
    AN INSIDE-OUT APPROACH TO NODEJS APPLICATION SECURITY
    

    View Slide

36. @ysmithND
    @ysmithND/@ysmithND darkmsph1t.github.io yolonda.io yolonda-smith
    f i g h t m e
    

    View Slide

37. @ysmithND
    B A C K U P
    

    View Slide

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
    

    View Slide

39. @ysmithND
    

    View Slide

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
    

    View Slide

41. @ysmithND
    concept of operations
    CACHE
    DATABASE
    SESSIONS
    SECURITY HEADERS
    FORMS
    CONNECTION
    SECRETS
    CLIENT
    ACCESS CONTROL
    CSP
    CACHE
    CORS
    APP DEPENDENCIES
    

    View Slide