Security audits in Drupal are not a trivial thing. This is how we do it.Tue, 2016-03-22 13:59By salva
Site audits are one of the services that some of our clients have requested from us in the past. While a site audit might be done with a specific objective in mind, there's always a common reason: find, understand, and fix any potential holes or problems that could cause a service outage on the site, or on the server where it is hosted. In some cases, that's the only reason, whereas in other cases the outcome of the audit will inform a more important decision, such as a platform or server move, or a site rebuild, to name a few.
Depending on the goal of an audit, the things to look at on the site might change a bit: is it a performance audit, a security one, or a general review to check the overall status of the site and the feasibility of keep evolving it in an efficient way? This post covers the details concerning security audits in particular, although some of the practices mentioned here do not belong exclusively to the realm of security, and will be equally needed in other audits. Let's get started.General aspects
There are some things that an audit should always cover, as they give a good overview of the site and how well it's been looked after. Some of these aspects are:
- General codebase observations: Get an overview of the structure and organisation of modules and custom php scripts (if any). In big projects, where people come and go and different developers get to work on the code, it's not uncommon to see a big mess in custom code, structured without consistent patterns or styleguides. This might not affect security directly, but it might be a sign that not much care has been put into how things are done, and it will surely impact maintenance.
- General code inspection: Performed through an IDE or automated tools, to find extensive uses of bad practices in code. Again, this might not necessarily surface any potential security holes, but depending on the tools used, there are cases in which it could actually do so. A good tool for a general review of Drupal modules is the Coder module, which can be tuned to look only for problems of a specific nature (e.g: only check Drupal standards).
- Site Audit Script: The Site Audit module is worth a look as well. While it's not the most feature-complete audit tool, it provides useful info about certain areas of a Drupal site, and includes some security checks too.
- Watch out for patched modules: The Hacked! module can help you to easily identify which contributed modules have been altered by developers after the official version was added to the codebase. It compares the installed version with the official one available in www.drupal.org, to highlight the differences. If the development team have behaved well, all these patches will be documented in some way in the codebase, so make sure you consider them in more specific audits, in particular for security.
Drupal core is great when it comes to security, and it also encourages module developers to follow good practices when contributing to the community, by providing clear guidelines about how to write secure code. However, considering the low entry barrier of the platform for anyone who has some basic PHP skills, it's not hard to find projects in which some of the standard APIs and guideliness are either overlooked, or bypassed entirely. This opens possible security holes in the system.
Being a CMS, the possible security holes of a Drupal site may not lay only in the codebase, but also in how the different modules are configured, often in a too-permissive fashion. Enabling PHP Filter to allow PHP execution from the UI, or a bad configuration of input (text) formats, are just a couple examples of how a bad configuration could be used to breach into the site. You can find more details about this in this page of the Administration & Security Guide.
In this article, I'd like to focus a bit more in the possible issues that can be generated at the codebase level. The next list covers the most common vulnerabilities that should be looked for when auditing a Drupal project, and some other aspects to consider. These checks are normally for the custom code. Some details are given next to each vulnerability type, with the common functions or elements that can be used to exploit the vulnerability, or where it might be introduced:
SQL Injection: Make sure no $_GET data is used without proper sanitisation, specially if it's going to be used in queries to the database. The term is a classic, I know, and it's been used and abused all over the web for a lot of years, but not without cause: it's been less than two years since I came across a vulnerability of this type (don't get excited, you won't find any name and shame in this post).
Check as well for usage of drupal_get_query_parameters(). If not treated safely, data received from there can be as dangerous as $_GET.
Remote code execution: Make sure $_POST data is being used safely. Not usually an issue if Drupal Form API is used. While not encouraged, it's possible for developers to use $_POST or $form_state['input'] to retrieve user-submitted data. So, when searching for places where this kind of data is used in code, make sure those variable names are included in the search.
Pay also attention to custom data stored in the database that is later used for custom logic, but having being previously retrieved through a custom form.
Some functions can be used to exploit vulnerabilities with malicious data captured through any of the methods described. Most of these functions are not too common for small websites, but they can be very dangerous if not used with care, so it's always worth looking for any usages of these in code, and in case you see any of them, ensure they're used safely:
XSS / Persistent XSS: Another classic. Check that all user input is sanitised before being output as HTML. See Handle text in a secure fashion:
General checks. Make sure these functions or statements are used according to the documentation, and with data sanitised where relevant:
Make sure anything contained in blocks content is sanitised, since these contents are output "as is".
Other possibly dangerous Drupal elements:
These elements are not dangerous as such, but they're used to display HTML contents. The general idea here is: sanitise data before displaying it!
Form API #title and #description
Form API #markup types.
Review usages of rich text fields in code, and make sure they're always displayed using their appropriate text format.
Views fields without sanitising (e.g: using the "raw” contents from a views template).
Do all custom hook_menu functions have access arguments declared?
Do all custom queries use the node_access tag where required?
Are permissions respected when displaying entities retrieved via EntityFieldQuery?
CSRF: Make sure all custom forms use Drupal's FAPI or confirmation forms / tokens.
These are some of the most common checks to go through when reviewing the site configuration:
HTTPS configured correctly.
PHP filter is disabled.
Access to text formats.
Private files directory is in a secure location outside of webroot.
Execution of PHP files in subfolders disabled.
Everything else covered in the Writing secure code page of the Drupal developer handbook.
Anything listed in the OWASP Top 10 should be always present in a security audit.
Some of the points listed there are rather uncommon to see these days. However, no matter how unlikely they are, a security vulnerability is always a risk, so as good developers is our duty to, at least, try our best to make sure we follow good practices and don't create holes in the system, or fix them if we find any.
Once in the auditor role, there are tools to automate the search for some of the possible issues in code. One example is the Security Review module for Drupal, which makes some checks on a given site (none on the codebase itself) and generates a report highlighting the areas where the configuration should be changed. Taking it a step further, the Paranoia module will automatically make some changes to your site, disabling certain sections or features that could make it insecure.
Security is not a setting, it's a process, and even experts (except Code Enigma sysadmins) make mistakes. The worst mistake one can make about a site is taking its security for granted.
PageDrupal Security Updates PageSecure Drupal Hosting BlogMeet the YubiKey PageDrupal Support
The Drupal Insert module is a convenient module to easily place images in content, without hassling around with a WYSIWYG editor. It is rightly a popular Drupal module (nearly 80,000 active installs). We are also using it in our blogs; in combination with Markdown you can easily and quickly format content.
The only problem is that the images are not looking good. The quality of the scaled images can be set in Drupal (Administration > Configuration > Media > Image toolkit), but I noticed they are never really good enough. Also because you have to deal with many different kinds and sizes of screens of visitors: you would like everybody to see a nice image (mobile, tablet, desktop, retina etc).Solution for better quality images
Drupal's menu system API underwent a large number of significant changes in Drupal 8, just like many other areas in Drupal's newest version.
The way we define what piece of PHP logic should respond to a particular path, e.g. /example, is no longer part of the menu; instead it is now defined via the route system. The menu system - as it should logically - is now used to define how a particular page (a route) fits into the menu system, tabs, and contextual links. Let’s take a quick look at how the familiar tasks of defining and altering such entries have changed.Tags: acquia drupal planet
We, at Drop Guard, are extremely concerned about all things Drupal security. Security is not something that can be taken for granted after ordering a security review, or passing through a "security checklist", or even after switching to Drop Guard for updates handling. We should always remember that security is a continuous process, and it consists of numerous bits and pieces requiring your attention all the time.
Luckily enough, Drupal is a highly modular system, and instead of reinventing the wheel we can take advantage of the existing and battle tested solutions which are aimed at helping us with ensuring the continuous security for our applications.
We've collected the essential security-related modules in our view, and split them into two categories - passive (designed to monitor and provide information) and proactive (designed to take action or make changes to application configuration to ensure stronger security).Modules Security Drupal Planet
There is a lot of hype around decoupled architectures, so before embarking on a project, it is important to make a balanced analysis. Your choice of architecture has implications on your budget, your team, time to launch, the flexibility for content creators, the ongoing maintenance of your website, and more. In this blog post, I'd like to share a flowchart that can help you decide when to use what technology.
This flowchart shows three things:
In practice, I believe many organizations want to use all of these content delivery options. In certain cases, you want to let your content management system render the experience so you can take full advantage of its features with minimal or no development effort (coupled architecture). But when you need to build a website that needs a much more interactive experience or that integrates with unique devices (i.e. on in-store touch screens), you should be able to use that same content management system's content API (decoupled architecture). Fortunately, Drupal allows you to use either. The beauty of choosing from the spectrum of fully decoupled Drupal, progressively decoupled Drupal, and coupled Drupal is that you can do what makes the most sense in each situation.
For years, we have been using and recommending memcached for Drupal sites as its caching layer, and we wrote several articles on it, for example: configuring Drupal with multiple bins in memcached.
Memcached has the advantage of replacing core caching (which uses the database) with memory caching. It still allows modules that have hook_boot() and hook_exit() to work, unlike external cache layers such as Varnish.
However, memcached has its limitations: It is by definition transient, so rebooting wipes out the cache, and the server can suffer if it has high traffic. It is also entirely memory resident, so to cache more items you need more RAM, which is not suitable for small servers.
The following is a detailed guide to get Redis installed and configured for your server. It assumes that you are an Ubuntu Server 14.04, or the equivalent Debian release.Installing Redis
You do not need to enable any Redis modules in Drupal.
Then, install the Redis Server itself. On Debian/Ubuntu you can do the following. On CentOS/RedHat, you should use yum.aptitude install redis-server
Then, install PHP's Redis integration. Once you do that, you do not need to compile from source, or anything like that, as mentioned in Redis README.txt file.aptitude install php5-redis
Restart PHP, so it loads the Redis integration layer.
This assumes you are using PHP FPM:
If you are using PHP as an Apache module, then you need to restart it as follows:service apache2 restart Configuring Redis
Then in your settings.php file, you should replace the section for memcache which would be as follows:$conf['cache_backends'] = './sites/all/modules/contrib/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_servers'] = array('127.0.0.1:11211' => 'default');
$conf['memcache_key_prefix'] = 'site1';
And replace it with the following configuration lines:// Redis settings
$conf['redis_client_interface'] = 'PhpRedis';
$conf['redis_client_host'] = '127.0.0.1';
$conf['lock_inc'] = 'sites/all/modules/contrib/redis/redis.lock.inc';
$conf['path_inc'] = 'sites/all/modules/contrib/redis/redis.path.inc';
$conf['cache_backends'] = 'sites/all/modules/contrib/redis/redis.autoload.inc';
$conf['cache_default_class'] = 'Redis_Cache';
// For multisite, you must use a unique prefix for each site
$conf['cache_prefix'] = 'site1'; Cleaning Up
Once you do that, caching will start using redis. Memcached is not needed, so you should stop the daemon:service memcached stop
And you should purge memcached as well:aptitude purge memcached
And that is all there is to it.Changing Redis Configuration
You can then review the /etc/redis/redis.conf file to see if you should tweak parameters more, such as changing maxmemory to limit it to a certain amount, as follows:maxmemory 256mb
More below on this specific value.Checking That Redis Is Working
To check that Redis is working, you can inspect that keys are being cached. For this, you can use the redis-cli tool. This tool can be used interactively, as in, you get a prompt and type commands in it, and results are returned. Or you can use the specific command as an argument to redis-cli.
For example, this command filters on a specific cache bin, the cache_bootstrap one:$ redis-cli
127.0.0.1:6379> keys *cache_boot*
Or you can type it as:$ redis-cli keys "*cache_boot*"
In either case, if Drupal is caching correctly, you should see output like this:1) "site1:cache_bootstrap:lookup_cache"
As you can see, the key structure is simple, it is composed of the following components, separated by a colon:
- Cache Prefix
This is the site name in a multi site environment.
- Cache Bin
This is the cache table name when using the default database caching in Drupal.
- Cache Key
This is the unique name for the cached item. For cached pages, the URL is used, with the protocol (http or https) and the host/domain name.
You can also filter by site, using the cache_prefix:$ redis-cli keys "*site1:cache_page*"
The output will be something like this:1) "site1:cache_page:http://example.com/node/1"
You can also check how many items are cached in the database:$ redis-cli dbsize
The output will be the number of items:(integer) 20344 Flushing The Cache
If you need to clear the cache, you can do:$ redis-cli flushall Checking Time To Live (TTL) For A Key
You can also check how long does a specific item stay in cache, in seconds remaining:$ redis-cli ttl site1:cache_page:http://example.com/
The output will be the number of seconds:(integer) 586 Getting Redis Info
You can get a lot of statistics and other information about how Redis is doing, by using the info command:$ redis-cli info
You can check the full documentation for the info command.
But here is one of the important values to keep an eye on is used_memory_peak_human, which tells you the maximum memory that was used given your site's specifics, such as the number of items cached, the rate of caching, the size of each item, ...etc.used_memory_peak_human:256.25
You can use that value to tune the maxmemory parameter, as above.
You can decrease the Minimum Cache Lifetime under /admin/config/development/performance to make the available memory fit that number, or the other way around: you can allocate more memory to fit more.Monitoring Redis Operations In Real Time
And finally, here is a command that would show you all the operations that are being done on Redis in real time. Do not try this on a high traffic site!$ redis-cli monitor Performance Results
Redis performance as a page cache for Drupal is quite good, with Time To First Byte (TTFB) is ~ 95 to 105 milliseconds.Alternatives To Redis and Memcached
We did fairly extensive research for Redis and Memcached alternatives with the following criteria:
- Compatible With Redis or Memcached Protocol
We wanted to use the same PHP extension and Drupal Redis (or Memcached) modules, and not have to write and test yet another caching module.
- Non-Memory Resident Storage
We want to reduce the memory foot print of Redis/Memcached, because they both store the entire key/value combinations in memory. But still wanted to get acceptable performance.
The following products all claim to meet the above criteria, but none of them worked for us. They were tested on Ubuntu LTS 14.04 64-bit:MongoDB
Using MongoDB article for more details.MemcacheDB
MemcacheDB is a Memcached compatible server which used the excellent Berkeley DB database for storage.
This MemcacheDB presentation explains what it does in detail.
It has an Ubuntu package right in the repository, so no need to compile from source, or manually configure it. It works flawlessly. The -N option enable the DB_TXN_NOSYNC option, which means writes to the database are asynchronous, providing a huge performance improvement.
Configuration in Drupal's settings.php is very easy: it is exactly like Memcached, with only the port number changing, from 11211 to 21201.
Alas, all is not rosy: it is not really a cache layer, since it does not expire keys/values based on time, like Memcached and Redis does.Redis NDS
Redis-NDS is a fork of Redis 2.6, patched for NDS (Naive Disk Store).
It does compile and run, but when the line: 'nds yes' is added to the configuration file, it is rejected as an invalid value. Looking briefly in the source, we also tried 'nds_enabled yes', but that was rejected as well. So we could not get it to run in NDS mode.ARDB
ARDB is another NoSQL database that aims to be Redis protocol compatible.
We compiled this with three different storage engines: The Facebook RocksDB did not compile to begin with. Google's LevelDB compiled cleanly, and so did WiredTiger. But when trying to connect Drupal to it, Drupal hanged and never came back with both engines.SSDB
SSDB is also another NoSQL database that tries to be Redis protocol compatible.
It compiled cleanly, but had the same symptom as ARDB: Drupal hangs and never receives back a reply from SSDB.
If you were able to get any of the above, or another Redis/Memcached compatible caching engine working, please post a comment below.Resources
- A useful article on Redis persistence. Make sure you read this in conjunction with Redis' own documentation on presistence.
- Redis documentation on memory optimization.
- The Pantheon Redis instructions are useful, even though they are specific to their hosted service.
One of these scenarios is using MongoDB as the caching layer for Drupal.
This article describes what is needed to get MongoDB working as a caching layer for your Drupal site. We assume that you have an Ubuntu Server LTS 14.04 or similar Debian derived distro.Download The Drupal Module
First, download the MongoDB Drupal module. You do not need to enable any MongoDB modules.drush @live dl mongodb Install MongoDB Server, Tools and PHP Integration
Then install MongoDB, and PHP's MongoDB integration. Note that 'mongodb' is a virtual package that installs the mongodb-server package as well as other client tools and utilities:aptitude install php5-mongo mongodb Restart PHP
Restart PHP, so that MongoDB integration takes effect:service php5-fpm restart Configure Drupal With MongoDB
Now, edit your settings.php file, to add the following:$conf['mongodb_connections']['default']['host'] = 'mongodb://127.0.0.1';
$conf['mongodb_connections']['default']['db'] = 'site1';
$conf['cache_backends'] = 'sites/all/modules/contrib/mongodb/mongodb_cache/mongodb_cache.inc';
$conf['cache_default_class'] = 'DrupalMongoDBCache';
Note, that if you have multisite, then using a different 'db' for different sites will prevent cache collision.Monitoring MongoDB
You can monitor MongoDB using the following commands.mongotop -v
mongostat 15 Tuning MongoDB
Turn off MongoDB's journaling, since we are using MongoDB for transient cache data that can be recreated from Drupal.
Edit the file /etc/mongodb.conf and change journal= to false.Performance Results
Quick testing on a live site showed that MongoDB performance is acceptable, but not spectacular. That is specially true when compared to other memory resident caching, such as Memcached or Redis.
For example, on the same site and server, with Redis, Time To First Byte (TTFB) is ~ 95 to 105 milliseconds. With MongoDB it is ~ 200, but also goes up to ~350 milliseconds.
Still, MongoDB can be a solution in memory constrained environments, such as smallish VPS's.Tags:
Civil Comments is a platform that brings real-world social cues to comments sections via crowd-sourced moderation and powerful community management tools. Civil Comments is the first commenting platform specifically designed to improve the way people treat each other online.
Unlike others who have thrown up their hands and accepted that the comments sections of the Internet would either be dominated by bullies and trolls, or become a moderation burden for a site's editors, the team at Civil is attempting to solve the problem with community moderation. It is an exciting new take on a widespread problem, and Chromatic is thrilled to bring Civil Comments integration to Drupal with a new contrib module.
It should be noted (and is on the project page!) that there is not currently a free version of Civil Comments. For the time being, it is only available with a subscription as Civil continues work on the platform, but from what I understand a free version is on the horizon.
It's a good time to press your advantage as a Drupal developer.
Drupal 8 has launched, and it's much easier now for Drupal developers to expose content and features on their sites via an API. The capability is built right into Drupal 8 Core. Some contrib modules are attempting to make such capabilities even better.Tags: acquia drupal planet
I had a question the other day on twitter as to if it’s possible to run drush sites aliases in parallel. Apparently I was asking the question the wrong way as @greg_1_anderson (Drush co-maintainer) told me that Drush supported –concurrent and apparently has for several years. In fact, its supported it so long and is so under used that they might remove it from Drush as a result :).
I recently defended my Master of Sciences thesis with a central theme of open source, activism and Drupal. You can grab a copy here or in the article links. I started this research project in 2007, in part, life got in the way but also, I didn’t know how to tell the story.
This video talks through how XMLRPC Page Load and HTTPRL Spider can be used to warm caches on private / authenticated sites. XMLRPC Page Load provides a callback that tricks Drupal into thinking that it’s delivering a page to certain user account. It does this by simulating page delivery but then never actually writing the output anywhere.
Drupal 8.1 will be released in April and it marks the start of a new era for Drupal.
Previously, new features were only added every few years, with the release of major Drupal versions such as 6, 7 and 8.
Now, thanks to a new release cycle, we can look forward to new Drupal features every six months. Drupal 8.1 is arriving six months after the release of 8.0, and we can expect version 8.2 in October this year.
So what's new in Drupal 8.1? Read on to find out ...