Drupal security presentation from Drupalcamp Cologne 2009.

1. Drupal Security
2009. January 17., Drupalcamp Cologne
With special thanks to Kuai Hinojosa and Greg Knaddison

2. Who cares?
• With relatively simple holes, your
administrator user can be taken over
• From there, people will easily “use”
your site: place spam links, get user
data, distribute viruses

3. Relatively simple?
WhiteHat security research collected
data through vulnerability assessment of
the largest and most popular websites in
the retail, financial, insurance, education
and social networks.

4. 67%
of websites have
Cross site scripting issues
http://www.whitehatsec.com/home/assets/presentations/PPTstats082708.pdf

5. What can XSS do?
Example from Heine Deelstra, security team lead

6. Easy to loose
credibility, hard to
regain it

7. So what are these
issues?

8. Common issues
• Client-side attacks
• Cross site scripting (XSS)
• Cross site request forgery (CSRF)

9. Common issues
• Command execution
• SQL injection

10. Common issues
• Authentication problems
• Authorization problems
• Information disclosure: leakage,
directory indexing, known resource
locations

11. Is Open Source
secure?

12. “Open Source is
secure”
• Open Source makes people look at it
• Popularity gets more eyes
• There are always more smart people to
find and fix problems

13. “Open Source is
insecure”
• People can equally find holes
• Some people (inadvertently) disclose
issues in the public
• Fix becomes public and can / will be
reviewed

14. Is Drupal secure?

15. Secure API design
• Drupal APIs are designed to be secure
• It is eventually up to programmers to
use them that way
• http://drupal.org/writing-secure-code

16. Designed against XSS
• t(), format_plural() placeholders:
%name, @url, !insecure
t(‘%name has a blog at <a
href=”@url”>@url</a>’, array(‘@url’ =>
valid_url($user->profile_blog), ‘%name’
=> $user->name));
• Use Drupal.t(), Drupal.formatPlural() in JS.

17. Designed against XSS
• check_plain() to escape text to HTML
• check_markup() to format text to HTML
• filter_xss() to filter text to HTML
• filter_xss_admin() to filter admin text to
HTML
• node_view($node) instead of $node->body

18. Designed against
CSRF
• Form API checks generated form token
• Token API provided to generate / check
eg. for AJAX implementations, see
drupal_valid_token()
• Valid choice checker

19. Designed against
SQL injection
• db_query(“UPDATE {mytable} SET
value = ‘%s’ WHERE id = %d”, $value,
$id);
• If you need to include dynamic table or
column names in your query, see
db_escape_table()

20. Designed to protect
content
• user_access(‘administer nodes’, $account)
• node_access(‘edit’, $node, $account);
• db_query(db_rewrite_sql(‘SELECT title
FROM {node}’));

21. Designed against
information leakage
• Ensure your .htaccess is effectively
working
• Turn off public error reporting
• Avoid using file browser/uploader
scripts

22. Designed to help
users be secure
• Password strength checker
• Update notification module
• Know what you run, keep it secure

23. You are responsible
for configuration
• Limit Drupal permissions
• Look at your input formats (you might
be easily Googled)
• Instead of using the PHP filter, write
your own modules
• Watch for the files you allow to be
uploaded

24. Drupal security team
A team of volunteers working to ensure
best security of Drupal and thousands of
contributed modules

25. Design. Educate. Fix.

26. What’s supported?
• Drupal core and all(!) contributed
project on drupal.org
• Not actively looking for vulnerabilities
in contributed modules
• Stable releases and development
versions (for very popular modules)
• Only current and one earlier versions
are supported: now 6.x, 5.x

27. Points of contact
• Releases at http://drupal.org/security
• Reporting issues: http://drupal.org/
node/101494
• Reporting cracked sites: http://
drupal.org/node/213320

28. Questions?

29. Thank you!