Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security at Greenhouse


Published on

Our approach to security at Greenhouse, and a few things you do in your Rails app.

Published in: Technology
  • Be the first to comment

Security at Greenhouse

  1. 1. RECRUITING OPTIMIZATION SUMMIT 2015 Security at Greenhouse Mike O’Neil, Tech Lead
  2. 2. Software that optimizes your company’s entire recruiting process: • Sourcing – spend your money & time effectively • Interviewing – perform structured, purposeful interviews • Decision making – support your hiring decision with data; see what worked, what didn’t, and refine your process What is Greenhouse?
  3. 3. • Javascript • Rails • Postgres • Heroku + AWS Our Stack
  4. 4. • We store sensitive data (PII, salary negotiations, etc.) • Customers need to trust us with that data • “We’re secure” isn’t quite good enough. We have to be able to demonstrate it. Security is important
  5. 5. • Invite others to “hack” on the product • Undergo third party audits • Instill a culture of security How do we do that?
  6. 6. Invite others to “hack” on the product
  7. 7. • We chose HackerOne: • Security researchers from all over try to find exploits • Pay out a small bounty for verifiable exploits • Hundreds of man-hours for very little payout Start a Bug Bounty Program
  8. 8. • Cross-site issues (XSS / CSRF) • Clickjacking (embed your site in an iframe elsewhere) • Reflected File Download (JSONP vulnerability) • Best practices: missing security headers, DNS configuration not optimal, etc. • 2 CVEs found: Solr, and Rails itself What bug reports did we see?
  9. 9. The attacker was able to determine if a file exists outside of the Rails root (but not retrieve the file). How? Simply visit: “Arbitrary File Disclosure” found in Rails core This results in a special 404 response, indicating the file exists.
  10. 10. • Triage: prepare to be overwhelmed in the beginning • Too many fake bug reports Downsides to a Bug Bounty Program
  11. 11. • Find security holes • Low cost, low barrier to entry • Gain exposure to a wide array of attack vectors • Show people you care about security Upsides to a Bug Bounty Program
  12. 12. Undergo third-party audit
  13. 13. • We’re not security experts ourselves • Customers need assurance that our product is secure • Some companies won’t sign on to Greenhouse without it Call in the experts
  14. 14. They come on-site and have complete access to our code and test environment. • Penetration testing (blackbox and whitebox) • Code review • Design review iSEC Partners
  15. 15. Only one: $$$ Downsides
  16. 16. Instill a culture of security
  17. 17. • Use 1Password to store all your account passwords • Don’t send API keys, etc. to each other over email in plaintext: everyone needs a PGP key • Enable 2FA on Github / Heroku / AWS • Background checks for anyone with access to production • Tech leads review all code Processes we follow
  18. 18. A few things you can be doing to secure your Rails app…
  19. 19. Rack::Attack ( config/initializers/rack_attack.rb: Throttle your login page config = { :limit => 5, :period => 1.minute } Rack::Attack.throttle('login', config) do |request| if && request.path == ‘/your/sign_in/path’ request.params['user']['email'] end end
  20. 20. If you use CanCan, put this in your base controller: Ensure all controllers do authorization check_authorization Now if you don’t call authorize! in a controller action, an AuthorizationNotPerformed error is raised. Tip: Start with a “reporting” mode before flipping it live. Catch this error and log it, then fix the offending controller actions.
  21. 21. • SymmetricEncryption gem (github: reidmorrison) • We created an ActiveRecord keyword to indicate which columns should be encrypted/decrypted. Encrypt sensitive data in your database class User < ActiveRecord::Base encrypt_columns :api_key end user = user.api_key = ‘abc123’ # encrypted automatically user.api_key # decrypted on the fly
  22. 22. • DOS attack: open a lot of connections, send partial requests, but never complete them. • Rails servers are susceptible to this attack, e.g. unicorn • Solution: Put nginx in front of Rails, bump up worker_connections quite a bit. • On Heroku? Use a buildpack to run nginx. Mitigate slowloris attack
  23. 23. Mike O’Neil