Slides of Kalle Varisvirta's auditing Drupal sites presentation, given at DrupalCamp Baltics on August 23, 2013 in Tallinn, Estonia

1. Auditing Drupal sites
Kalle Varisvirta
Technology Director
Exove
@kvirta

2. What’s an audit?
Audit is a run-through of an implementation of a site
Usually an experienced developer goes through an
implemented site in detail, also by looking at the actual
source code
Audits are done for many different reasons and thus the
actual process of doing an audit varies a lot

3. Why are audits done?
Basically, audits we’ve been doing can be categorized
in a couple of typical groups
Acquisition audit
Implementation verification audit
Vendor management audit
Support audit

4. Acquisition audit
Generally done before the decision to buy a business, either a
part of a bigger company (e.g. their online business) or a full
company
Basically a part of the ‘due diligence’ process
Usually these are done to smaller startups who base their
business to a web site / web service
Typically more in-depth
Focuses on whatever business plans there are for the system

5. Implementation
verification audit
A customer want to validate their vendor’s work on
their Drupal system
Usually pretty brief, done in collaboration with the
implementing vendor
Shouldn’t ever be done for a system that’s not finished,
unless it’s a strict architecture audit
Usually the client isn’t expecting major problems to be
found

6. Vendor management
audit
Vendor management audit is usually done to either
switch vendors or due to problems with the current
vendor
Usually done without the knowledge of the current
vendor, thus done usually with limited documentation
and/or information
Might be either very brief or very profound audit
Client expects to find problems in the implementation

7. Support audit
A very brief audit done to move the system to be
supported by the auditing partner
These are done with minimal resources, but must be
done well, because the vendor carries all the risks
The only type of audit where the auditing consultant
can learn from the experience, as all the details will be
revealed in the longer run

8. How it’s done

9. TIP #1
You always need
the source code

10. Getting started
First and foremost: start taking notes from day 1
Secure the source code and a dump of the database
If the data is too private, ask for it to be obfuscated
Don’t ever settle for partial source code, just the
custom modules, for example
They’ll be happy to leave the hacked core and
“enhanced” contrib modules outside of the audit

11. Install the site
Whichever audit you’re doing, start by installing the site
It’s a learning experience, you’ll find out what’s missing
and what’s not documented
You’ll probably have to stop several times to ask more
data, code, Varnish VCL configs, Apache rewrites, API
definitions (to create dummies) etc. so reserve enough
calendar time for this
Still worth the time - every time

12. TIP #2
You must
understand the
architecture

13. Architecture
Once installed, look at the architecture of the site
Usually Drupal sites are based on certain contrib
combinations to build functionality
Blocks, controlling them: context
Searching: Search API, Apache SOLR Integration
Translations: Field, Internationalization, Multisite
Access: Domain access, Taxonomy access

14. Architecture
Does it fit the purpose?
Is the site using Drupal as it should?
This is something we see a lot, Drupal is used just as
a web frontend to display data past it
Are there custom parts where there’s a well-working
contrib available?
Is it overly complicated?

15. Architecture
Always make sure you understand the architecture
Don’t get biased by your own favorite modules, there
are many valid ways of accomplishing many valid
functionalities on Drupal
When the site is very complicated, integrated and
contains a lot of custom code, understanding the
architecture might take several days
You’ll just have to endure it, it’s the prerequisite for a
proper audit

16. Reading code
Reading code is not a big problem in regular Drupal
audits
There’s relatively little custom code to be read and
you can find where it is by running Hacked! (https://
drupal.org/project/hacked)
When there’s a lot of code, remember you can’t read it
all

17. Reading code
With limited time and too much code to read, focus on
the parts that matter
You know where the security holes usually are
You know what mistakes beginners usually made
You know what’s great for killing performance

18. Looking for:
security holes?
Check for SSL login
Check for old contribs without security patches
Check out if all the custom parts are using abstraction to
interface with the database
Look for usage of uncleaned inputs in UI
Don’t forget the Javascript, a lot of XSS possibilities there
Look for API calls without HTTPS but with private data

19. Looking for:
beginner mistakes?
Look for unclean access to Drupal
Accessing database straight (and not own tables)
Look for unnecessary custom modules (good contribs
available)
Look for wrong hooks (e.g. init instead of cron for stuff
that’s needed to be done rarely)

