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.