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

2. 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

3. 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.”

4. 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...

5. 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

6. 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

7. 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

8. 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

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

10. 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!

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

12. Privilege Continued Don't tree the Drupal permissions form!

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

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

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

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

17. 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

18. Refine Input Types Restrict HTML Input

19. 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!

20. File Uploads Be careful what files can be uploaded

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

22. Mitigation Defensive strategies help to defend your Drupal site

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

24. Defense in Depth Review your logs to detect Or use an automated system like OSSEC (http://www.ossec.net)http://www.ossec.net