Drupal Risk Assessment & Management 5 — Questions and Answers
Question 1: Which approach best supports ongoing risk management for a large Drupal multisite installation?
- Centralizing Drupal core and contributed modules via Composer with a shared codebase and per-site settings (Correct answer)
- Installing separate, independent Drupal copies for each site to avoid shared risk
- Disabling automatic update checks to reduce server load across all sites
- Granting each site's editor full administrator access to simplify management
Correct answer: Centralizing Drupal core and contributed modules via Composer with a shared codebase and per-site settings
A shared codebase managed by Composer means security patches are applied once and inherited by all sites, reducing the risk surface across the entire installation.
Question 2: A Drupal site receives a high-severity security advisory for a module it uses. According to risk management best practices, what should happen first?
- Assess whether the vulnerable functionality is reachable by potential attackers on this specific site (Correct answer)
- Immediately disable the module without reading the advisory details
- Wait for the next scheduled maintenance window regardless of severity
- Notify end users of the vulnerability before patching
Correct answer: Assess whether the vulnerable functionality is reachable by potential attackers on this specific site
Context-specific impact assessment determines actual exploitability before committing to an emergency change that could cause downtime.
Question 3: Which Drupal mechanism reduces the risk of cross-site request forgery (CSRF) attacks on state-changing operations?
- Drupal's form API automatically generates and validates unique form tokens (Correct answer)
- Drupal forces all POST requests to use HTTPS
- Drupal's Block system prevents unauthorized form submissions
- Drupal validates the user's IP address on every form submit
Correct answer: Drupal's form API automatically generates and validates unique form tokens
Drupal's Form API includes built-in CSRF tokens (form_token and form_build_id) that are validated on submission, preventing cross-site request forgery.
Question 4: What risk does running Drupal with PHP's 'register_globals' enabled (on legacy PHP versions) introduce?
- Attackers can inject arbitrary variables via URL parameters, potentially overwriting Drupal's internal variables (Correct answer)
- PHP runs slower because all globals must be serialized on each request
- Drupal's database abstraction layer loses prepared statement support
- Session cookies are broadcast to all domains in the same TLD
Correct answer: Attackers can inject arbitrary variables via URL parameters, potentially overwriting Drupal's internal variables
register_globals allows external input to populate PHP variables, enabling attackers to overwrite security-relevant variables in Drupal's codebase.
Question 5: A risk assessment flags that Drupal's cron is running publicly accessible at /cron/{key} without HTTPS. What is the primary concern?
- The cron key can be intercepted and used to trigger cron jobs or enumerate system tasks (Correct answer)
- Cron jobs will fail because Drupal requires IPv6 for cron execution
- The cron endpoint will cache all outputs and expose them to anonymous users
- Running cron over HTTP disables Drupal's queue worker system
Correct answer: The cron key can be intercepted and used to trigger cron jobs or enumerate system tasks
The cron key transmitted over plain HTTP can be sniffed by a network observer, who could then trigger cron execution or map system tasks.
Question 6: Which configuration change reduces the risk of brute-force attacks on Drupal login?
- Installing the Flood Control or Login Security module to limit failed login attempts (Correct answer)
- Increasing the maximum password length field to 512 characters
- Enabling Drupal's built-in two-column layout for the login form
- Setting the user registration setting to 'Visitors, but admin approval required'
Correct answer: Installing the Flood Control or Login Security module to limit failed login attempts
Flood Control and Login Security modules impose attempt limits and lockouts, directly countering brute-force credential attacks.
Question 7: An organization runs a risk assessment and determines that a third-party CDN handles DDoS mitigation for their Drupal site. Which risk management strategy is this?
- Risk transference — shifting DDoS impact responsibility to the CDN provider (Correct answer)
- Risk avoidance — eliminating the possibility of a DDoS attack
- Risk acceptance — acknowledging DDoS as an unmitigated threat
- Risk mitigation — reducing the likelihood of a DDoS occurring
Correct answer: Risk transference — shifting DDoS impact responsibility to the CDN provider
Using a third-party CDN for DDoS protection transfers the operational burden and financial impact of that risk to the provider.
Drupal Risk Assessment & Management 5
Which approach best supports ongoing risk management for a large Drupal multisite installation?