Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

    View full-size 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 full-size slide

  3. @ysmithND
    about me
    CYBER OPERATIONS OFFICER, USAF

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

  7. @ysmithND
    the common refrain

    View full-size slide

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

    View full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size slide

  16. @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 full-size slide

  17. @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 full-size slide

  18. @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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. @ysmithND
    $ _spartan -h
    @ysmithND

    View full-size slide

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

    View full-size slide

  24. @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 full-size slide

  25. @ysmithND
    @ysmithND

    View full-size slide

  26. @ysmithND
    @ysmithND

    View full-size slide

  27. @ysmithND
    @ysmithND

    View full-size slide

  28. @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 full-size slide

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

    View full-size slide

  30. @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 full-size slide

  31. @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 full-size slide

  32. @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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. @ysmithND
    B A C K U P

    View full-size slide

  37. @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 full-size slide

  38. @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 full-size slide

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

    View full-size slide