brunofacca / zen-rails-security-checklist Goto Github PK

I would like to add the following remarks:

• Use SecureRandom for generating tokens like reset password tokens. ruby Random is predictable.
• Create a new session after loging in (if you don't use a gem) to prevent session fixation attacks.
• Use rails secure_compare instead of == to compare security relavent strings to prevent timing attacks.
• Keep an eye on Time-of-Check-to-Time-of-Use-Problem (race conditions)
• Keep in mind that object serialisation can be dangerous (for instance https://community.rapid7.com/community/metasploit/blog/2013/01/09/serialization-mischief-in-ruby-land-cve-2013-0156).
• Use a Strong Session-Secret (https://martinfowler.com/articles/session-secret.html)
• Use a suiteable key stretching algorithmen for storing passwords instead of a simple Hash-Algorithm (https://pthree.org/2014/12/26/sha512crypt-versus-bcrypt/)

Thought it'd be good to notice these things in file upload handling. Paperclip is a great gem. However devs seems to ignore some details on content type spoofing and imagemagick vulnerabilities.

AFIK, content spoofing fails on higher level types. For eg, content type validation with 'video/mp4' will also allow a spoofed pdf file as a video. Content type matching works with media type which for both of has same value as 'application'.
Reported an issue here.. but no activities so far: thoughtbot/paperclip#2426

Also while setting up paperclip most devs won't dig into imagemagick policies or anything which could lead to severe vulnerabilities and dos attacks like https://hackerone.com/reports/390
It'd be nice to look into some imagemagick policies that suit your environment.
https://www.imagemagick.org/script/resources.php
http://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=26801
https://imagetragick.com/#info
thoughtbot/paperclip#1513

I think it would be good to add a section about how to remove potentialy dangerous middleware.

Like https://hackernoon.com/the-giving-ruby-the-strange-case-of-user-enumeration-on-heroku-not-fixed-1a8296067318 showed Rack::Runtime lowers the bars for a timming attack. With this middlewar enabled you get the runtime informations directly from the server and don't need to worry about network influences. In my point of view this makes timing attack more likely.

For production it would be good to consider dropping Rack::Runtime via Rails.configuration.middleware.delete Rack::Runtime

It's said that the Rails guys did bring it up many times over the years, but it's unlikly they will drop it.

Use generic error messages such as "Invalid email or password" instead of specifying which part (e-mail or password) is invalid. Devise does that by default. Mitigates user enumeration and brute-force attacks.

Hi, I think this section of the checklist might benefit from updating as from what I can tell Devise has further user enumeration mitigations that are disabled by default. For more see eliotsykes/rails-security-checklist#21 where I'm trying to update another checklist with a similar issue. HTH.

This article contains new security tips
https://brakemanpro.com/2017/09/08/cross-site-scripting-in-rails

The link https://github.com/brunofacca/zen-rails-security-checklist#sensitive-data-exposure is broken in your ToC

I recommend https://github.com/thlorenz/doctoc which does a good job to automate this tedious task. Especially when it's in git hook 😉

Thanks for sharing to the 🌍 ! 😸

How is Use HTTP verbs in a RESTful way a cross-site request forgery problem?

The second statement in there is correct:
Do not use GET requests to alter the state of resources