Basic security audit

[lippytak]

At some point...at least:

• [x] Setup SSL setup
• [x] Get one dev to sanity check the code/config setup
• [ ] Automatically delete all temp information (generated images) after request, or if request fails
• [ ] Make our heroku passwords unique and strong
• [ ] switch Heroku accounts
• [ ] Set short lock time and strong passwords on any laptops with local .ENV files
• [x] Make sure we're using Phaxio https (https://api.phaxio.com)
• [ ] policy around application/document storage
• [ ] get third party to review code

[daguar]

Is this v2? (I can do it, just wanna know.)

[lippytak]

Nope. Not IMO atleast. I think we should do this before strangers apply without our in person support, whenever that may be.

On Saturday, May 10, 2014, Dave Guarino notifications@github.com wrote:

Is this v2? (I can do it, just wanna know.)

— Reply to this email directly or view it on GitHubhttps://github.com/daguar/calfresh-and-so-clean/issues/35#issuecomment-42763195 .

Sent from thumbs

[daguar]

TIL:

All default appname.herokuapp.com domains are SSL-enabled already and can be accessed simply by using https, e.g., https://appname.herokuapp.com. https://devcenter.heroku.com/articles/ssl-endpoint

so I just pushed a change implementing forced HTTPS redirects when in any environment besides local development. This will need to be revisited should we use a custom (i.e., non-herokuapp.com) domain.

(I've also made your bullet to-do's checklist boxes, and checked the first one off.)

[lippytak]

TIL:

• [x] Markdown checkboxes.

[alanjosephwilliams]

Let me know if other team members need to sign an NDA as well.

[daguar]

@migurski made the suggestion of considering EC2 with an encrypted /tmp folder holding the generated images, since Heroku's shared hosting which opens more theoretical attack vectors.

[lippytak]

Adding a couple more (not dev...)

• Use HelloFax teams instead of sharing an account so we don't have to share passwords
• Same for Phaxio if possible

[daguar]

I walked through the code with @migurski yesterday. Here are the key things that came out of it (overall seems like we're good, just need some minor tinkering to make it even more secure):

• Best to dispose of image as quickly as possible (as soon as fax is through, get rid of it)
  • Ideally everything lives only as long as the request
  • Can use Tempfile (instead of SecureRandom), avoids race conditions etc http://www.ruby-doc.org/stdlib-1.9.3/libdoc/tempfile/rdoc/Tempfile.html
• Consider using a temp dir with standard filenames
  • If anything goes wrong in process, blow away the entire dir, so that it doesn't keep any of this info
• Can 303 to the image after submission
  • The POST could send the image to the user as URI data (respond back rendering the thing, and delete the local copy)
• If fax is secure, stay with that for now (email potentially less so) especially since it's what they publicly publish

[daguar]

Checking off the "use Phaxio's HTTPS endpoint" because the Ruby API wrapper we use does that, per https://github.com/gristmill/phaxio/blob/master/lib/phaxio/client.rb#L3

[daguar]

Checking off "Get one dev to sanity check the code/config setup" because @migurski is a dev I think.

[daguar]

I've added 2 new items to the list above:

• Automatically delete all temp information (generated images) after request, or if request fails
• For broader (uncontrolled use) production, configure Phaxio setting to never store any images

[migurski]

So good. Regarding the 303 + data URI, the response should include finely-tuned cache-control response headers. Do you plan to serve over SSL?

[daguar]

Do you plan to serve over SSL?

Most definitely (and we are currently) because we're dealing with some sensitive inputs.

So good.

Feel free to expand on what you like about the code/project, Mike. :smile_cat:

[migurski]

Most definitely (and we are currently) because we're dealing with some sensitive inputs.

Great, that solves a lot right there.