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

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 c o m i n g f r o m
   i n s i d e t h e h o u s e
   AN INSIDE-OUT APPROACH TO NODEJS APPLICATION SECURITY
   yolonda smith
   

   View Slide

2. @ysmithND
   STAGE 1
   

   View Slide

3. @ysmithND
   CYBER OPERATIONS OFFICER, USAF
   get to know your captain
   

   View Slide

4. @ysmithND
   RECOVERING PRODUCT MANAGER
   get to know your captain
   

   View Slide

5. @ysmithND
   LEAD INFOSEC ANALYST
   get to know your captain
   

   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
    S T A G E 2
    

    View Slide

12. @ysmithND
    AN EXPERIMENT
    WHAT’S “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 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
    WHY THO?
    why spartan?
    

    View Slide

17. @ysmithND
    NO, BUT FOR REAL
    Y THO?
    What happens after the aliens
    get past the first line of
    defense?
    Application is the inner core at
    the center of the earth*
    spartan is the middle finger
    you give the aliens
    Client
    CDN/PoP
    WAF/Firewall
    Load Balancer/Proxy
    Container/Cluster
    Application
    Dependencies Supply Chain Source Code
    

    View Slide

18. @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

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

    View Slide

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

    View Slide

21. @ysmithND
    > _spartan -h
    @ysmithND
    

    View Slide

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

    View Slide

23. @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

24. @ysmithND
    @ysmithND
    

    View Slide

25. @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

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

    View Slide

27. @ysmithND
    UNSOLICITED ADVICE
    summary (for developers)
    1. DO know what you have, understand its
    value and watch it
    a. This includes infrastructure
    2. DON’T rely on the pen-test to catch all of the
    security issues
    3. DO devote at least one sprint/epic on secure
    design & code review
    4. DO make sure that you have a means of
    detecting attempts to circumvent your
    controls
    

    View Slide

28. @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

29. @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/
    • Prevention vs Cure
    • https://www.isixsigma.com/industries/software-it/defect-prevention-reducing-
    costs-and-enhancing-quality/
    • MOAR spartan
    • https://docs.spartan-security.io
    resources & references
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. @ysmithND
    B A C K U P
    

    View Slide

34. @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

35. @ysmithND
    

    View Slide

36. @ysmithND
    

    View Slide

37. @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

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

    View Slide