Home Wiki > SDB:Secure coding checklist: Ruby on Rails
Sign up | Login

SDB:Secure coding checklist: Ruby on Rails

tagline: From openSUSE

Attack Vector/Vulnerability
Solution
input/output validation
  • white-list filtering as early as possible
  • use safeERB, XSSshield, etc.
  • use .find(params[:id]) only with additional parameters or @user.order.find(id)
  • SQL injections
    • use bind variables and an array for SQL queries using .find
    • use sanitize_sql() or prepared statement for remote SQL queries
  • use protect_from_forgery (CSRF)
  • use escape methods for
    • Shell
    • LDAP
    • ...
  • Mass Assignment
    • use attr_accessible
    • don't pass user-data to .new or .create
  • take care with redirect_to
session handling
  • use SSL
  • use strong passwords only
    • 6 characters
    • numbers and letters
    • verify with cracklib-ruby
  • use password salt
  • use key derivation function for further processing (RFC 2898)
  • use a random+changing :secret for the Cookies
  • all controller actions are public
  • reset_session at login
  • limit admin interface to sub-net or localhost
  • ActionController::Base.session_options[:session_secure] = true
  • Cookie life-time has to be enforced on server-site
  • do NOT store secret information in a Cookie (only base64 encoded)
  • use CAPTCHAs to stop scripted attacks
  • bind IP address to Session-ID
  • re-authenticate before executing security- relevant actions
    • changing password
    • changing email address
    • changing repo URL
    • ...
very dangerous methods/functions
  • system()
  • popen()
  • `` (backticks)
  • eval()
  • deserialize()
information leak
  • short error message no full back-trace!
  • filter_parameter_logging
  • remove backup files periodically
  • use .find(params[:id]) only with additional parameters or @user.order.find(id)
  • use bind variables or alike for SQL queries using .find
file uploads and downloads
  • use hash of filename instead of real name
  • put them in a DB and use an ID
  • deny direct download of files
    • put them outside of DocumentRoot
  • deny suffixes like: rb, cgi, php, erb, html, ..
  • deny ../ and / in name
  • always set correct Content-Type
sensitive information
  • standards and acts: PCI DSS, HIPAA, SOX, ...
  • encrypt
  • keep them in memory as short as possible
  • create audit records for access
  • do not log the data itself to avoid leaking
cryptography
  • use OpenSSL
  • no hard-coded algorithms etc.
  • use only
    • AES with 256 bit key
    • SHA-2 with 512 bit
    • RSA, DSA, DH with 2048 bit key
    • CTR or CBC mode
  • fresh random numbers from /dev/random or /dev/urandom
  • avoid stream ciphers