Show Menu
Cheatography

Rails 5 Security Cheat Sheet (DRAFT) by

This is a draft cheat sheet. It is a work in progress and is not finished yet.

SQL Injection

Defi­nit­ion:
SQL injection is the placement of malicious code in SQL statem­ents, via web page input.
Exam­ple:
Malicious user inputs SQL code as vaue for text input
Threat Level (Mediu­m-H­igh):
Active­Record, in most cases, protects against SQL Injection by default, however, there are ways in which it can be used insecurely which can lead to SQL Injection.
Rails Fix:
Avoid using find_by_sql
Do not pass params directly into queries use '?' vars
Explicitly force IDs to_i for queries
Use "­Strong Parame­ter­s" in Controller
Pote­ntially Dangerous Methods:
Calcul­ations (average, sum, maximum...){{nl}exists?(id)
delete_all / destroy_all
find_by(id)
https:­//r­ail­s-s­qli.org/
This is one of the most common web hacking techniques.
Malicious SQL could destroy your database.

Cross-Site Scripting (XSS)

Defi­nit­ion:
XSS is a code injection attack that allows an attacker to execute malicious JavaScript in another user's browser The only way for the attacker to run his malicious JavaScript in the victim's browser is to inject it into one of the pages that the victim downloads from the website.
Pers­istent XSS
Malicious JS has been saved to DB by attacker. Is executed when victim loads page
Refl­ected XSS
In a reflected XSS attack, the malicious string is part of the victim's request to the website. The website then includes this malicious string in the response sent back to the user. Think Phishing.
Threat Level (High for Persistent XSS)
Data must be sanitized before being saved to DB
Rails Fix:
Data must be sanitized before being saved to DB
 

Session Hijacking

Defi­nit­ion:
Stealing a user's session ID lets an attacker use the web applic­ation in the victim's name.
Exam­ple:
Man in the middle sniffs out valid session id
Threat Level (Mediu­m-L­ow):
Man in the middle attack
Rails Fix:
Expire Sessions
Use https to thwart man-in­-th­e-m­iddle attacks
Call reset_­session when logging users in and out to avoid session fixation.
Sanitize user input to avoid XSS.
Use Devise (it will automa­tically expire sessions on sign in and sign out)
Rails Fix (Enabled by default)
Encryp­ted­Coo­kie­Store: Session is encrypted before being stored in cookie (confi­g/s­ecr­ets.yml)
Session Fixati­on:
Using a fixed/­per­mament session id. Call reset_­session after login/­logout to prevent this.

Cross-Site Request Forgery (CSRF) (Built In)

Defi­nit­ion:
An attack that forces an end user to execute unwanted actions on a web applic­ation in which they're currently authen­tic­ated.
Exam­ple:
Phishing example. User clicks on link to page that looks like legit site. Victim is tricked into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf.
Threat Level (LOW):
Modern browsers enforce same-o­rigin policy restri­ctions on scripts.
Rails Fix (Enabled by default)
Rails protects against CSRF attacks by default by including a token named authen­tic­ity­_token within HTML responses
That token is also stored in user session and they are compared when Request is made.
To confirm it's enabled verify protec­t_f­rom­_fo­rgery is in Applic­ati­onC­ont­roller
Deve­loper Fix:
Use GET and POST properly (CSRF is on POST only)

Develop Respon­sibly

Filter params saved in logs
config.fi­lte­r_p­ara­meters << :password, :credi­t_card
Do not Redirect based on a URL in the Request
Think through file uploads
Check extens­ions. Beware execut­eable files
Restrict File Downlo­ads
Make sure users cannot download arbitrary files.
send_file('/var/www/uploads/' + params­[:f­ile­name])
Brute Force login attacks
Think about using a CAPTCHA