Ruby on Rails Risk Assessment & Management 4 — Questions and Answers
Question 1: What is the risk of using `find_by_sql` or `where` with string interpolation of user input in Rails ActiveRecord?
- SQL injection, allowing attackers to manipulate or exfiltrate the database (Correct answer)
- ActiveRecord connection timeout due to long query strings
- Automatic full-table scans bypassing indexes
- N+1 query generation in association joins
Correct answer: SQL injection, allowing attackers to manipulate or exfiltrate the database
String interpolation bypasses ActiveRecord's parameterized query sanitization, directly embedding user input into SQL statements.
Question 2: Which risk does enabling `config.assets.compile = true` in a Rails production environment introduce?
- Increased CPU/memory load and potential DoS from on-demand asset compilation per request (Correct answer)
- Permanent disabling of the Turbo Drive page-transition cache
- Breaking of Webpacker JavaScript module resolution
- Loss of asset fingerprinting causing cache invalidation failures
Correct answer: Increased CPU/memory load and potential DoS from on-demand asset compilation per request
Live asset compilation is expensive; if triggered per request under load, it can exhaust CPU and memory, effectively causing a denial of service.
Question 3: In Rails, what is the risk of using `protect_from_forgery with: :null_session` instead of `:exception` on non-API controllers?
- CSRF attacks silently succeed with a blank session rather than being rejected (Correct answer)
- The session store switches from cookies to ActiveRecord automatically
- Devise logout tokens become permanently invalidated
- The Rails router raises a RoutingError for all POST requests
Correct answer: CSRF attacks silently succeed with a blank session rather than being rejected
:null_session only clears the session on a CSRF mismatch instead of raising an error, meaning forged requests can still partially succeed.
Question 4: What security risk is associated with using `send` or `public_send` with user-controlled method names in a Rails controller?
- Attackers can invoke arbitrary public methods on the object, including dangerous ones like destroy or system calls (Correct answer)
- Ruby raises a NoMethodError that exposes the full controller backtrace
- The ActionDispatch middleware stack is bypassed for the request
- Session cookies are regenerated on every invocation
Correct answer: Attackers can invoke arbitrary public methods on the object, including dangerous ones like destroy or system calls
Allowing user input to select the method name via send gives attackers control over which methods execute, potentially triggering destructive actions.
Question 5: Which risk does an overly permissive CORS configuration (e.g., `origins '*'`) in a Rails API-only app create?
- Any website can make authenticated cross-origin requests using the victim user's credentials (Correct answer)
- The Rails router rejects same-origin requests from the frontend
- ActionController sets all responses to Content-Type: text/plain
- Rack middleware strips Authorization headers from all requests
Correct answer: Any website can make authenticated cross-origin requests using the victim user's credentials
A wildcard CORS origin combined with credentials: true allows malicious sites to issue API requests on behalf of logged-in users.
Question 6: What risk does failing to rotate `secret_key_base` after a production server compromise pose in a Rails application?
- Attackers can continue forging valid session cookies and CSRF tokens indefinitely (Correct answer)
- The Rails asset fingerprint pipeline produces incorrect digests
- ActiveRecord encrypted attributes can no longer be decrypted
- Devise password reset tokens remain permanently valid
Correct answer: Attackers can continue forging valid session cookies and CSRF tokens indefinitely
secret_key_base signs cookies and CSRF tokens; without rotation after a breach, an attacker retains the ability to forge trusted session data.
Question 7: Which risk does allowing users to supply file paths directly to `File.read` or `send_file` in a Rails controller introduce?
- Path traversal attacks enabling arbitrary file reads outside the intended directory (Correct answer)
- MIME type spoofing causing browser XSS via downloaded files
- Rack content-length mismatches triggering connection resets
- ActiveStorage attachment IDs being overwritten on disk
Correct answer: Path traversal attacks enabling arbitrary file reads outside the intended directory
Without path sanitization, sequences like ../../etc/passwd allow attackers to read arbitrary files the Rails process has permission to access.
What is the risk of using `find_by_sql` or `where` with string interpolation of user input in Rails ActiveRecord?