Securing your nodejs deployments while you sleep

6932fd8236cec12354ba8230c0e80d81?s=47 Ahamed Nafeez
September 19, 2014

Securing your nodejs deployments while you sleep

JSFoo 2014, Bangalore.

Developers push code at a much faster rate, that your security engineers don’t have enough time to take a look at them. Most of the vulnerabilites like XSS & CSRF comes in to existence when developers try to bring the next uber feature live, by not giving much attention to security or one of them is simply not aware of writing secure code. It has been a problem which is worrying most of the startups and organizations recently. In spite of having a secure framework which inherently takes care of most common security issues, it becomes a nightmare for security engineers / testers to take a look at every code commit for a vulnerability in their code. This talk is about automating the process of finding insecure code pushes for Nodejs deployments.

6932fd8236cec12354ba8230c0e80d81?s=128

Ahamed Nafeez

September 19, 2014
Tweet

Transcript

  1. Securing your nodejs deployments while you sleep Ahamed Nafeez !

  2. None
  3. Continuous Delivery

  4. A vulnerability gets out to the internet before the security

    team looks at it or a scanner is run. Code deployment is now near instantaneous
  5. Constant iteration in production via feature flags, A/B testings etc

  6. Attack vs Defence

  7. A-B usability tests Error-Catchers Benchmarking These don’t write themselves

  8. What about the security of your data and nodejs app?

  9. People start with a simple access control policy- Everyone has

    access to everything.
  10. Or maybe you never gave a thought about your front-

    end architecture to prevent against, Cross-Domain attacks
  11. Security should be a first class requirement.

  12. Watch the code as soon as it gets deployed. !

    Do Continuous Integration with security checks relevant to the Diffs / Delta
  13. What if you could monitor code commits for insecure patterns

    / behaviours?
  14. Lets try doing that to a repository on GitHub

  15. 1. Use GitHub’s WebHooks.
 2. Get all commits to your

    repository.
 3. Get the DIFF and send it across various security tests. In 3 simple steps
  16. What can you test?

  17. ! 1. Insecure usage of templates for Cross-Site Scripting (XSS)

    2. Insecure libraries 3. . . . ! ! Simple static analysis !
  18. ! 1. New routes being added!! 2. State changing routes

    being added ! Dynamic analysis !
  19. git-watchdog 
 Collects post-receive from GitHub and alerts you on

    security errors

  20. Cross-Site Scripting (XSS)

  21. Imagine an injection context inside a JS variable <html> <script>

    var a = “—-user-input-here—”; alert(‘Finished’); </script> </html>
  22. Just strip out / escape the “ character (Double Quotes)

  23. Guess what happens ? <html> <script> var a = “</script><svg/onload=alert(2)>”;

    alert(‘Finished’); </script> </html>
  24. HTML Parser have preference over JS Parser.

  25. Principle of Un-obtrusive Javascript Client-Side Templating Content Security Policy Reduce

    the entry point to one What defensive front-end architecture looks like
  26. Templating & XSS <%= %>, {{ }} — HTML Encoded

    - Usually XSS Safe <%- %>, {{{ }}} — No Encoding - Causes XSS in any context. Your design should naturally avoid this.
  27. This works until someone who doesn’t understands your code starts

    committing to production.
  28. Things to look out Anything which has <%- or {{{

    needs some attention. Write a simple module which checks the code commits for that.
  29. Writing an XSS checker in git-watchdog

  30. ExpressJS! Web Application framework for node

  31. Scan on new routes being added? In Express, app._router.stack gives

    you all the registered routes. Pretty useful if you want to trigger a scan for a newly added end-point.! Figure out what works for your framework!
  32. Lets discuss more @skeptic_fx