20. Looking for:
performance problems?
Check out static caches for time-consuming functions
Check out the amount of processing in init hook
Look for slow backend APIs
Check out the caching strategy
Look for unnecessary, but very slow contrib modules
Look for misusage of contrib modules

21. Social engineering
Talk to the original site developers whenever it’s
possible
They’ll tell you how it works and why it works like that
They might even point you to potential problems
Just be polite and friendly, especially in acquisition
audits - auditing is not about pissing people off

22. TIP #3
It’s not just
the code

23. Installation and
server configuration
A really professionally made site might still be deployed
by a total newbie
Always look at the production environment
You’ll need at least read access to the actual server
or a copy of all the relevant configuration files
There’s a lot to check for security, performance and
reliability

24. Installation and
server configuration
Look at the PHP, httpd and PHP process manager
configurations
Opcode cache in use
PHP ‘scary options’ off
Apache/Nginx safely configured
MySQL and other databases
Replication configurations
Backups

25. Installation and
server configuration
Check for open ports, services running, MySQL
passwords
Look at the sweet extras, memcache configuration,
Varnish VCLs, MongoDB, Redis, SOLR configurations
While you’re at it, make sure you check out the
SOLR schemas, too

26. Drupal configuration
Then take a look at the Drupal configuration
User roles and privileges
Registration and login settings
Caching settings
Contrib module settings, beware, there might be
some really scary ones
Custom module settings

27. Drupal configuration
SEO configurations, that’s easily forgotten
Cleanup for automatic imports or other automatically
growing data
Multisite configurations
Language configurations
etc...

28. TIP #4
A quick
benchmark
never hurt
anyone

29. Performance
Depending on the audit, performance is just a part of the
audit, or the main focus of the audit
In acquisition audits, performance issues are usually very
important
The buyer, your customer, wants to use the site for
something bigger, better and more performance
needing
In this case, full load testing and benchmarking is
appropriate

30. Performance
But even in the normal case, a quick benchmark is in
order
Just run couple of pages with anonymous user and
logged in user with a benchmarking tool (ab, siege)
and profile (xdebug, xhprof) the backend (on a
separate benchmark run) under load
You’ll see the bottlenecks immediately and get an
idea if the site is slower than normal, or properly
optimized

31. TIP #5
Auditing is a
gentleman’s
game

32. Reporting
Usually one or two written reports are produced as an
output
Two written reports are needed when we need a
technical and a non-technical report
Frequently they contain parts of code or runtime grinds,
but sometimes the NDA bans that (possible in
acquisition audits)

33. Reporting
The usual audit document is divided into three parts
Introduction: explains the system, its architecture and
platform, modules and implementation on a high level
Findings: lists all the findings, usually also mentions
the stuff that was okay, but focuses on the problems
Improvement suggestions: lists all the suggested
improvements for the problems listed in the previous
chapter

34. Don’t bash!
Never bash the vendor who implemented the system
Just list the problems neutrally
You’ll be on the receiving end at some point and you’ll
appreciate the auditor to understand that there are different
circumstances in which Drupal systems are made - some
harder than others
Auditing is a gentleman’s game
We’re a small community of professionals and there’s no
need to sell by bashing others

35. TIP #6
Get a
reference -
if you can

36. Any references?
The most problematic part in selling Drupal audits is to
get the proper public references to be credible
1/20 audits I’ve done has given a public reference
Auditing is a subtle matter and so is the business of
selling them
The NDAs involved might have steep damage clauses
Some are so bad that small Drupal shops might
have to get insured or pass the case

37. Selling audits
When your customer is changing vendors, from
someone to you, you should try and sell an audit
It’s for your own security - you never know what
you’re getting into
Same goes for taking an existing site into support,
always demand to make an audit as a part of the
support deal

38. Selling audits
Never promise you’ll find anything wrong in an audit -
you don’t know that
Never promise you’ll find everything that’s wrong with
the system during an audit - nobody can guarantee
that
I can only guarantee you’ll miss something

39. A quick recap

40. Recap
Get the source code, you need it, all of it
Get the configuration or get access to production
Understand the architecture
Optimize code reading, read only code that matters
Remember to test the performance
Be a gentleman
Try to get a public reference

41. Thank you!
Questions?