Security best practices in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding CSRF Protection in Rails

What is the primary purpose of the protect_from_forgery method in a Rails controller?

A It prevents Cross-Site Request Forgery attacks by verifying authenticity tokens in non-GET requests.

B It encrypts all user passwords before saving them to the database.

C It automatically sanitizes all user input to prevent SQL injection.

D It disables cookies to enhance session security.

💡 Hint

Think about how Rails protects forms and non-GET requests from unauthorized actions.

The protect_from_forgery method helps prevent CSRF attacks by requiring a valid authenticity token in forms and AJAX requests. This token ensures that the request comes from the legitimate user.

❓ component_behavior

intermediate

Effect of Strong Parameters on Mass Assignment

Given the following controller code snippet, what will happen if a user tries to submit a form with an extra parameter admin: true?

def user_params
  params.require(:user).permit(:name, :email, :password)
end

A The <code>admin</code> parameter will be ignored and not assigned to the user model.

B The <code>admin</code> parameter will be assigned, making the user an admin.

C The application will raise a <code>ForbiddenAttributesError</code> exception.

D The <code>admin</code> parameter will overwrite the <code>email</code> attribute.

💡 Hint

Consider how permit controls which parameters are allowed for mass assignment.

Strong parameters only allow the specified attributes (:name, :email, :password) to be assigned. Extra parameters like admin are filtered out and ignored, preventing unauthorized mass assignment.

📝 Syntax

advanced

Identifying Secure Session Store Configuration

Which of the following Rails session store configurations correctly enhances security by preventing session fixation and ensuring cookie confidentiality?

A Rails.application.config.session_store :cache_store, key: '_app_session', secure: false, httponly: true

B Rails.application.config.session_store :cookie_store, key: '_app_session', secure: false, httponly: false

C Rails.application.config.session_store :active_record_store, key: '_app_session', secure: false, same_site: :lax

D Rails.application.config.session_store :cookie_store, key: '_app_session', secure: true, httponly: true, same_site: :strict

💡 Hint

Look for options that enable secure cookies and restrict JavaScript access.

Setting secure: true ensures cookies are sent only over HTTPS. httponly: true prevents JavaScript access to cookies, reducing XSS risks. same_site: :strict helps prevent CSRF by restricting cross-site requests.

🔧 Debug

advanced

Debugging SQL Injection Vulnerability

Consider the following Rails code snippet in a controller:

def search
  @users = User.where("name = '#{params[:name]}'")
end

What is the main security issue with this code?

A It will raise a syntax error due to incorrect string interpolation.

B It is vulnerable to SQL injection because user input is directly interpolated into the query string.

C It prevents SQL injection by escaping user input automatically.

D It uses parameterized queries, so there is no security issue.

💡 Hint

Think about how user input is used inside the SQL query string.

Directly inserting user input into a SQL query string without sanitization allows attackers to inject malicious SQL code. Rails provides parameterized queries to avoid this risk.

❓ state_output

expert

Output of Content Security Policy Header Configuration

Given the following Rails configuration in config/application.rb:

config.action_dispatch.default_headers = {
  'Content-Security-Policy' => "default-src 'self'; img-src https://trusted.com; script-src 'none'"
}

What will be the effect on the browser when loading this app?

A The browser will block all resources including images and scripts from loading.

B The browser will allow scripts from any source but block images from external domains.

C The browser will only load resources from the same origin, images from https://trusted.com, and block all scripts.

D The browser will ignore the header because it is misconfigured.

💡 Hint

Review how Content Security Policy directives control resource loading.

The default-src 'self' directive restricts all resources to the same origin by default. The img-src https://trusted.com allows images from that domain. The script-src 'none' blocks all scripts from loading, enhancing security.

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