$30 off During Our Annual Pro Sale. View Details »

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

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.

ysmithND

June 01, 2019
Tweet

More Decks by ysmithND

Other Decks in Technology

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