Drupal Security Securing your Configuration Justin C. Klein Keane University of Pennsylvania School of Arts and Sciences Information Security and Unix Systems

Security Responsibility Drupal API protects sites from many threats Module code may have holes but it's tough to find them on your own By definition you need to delegate privilege Enforcing safe configuration is just a mouse click away

Why Bother? “I'm running a small site, who would want to attack it?” “I back up every night, if it goes down I can just restore?” “I'm the only admin, so vulnerabilities don't actually affect users.”

Logical Fallacy You don't know what the attacker is after! Bandwidth Blackhat SEO Spam Drive by download JavaScript port scanning Host RFI text file On, and on, and on...

Risk Analysis Everyone should gauge their own risk Threat x Likelihood x Impact = Risk How can you judge likelihood? What about unknown threats? You may not think of security problems before they affect your site

Sample Attack Pattern Enumerate user accounts Brute force (guess) passwords Log in as a low privilege user Escalate privilege Take over web server process Establish a shell account Escalate privilege to root

Real World Attack Pattern Attacker identifies reflected XSS Attacker links to your reflected XSS Search engine crawls link, reflects to attacker site Attacker site gains search rank based on your site

Other Attack Patterns Attacker discovers ability to post content Attacker posts stored XSS Attacker posts to site with link to malware, trust exploitation Attacker spams your site Attacker brute forces a site account Account has same credentials as shell Possibilities are endless

Account = Privilege = Danger! Accounts have specific privilege Some privileges are super dangerous: Administer content types Administer filters Administer users Administer permissions Administer site configuration

PHP through Web UI = THREAT If attackers can write PHP it's game over Jealously protect PHP permissions Users with PHP can destroy the site by accident Poorly coded PHP can introduce other vulns!

Permissions to Create Content Created content could mean: Stored xss Stored xsrf Hijacked message Exploited trust Spam Drive by download And on and on...

Privilege Continued Don't tree the Drupal permissions form!

Use Roles Create roles to subdivide permissions to only those users who actually need them.

Limit Access to User Profiles Consider using RealName module Limit access to authenticated users

Creating Profiles Don't allow anonymous users to create new accounts (or they will) Be careful what permissions these accounts could get

Don't Passwords! Remove '!password' tokens! Login link works just fine

Limit PHP If you aren't using the PHP input type get rid of it Delete php in the /modules directory This will remove the PHP input format filter Make sure no role has any permission with 'PHP' in the description Monitor your permissions assignments

Refine Input Types Restrict HTML Input

Modules Modules are the #1 way vulnerabilities get to your site Don't use pre release modules no matter what the help forums say! They aren't suitable for production They're not supported by Drupal security They're buggy by definition!

File Uploads Be careful what files can be uploaded

Restrict Error Reporting MySQL errors aren't helpful to users and can give away configuration details.

Mitigation Defensive strategies help to defend your Drupal site

Defense in Depth If you can't prevent – detect! Several core modules help

Defense in Depth Review your logs to detect Or use an automated system like OSSEC (