• Your site is vulnerable (really, it is)
  • GVS offers security review service for Drupal
  • Bad things: abusing resources, stealing data, altering data
    • Abusing resources: DDOS (extorting money from site owner), using open relay in a mail sending module for spam
    • Stealing data: from users (their passwords, e-mail address)
    • Altering data: defacement
  • You don't hear about security vulnerabilities much; Drupal core mentions vulnerabilities (and updates) but not so much for modules
  • Worry in a prioritized way
  • Choose your strategy: stay ahead of the pack, or protect valuable assets?
  • Attacks focus on sites that are out of date
  • Know about releases, have a method to update your site, do it
  • Look into Aegir if you're running multiple sites

Configuration

  • Available updates- settings, e-mail notifications when modules you use are updated
  • Security review module: drupal.org/project/security_review
  • Will show if your site is under attack with a SQL injection
  • Part of security review: check off which roles are considered "trusted" - trust-checks and points out which permissions are bad to give to untrusted users
  • Can skip some of the checks so they don't nag you (if this is on a dev server, and it's not relevant)
  • There is a hook to be able to run additional checks, but not sure whether modules should be able to declare their things (do we trust module developers to come up with the right set of rules?)
  • If there's something that can take an action on your site, accessible via a link - that could be a vulnerability (i.e. the "turn off this check" feature of the security module)
  • Run it before you launch, after you make big config changes; could do it as a periodic check and e-mail the report. Is ok to have always-on for a live site though

Vulnerabilities by type

  • Announcements from drupal.org; most sites have custom modules, almost always have custom themes
  • Analysis of one site: 3-4 vulnerabilities in Drupal core, 20 in contrib modules, 100 vulnerabilities in custom theme/modules (no one else is reviewing that stuff except for you)
  • XSS (cross-site scripting) - one of the hardest to fix
  • Access bypass - good ways to fix this
  • Cross site referral forgeries
  • SQL injection - easy to protect against, only getting easier

XSS

  • Anything you can do XSS can do (better)
  • XSS can change password for user 1
  • Most people don't know they've been a victim of XSS; it's in your browser, browser just executes javascript, don't know until you try to log back in
  • XSS tools exist to probe your network - even if your Drupal is on the intranet
  • Automated tools are a great way to get started, but not all that valuable in actually identifying things (false positives, false negatives)

Insecure configuration of input formats

  • Input formats and filters are confusing - people do what they need, and forget about it, and open themselves up to XSS
  • Anonymous users: shouldn't be allowed to have more than one input format
  • Filtered HTML is the right thing for untrusted roles
  • To this day, WYSIWYG modules say "give everyone access to full HTML and tinymce will just work" - NO! DON'T DO THAT!
  • Defaults are good: filtered HTML is a good thing
  • It's tempting to add images, spans, divs, etc - but different browsers have different vulnerabilities that way
  • There's a page on drupal.org that talks about what's safe to put in (there's some gray area - depends on your users and their browsers)
  • Weights: HTML corrector needs to go last

XSS for Themers/Coders (and reviewers)

  • Browscap module: analyzes user agents for people who go to the site
  • Firefox extension (default user agent) - used to be for Firefox to pretend to be IE, but now people use it for other things
  • Hackers can take normal user agent and replace it with jQuery that will be sent as the user agent - PWNED
  • Is there a module that will strip in javascript from the input box? - Filtered HTML does that
  • You can strip the script, or you can escape it (so it shows up as harmless text)
  • Filtered HTML also gets rid of attributes
  • There's a module that says which attributes can come through on which tags - well, the admin screen for it is huge, the input format area is a problem because it's confusing, so do you want to add an even more confusing module?
  • Themers: Read tpl.php and default implementations; rely on your module developer for variables that are ready to be printed (hook pre-process)
  • Developers: where does the text come from, is there a way a user can change it, in what context is it being used?
  • More is from the user than you think (user agents are from the user)
  • Filtered HTML makes things safe for the browser context
  • When data leaves Drupal and goes into MySQL - need to escape the data to make it safe for putting into the database
  • Contexts: mail (some clients sorta support javascript, need to specify plaintext), database, web, server
  • Take an hour: http://acko.net/blog/safe-string-theory-for-the-web
  • Drupal philosophy: make things secure by default
  • Escape variables using the checkplain function
  • If your site is translatable, it's also probably secure
  • If you're using the API properly, you probably don't need to worry about security (but it takes a while to learn how to use the API property)

Cross Site Request Forgeries (CSRF)

  • Taking an action without confirming the intent of that action
  • User Protect module - makes it harder to delete user 1; protects anonymous user, user 1, can add other users
  • Drupal's form API has protection from this - using links doesn't
  • An anonymous user can insert an "image" (the browser goes to look for it, and if that "image" is the link for User Protect that deletes the protection for user 1, that's bad)
  • In the case of User Protect, there's now a confirmation form - browser would just fetch confirmation form and throw that away-- requirement that you have to click on "submit" button would save you from anything bad happening
  • If you really want to use links like User Protect does, create a token based on something unique to the site, the user, and the action (and validate the token when the action is requested)
  • User session ID (unique key private to site, generated randomly at login) + form ID
  • When the action is submitted, Drupal will validate that it's still there
  • Is it possible to give permissions to manage everything EXCEPT user 1? - that's what User Protect does
  • Or, just use the form API - it includes this protection by default

Security and usability

  • Confirmation forms suck
  • BUT, truly destructive actions should be hard to do
  • Don't delete, archive and provide undo
  • Choose links or forms for usability, not security

Resources

  • drupal.org/security-team
  • drupal.org/security
  • drupal.org/writing-secure-code
  • drupal.org/security/secure-configuration
  • heine.familiedeelstra.com
  • crackingdrupal.com
  • crackingdrupal.com/node/34 - XSS Cheat Sheet
  • crackingdrupal.com/node/48 - CSRF

Questions

  • Rainbow tables - MD5 values for every possible password up to 6 characters
  • crackingdrupal.com - has resources including list of security modules (Salt module has salting of passwords)
  • Any way to hide you're running Drupal? - data in the CSS files, standard Drupal jQuery, a few files in the root directory, expiration date for anonymous is Dries's birthday; there's all sorts of things that fingerprint a Drupal site, trying to hide you're running Drupal takes more time than it's worth if you just keep up with updates