Security best practices in Ruby on Rails - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is Cross-Site Request Forgery (CSRF) and how does Rails protect against it?

CSRF is an attack where unauthorized commands are sent from a user that the web application trusts. Rails protects against CSRF by including an authenticity token in forms and verifying it on the server side to ensure requests are genuine.

beginner

Why should you use parameter filtering in Rails logs?

Parameter filtering hides sensitive data like passwords or credit card numbers from appearing in logs. This prevents accidental exposure of private information if logs are accessed by unauthorized users.

beginner

What is SQL Injection and how does Rails prevent it?

SQL Injection is when attackers insert malicious SQL code through user input to manipulate the database. Rails prevents this by using parameterized queries and Active Record methods that safely escape inputs.

beginner

How does Rails help prevent Cross-Site Scripting (XSS) attacks?

Rails automatically escapes HTML in views to prevent malicious scripts from running. This means user input is treated as plain text, not executable code, protecting users from XSS attacks.

beginner

What is the purpose of using HTTPS in Rails applications?

HTTPS encrypts data sent between the user and the server, protecting sensitive information from being intercepted. Rails encourages HTTPS by providing easy ways to enforce secure connections.

Which Rails feature helps protect against CSRF attacks?

A Automatic SQL escaping

B Encrypted cookies

C Authenticity token in forms

D Session timeout

Rails includes an authenticity token in forms to verify requests come from trusted sources, preventing CSRF.

How does Rails prevent SQL Injection?

A Enforcing HTTPS

B By escaping HTML in views

C Filtering parameters in logs

D Using parameterized queries with Active Record

Rails uses parameterized queries and Active Record methods to safely handle user input and prevent SQL Injection.

What does Rails do to protect against Cross-Site Scripting (XSS)?

A Escapes HTML in views automatically

B Filters sensitive parameters in logs

C Encrypts database fields

D Uses authenticity tokens

Rails escapes HTML in views by default to prevent malicious scripts from running, protecting against XSS.

Why is it important to filter sensitive parameters in Rails logs?

A To prevent sensitive data exposure

B To enable HTTPS

C To reduce database size

D To speed up logging

Filtering sensitive parameters prevents private data like passwords from appearing in logs, protecting user privacy.

What is the main benefit of using HTTPS in a Rails app?

A Faster page loads

B Encrypted data transfer

C Automatic CSRF protection

D Simpler code

HTTPS encrypts data between the user and server, protecting sensitive information from interception.

Explain how Rails protects against common web attacks like CSRF, SQL Injection, and XSS.

Think about how Rails handles user input and form submissions.

Describe why filtering sensitive parameters in logs and using HTTPS are important security practices in Rails.

Consider what could happen if logs or data transmissions are not secured.

Practice

1. Which Rails feature helps prevent unwanted or dangerous user input from being saved to the database?

easy

A. Strong Parameters

B. Active Record Callbacks

C. Action Mailer

D. Asset Pipeline

Solution

1. Step 1: Understand user input control

   Strong Parameters allow you to specify which attributes are allowed from user input, preventing mass assignment vulnerabilities.

2. Step 2: Identify the correct Rails feature

   Active Record Callbacks and others do not control input filtering; only Strong Parameters do.

3. Final Answer:

   Strong Parameters -> Option A

4. Quick Check:

   User input filtering = Strong Parameters [OK]

Hint: Strong Parameters filter user input safely [OK]

Common Mistakes:

• Confusing callbacks with input filtering
• Thinking Asset Pipeline handles security
• Assuming Action Mailer controls input

2. Which line correctly enables CSRF protection in a Rails controller?

easy

A. enable_csrf_protection!

B. protect_from_forgery with: :exception

C. csrf_protect true

D. use_csrf_protection = true

Solution

1. Step 1: Recall Rails CSRF protection syntax

   The correct method to enable CSRF protection is protect_from_forgery with: :exception in controllers.

2. Step 2: Check other options for validity

   Other options are not valid Rails syntax and will cause errors or have no effect.

3. Final Answer:

   protect_from_forgery with: :exception -> Option B

4. Quick Check:

   CSRF protection syntax = protect_from_forgery [OK]

Hint: Use protect_from_forgery with: :exception [OK]

Common Mistakes:

• Using non-existent methods for CSRF
• Forgetting to add CSRF protection
• Misnaming the method or options

3. Given this Rails view code:

<%= raw @user.name %>

What security risk exists if @user.name contains HTML tags?

medium

A. Cross-Site Scripting (XSS) attack

B. SQL Injection

C. Mass Assignment

D. Denial of Service

Solution

1. Step 1: Understand output escaping in Rails views

   Using <%= %> escapes HTML by default, but if raw HTML is inserted, it can cause XSS.

2. Step 2: Identify the risk of unescaped HTML in user input

   If @user.name contains HTML tags and is not escaped, it can run malicious scripts in the browser, causing XSS.

3. Final Answer:

   Cross-Site Scripting (XSS) attack -> Option A

4. Quick Check:

   Unescaped HTML in views = XSS risk [OK]

Hint: Unescaped user input risks XSS attacks [OK]

Common Mistakes:

• Confusing XSS with SQL Injection
• Assuming Rails never escapes output
• Ignoring HTML tags in user input

4. You see this code in a Rails controller:

params.require(:user).permit(:name, :email)

But users report they can update admin-only fields. What is the likely problem?

medium

A. CSRF protection is disabled

B. The controller action is missing

C. Strong Parameters are not used correctly

D. The database schema is incorrect

Solution

1. Step 1: Analyze the use of Strong Parameters

   The code shows permitted params, but if the controller does not use this filtered params hash for updating, mass assignment can happen.

2. Step 2: Identify why admin-only fields update

   If the controller uses unfiltered params or merges extra params, Strong Parameters are bypassed, causing security issues.

3. Final Answer:

   Strong Parameters are not used correctly -> Option C

4. Quick Check:

   Mass assignment issue = incorrect Strong Parameters use [OK]

Hint: Always use filtered params for updates [OK]

Common Mistakes:

• Assuming CSRF causes mass assignment
• Ignoring how params are passed to update
• Blaming database instead of controller code

5. You want to ensure all Rails app traffic is secure and user data is protected. Which combination of practices is best?

hard

A. Only use HTTPS and ignore CSRF and output escaping

B. Disable CSRF protection, use HTTP, and sanitize database inputs

C. Use HTTP, skip escaping output, and rely on user validation

D. Force HTTPS, enable CSRF protection, and escape all output

Solution

1. Step 1: Identify key security practices for web apps

   Forcing HTTPS encrypts data in transit, CSRF protection stops fake requests, and escaping output prevents XSS.

2. Step 2: Evaluate each option's security coverage

   Force HTTPS, enable CSRF protection, and escape all output covers all three essential protections. Others disable or ignore important protections, increasing risk.

3. Final Answer:

   Force HTTPS, enable CSRF protection, and escape all output -> Option D

4. Quick Check:

   HTTPS + CSRF + escaping = best security [OK]

Hint: Combine HTTPS, CSRF, and escaping for strong security [OK]

Common Mistakes:

• Ignoring CSRF protection importance
• Thinking HTTPS alone is enough
• Skipping output escaping