Auditing Drupal Sites - DrupalCamp Baltics 2013

2,811 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,811
On SlideShare
0
From Embeds
0
Number of Embeds
348
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Auditing Drupal Sites - DrupalCamp Baltics 2013

  1. 1. Auditing Drupal sites Kalle Varisvirta Technology Director Exove @kvirta
  2. 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. 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. 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. 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. 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. 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. 8. How it’s done
  9. 9. TIP #1 You always need the source code
  10. 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. 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. 12. TIP #2 You must understand the architecture
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. TIP #3 It’s not just the code
  23. 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. 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. 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. 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. 27. Drupal configuration SEO configurations, that’s easily forgotten Cleanup for automatic imports or other automatically growing data Multisite configurations Language configurations etc...
  28. 28. TIP #4 A quick benchmark never hurt anyone
  29. 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. 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. 31. TIP #5 Auditing is a gentleman’s game
  32. 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. 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. 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. 35. TIP #6 Get a reference - if you can
  36. 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. 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. 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. 39. A quick recap
  40. 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. 41. Thank you! Questions?

×