Drupal Security

Securing your Configuration

Justin C. Klein KeaneUniversity of Pennsylvania

School of Arts and SciencesInformation 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 Email 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 (

http://www.ossec.net)