The Security Training was presented by Greg Knaddison and Ben Jeavons from Growing Venture Solutions. Greg and Ben are both members of the Drupal Security team and co-authored the Drupal Security Report in 2010. Greg Knaddison is also the author of Cracking Drupal, a Drop in the Bucket, "the first book to reveal the vulnerabilities and security issues that exist in the sites that have been built with Drupal and how to prevent them from continuing".

The main goal of the training was to help the developers to start to "think like a hacker". Truly to make your site as secure as possible you need to think like a hacker, consider all the possible holes in your site and make sure to do your best to block the holes to keep your site as secure as possible.

Drupal, as a framework, has many mechanisms in place to keep sites secure, but as developers it's our responsibility to enforce the security by using these mechanisms and writing as secure code as possible.

Some of the main vulnerabilities found on the web, and that Drupal works to "fight" are:

• Access Bypass: Missing or unauthorized access checks
  • Drupal has a lot of hooks (functions that can be used in code to extend Drupal) in place for use in combating access bypass vulnerabilities and making sure appropriate permissions are applied to content access.
• Spam:
  • Internal Tools:
    • CAPTCHA
    • Spam Module
    • Bad Behavior Module
    • http://BL
  • Examples of External Tools:
    • reCAPTCHA
    • Mollom
• XSS - Cross Site Scripting (The Beast):
  • This is when some javascript, or other type of scripting language is somehow entered into the site's content and a visitor and/or administrator, unbeknowst to them, executes the script.
  • One of the easiest ways to combat that is make sure there is no way anything can be entered, by any unauthorized visitors into text fields by applying the correct input filters based on specific roles.
  • In addition, there are functions such as check_plain() that can be applied to user data programmatically to ensure, that even if they are somehow able to enter the code into text fields, the code that runs that page will check the inputted data.
• CSRF: Cross Site Request Forgeries
  • This is when a hacker makes an action occur using your session without your knowledge or approval.
  • One example of this would be one of those "punch the monkey" type games. You think you are simply playing a game, but as soon as you "punch the monkey" some other behavior happens behind the scenes, ie: your account is deactivated, or worse.
  • To combat this type of attack, Drupal has things called tokens that are made up of many parts of your session at a given time and are very hard to spoof.
• SQL Injections:
  • Attacker sends specially crafted data, the data “tricks” the system into switching context and the remaining data is interpreted as an SQL command
  • Protect from SQL injections by escaping user data using "placeholders" in the queries.

The root cause of most vulnerabilities on any site on the web is user supplied input, and ALL Drupal sites depend heavily for user supplied input to exist. This includes everything from the code that runs the sites, the text in the body of the nodes, to the comments left by visitors to the site. Greg and Ben suggest to trust (almost) nothing. Considering this, every bit of code we write, every page that we develop, we must be aware of where a user could be inputting data. This is not just the obvious, like text fields, but also submit buttons, hidden fields, URL's query strings, etc.

As part of the Drupal community is a very active group of individuals that make up the Drupal Security Team. These individuals are a