security at greenhouse
TRANSCRIPT
RECRUITING OPTIMIZATION SUMMIT 2015
Security at GreenhouseMike O’Neil, Tech Lead
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?
• Javascript
• Rails
• Postgres
• Heroku + AWS
Our Stack
• 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 haveto be able to demonstrate it.
Security is important
• Invite others to “hack” on the product
• Undergo third party audits
• Instill a culture of security
How do we do that?
Invite others to “hack” on the product
• We chose HackerOne: https://hackerone.com/greenhouse
• 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
• 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?
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
http://yoursite.com/..%2F..%2F..%2Fbin/bash
This results in a special 404 response, indicating the file exists.
• Triage: prepare to be overwhelmed in the beginning
• Too many fake bug reports
Downsides to a Bug Bounty Program
• 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
Undergo third-party audit
• 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
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
Only one: $$$
Downsides
Instill a culture of security
• 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
A few things you can be doing to secure your Rails app…
Rack::Attack (https://github.com/kickstarter/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.post? && request.path == ‘/your/sign_in/path’
request.params['user']['email']
end
end
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.
• 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.new
user.api_key = ‘abc123’ # encrypted automatically
user.api_key # decrypted on the fly
• 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
