Drupal Security2009. January 17., Drupalcamp CologneWith special thanks to Kuai Hinojosa and Greg Knaddison

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

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.

of websites haveCross site scripting issues

67%http://www.whitehatsec.com/home/assets/presentations/PPTstats082708.pdf

What can XSS do?

Example from Heine Deelstra, security team lead

Easy to loose credibility, hard to

regain it

So what are these issues?

Common issues

• Client-side attacks

• Cross site scripting (XSS)

• Cross site request forgery (CSRF)

Common issues

• Command execution

• SQL injection

Common issues

• Authentication problems

• Authorization problems

• Information disclosure: leakage, directory indexing, known resource locations

Is Open Source secure?

“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

“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

Is Drupal secure?

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

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.

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

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

Designed againstSQL 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()

Designed to protect content

• user_access(‘administer nodes’, $account)

• node_access(‘edit’, $node, $account);

• db_query(db_rewrite_sql(‘SELECT title FROM {node}’));

Designed against information leakage

• Ensure your .htaccess is effectively working

• Turn off public error reporting

• Avoid using file browser/uploader scripts

Designed to help users be secure

• Password strength checker

• Update notification module

• Know what you run, keep it secure

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

Drupal security team

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

Design. Educate. Fix.

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

Points of contact

• Releases at http://drupal.org/security

• Reporting issues: http://drupal.org/node/101494

• Reporting cracked sites: http://drupal.org/node/213320

Questions?

Thank you!