Ruby on Rails Risk Assessment & Management 3 — Questions and Answers
Question 1: Which Rails feature, if misconfigured, can allow attackers to execute arbitrary code via crafted serialized objects in cookies or cache stores?
- Ruby object deserialization in Marshal-based cookie stores (Correct answer)
- ActiveRecord callbacks with after_find
- Turbo Streams broadcast channels
- ActiveJob perform_later serialization
Correct answer: Ruby object deserialization in Marshal-based cookie stores
Marshal.load on untrusted data can trigger arbitrary code execution; Rails historically used Marshal for cookie stores, making secret_key_base rotation critical.
Question 2: What risk does an open redirect vulnerability in a Rails app introduce?
- Attackers can craft URLs on your domain that redirect users to malicious sites, enabling phishing (Correct answer)
- It allows bypassing Devise authentication guards
- It exposes the Rails secret_key_base to external parties
- It disables SSL verification for outbound requests
Correct answer: Attackers can craft URLs on your domain that redirect users to malicious sites, enabling phishing
Open redirects let attackers use your trusted domain as a stepping stone, tricking users into following what appears to be a legitimate link.
Question 3: Which database-level risk does Rails' `dependent: :destroy` option on associations help mitigate?
- Orphaned child records that may expose data after a parent is deleted (Correct answer)
- SQL injection through association joins
- Race conditions during concurrent record deletion
- Integer overflow in foreign key columns
Correct answer: Orphaned child records that may expose data after a parent is deleted
Without dependent: :destroy (or :nullify), deleting a parent record leaves orphaned children that can be accessed directly, potentially leaking data.
Question 4: In a Rails API, what risk does omitting rate limiting on authentication endpoints introduce?
- Brute-force credential stuffing attacks against user accounts (Correct answer)
- Uncontrolled memory growth in the Puma process pool
- CSRF token exhaustion on token-refresh endpoints
- ActionMailer queue starvation
Correct answer: Brute-force credential stuffing attacks against user accounts
Without rate limiting, attackers can attempt thousands of username/password combinations per second against login or token endpoints.
Question 5: Which risk is introduced when a Rails app uses user-supplied input directly in a `system()` or backtick shell command?
- OS command injection, allowing arbitrary system commands to be executed (Correct answer)
- Memory corruption in the Ruby GC heap
- ActiveRecord connection pool exhaustion
- Uninitialized constant errors in the Rails autoloader
Correct answer: OS command injection, allowing arbitrary system commands to be executed
Passing unsanitized user input to shell execution methods allows attackers to append their own shell commands using metacharacters like ; or |.
Question 6: What is the risk of using `Kernel#eval` or `binding.eval` with user-controlled strings in a Rails application?
- Arbitrary Ruby code execution on the server, allowing full system compromise (Correct answer)
- Syntax errors that crash the Puma worker process
- Bypassing ActiveRecord query caching
- Double-rendering errors in ActionController
Correct answer: Arbitrary Ruby code execution on the server, allowing full system compromise
eval executes any Ruby code, so user-supplied strings can read files, exfiltrate environment variables, or spawn processes.
Question 7: Which risk does storing API keys or database passwords directly in `config/database.yml` or `config/secrets.yml` committed to version control introduce?
- Credential exposure to anyone with repository access, including public GitHub forks (Correct answer)
- Rails failing to parse YAML anchors at boot time
- ENV variable shadowing causing incorrect credential loading
- Capistrano deploy keys being invalidated on each push
Correct answer: Credential exposure to anyone with repository access, including public GitHub forks
Hardcoded secrets in committed files are permanently visible in git history, even after removal, to any person or bot with repo access.
Which Rails feature, if misconfigured, can allow attackers to execute arbitrary code via crafted serialized objects in cookies or cache stores?