Go through this security checklist, create tasks for anything missing, determine urgency/launch blocking

[johnhutch]

https://simplesecurity.sensedeep.com/web-developer-security-checklist-f2e4f43c9c56

[jon-athan-hall]

I made tickets for every item that we're done doing (or at least what I'm pretty sure we're not doing). I then labeled them, and either put the ticket in Sprint 1.0, 1.1 Improvements, or 1.2 Improvements. Any tickets added to Sprint 1.0 were also given an estimate.

Below are the things we are already doing:

• Every new Rails project creates config/secrets.yml but we also Figaro's config/application.yml for managing environment variables which is in our .gitignore list.

• As of Rails 3.1, as long as you we a traditional SQL database, we're automatically using SQL prepared statements.

• Naturally, we are scanning for vulnerabilities (as best as we can) during our Code Review step.

• Passwords are encrypted with Devise.

• We are using proven components for login, forgot password, etc. since we're using a Devise gem (and didn't build our own instead).

• Heroku does automatically provide DDoS Mitigation, and also advertises a quick response to any attacks with more advanced mitigation controls when needed.

• It would appear that Heroku is using TLS/SSL across the site because I see "https" everywhere.

• Ruby on Rails sets the cookies to httpOnly automatically here: config/initializers/session_store.rb

• Ruby on Rails sets the following headers by default: X-Frame-Options 'SAMEORIGIN' and X-XSS-Protection 1; mode=block and X-Content-Type-Options nosniff

• No enumerable resources in our API. We don't have an API right now.

• Fully authenticated/authorized users using our API. We don't have an API right now.

• Canary checks in API. We don't have an API right now.

• White list validation of user input will be take care of in issues Implement model validations for all user-input data #121 and Implement frontend form validation #125.

• We will be able to to do upgrades without downtime by developing on our own machines, as well as on our pre-prod server (when that gets built).

• Heroku has logs set up and available automatically.

• We don't SSH into our Heroku service. We have their command line tools that automate everything. If we ever have to SSH into Heroku, it's because we didn't automate a task!

• Intrusion detection is on Heroku. Sounds like it includes looking out for physical beings breaking into their server rooms even!

• Heroku has that "dyno" set up for sleeping when not being used. "The most secure server is one that is powered down." That's pretty funny.

• We are writing tests. Keep it up (I'm looking at you @jon-athan-hall).

[jon-athan-hall]

Eh, I should wait to close this so it doesn't disappear before the team reviews it.

Remember anything not listed had a ticket created for it. They go from #114 to #131.

[johnhutch]

Notes:

1. Whoah, I had no idea we were already supporting https.
2. We DO have an API. Any controller action that has format.json in the respond_to block is technically part of our API. So with that in mind, what are enumerable resources and canary checks in regards to API?
3. I don't think we CAN SSH into heroku. At all.
4. I switched us to the pay service, so our dynos don't sleep anymore. Waking a dyno can take several seconds and that's no good (plus I hear triceratops is SUPER grump in the morning badump psht #dadjoked)
5. This is all goddam awesome. A++++++ would do business again. Kudos, thanks, and backpats.

[johnhutch]

Looks good!