Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Aug 30 2018
Aug 30

Pelo Fitness spinning class

Pelo Fitness spinning class

One of the best things about Drupal is its security. When tens of thousands of developers work collectively on an open source project, they find all the holes and gaps, and strive to fix them. When one is found, patches go out immediately to keep sites safe and secure. But a site is only secure if those patches are applied when they are released.

Pelo Fitness is a Marin County-based community dedicated to a culture of fitness. They offer cycling, strength, yoga & nutrition programs customized to an individual’s needs and fitness level. Whether someone is a competitive athlete, a busy executive or a soccer mom (or perhaps all three), their programs are designed to build strength and endurance, burn calories and boost energy.

Yet their site was weak since they hadn’t applied a few major Drupal security updates. There was a concern that the site could be hacked and jeopardize client information. Pelo Fitness customers use the site to purchase class credits and reserve bikes for upcoming classes, requiring users to log in and enter personal information.

Want to keep your site secure? Contact us to get started. 

The solution

Kanopi performed all the security updates to get the Pelo Fitness on the latest version of Drupal. All out of date modules were updated, and the site was scanned for suspicious folders and code; anything that looked suspect was fixed. Care was taken not to push code during high traffic times when reservations were being made, so code was pushed live during specific break times that would allow for the least disruption. Lastly the site was also moved over to Pantheon for managed hosting.

Due to the Drupal support provided by Kanopi, the Pelo Fitness website is now protected and secure. Inspired to make all their systems stronger, Pelo Fitness also switched to a different email system as well so all their tech solutions were more up to date.

How to keep your site secure

Websites are living organisms in their way, and need constant care and feeding. It’s imperative to always apply critical security patches when they come out so your users information (and your own) is kept secure at all times. There are a few simple things that you can do on your Drupal site to minimize your chances of being hacked.

  • Stay up to date! Just like Pelo Fitness, make sure you pay attention to security updates for both Drupal core and your contributed modules. Security releases always happen on Wednesdays so it’s easy to keep an eye out for them. To stay up to date, you can subscribe via email or RSS on Drupal.org or follow @drupalsecurity on Twitter.
  • Enable two-factor authentication on your site. It’s a few seconds of pain for an exponential increase in security. This is easily one of the best ways to increase the security of your site. And besides, it helps you makes sure you always know where your phone is. The TFA module provides a pluggable architecture for using the authentication platform of your choice, and Google Authenticator integration is available already as part of their basic functionality.
  • Require strong passwords. Your site is only as secure as the people who log into it. If everyone uses their pet’s name as their password, you can be in trouble even if your code base is “bulletproof” (nothing ever is). The Password Policy module sets the gold standard for traditional password strength requirements, or you can check out the Password Strength module if XKCD-style entropy is more your thing.
  • Make sure you’re running over a secured connection. If you don’t already have an SSL (TLS, technically, but that’s another story) certificate on your website, now is the time! Not sure? If your site loads using http:// instead of https://, then you don’t have one. An SSL certificate protects your users’ activities on the site (both site visitors and administrators) from being intercepted by potential hackers.
  • Encrypt sensitive information. If the unthinkable happens and someone gets hold of your data, encryption is the next line of defense. If you’re storing personally identifying information (PII) like email addresses, you can encrypt that data from the field level on up to the whole database. The Encrypt module serves as the foundation for this functionality; check out the module page and you can build up from there.
  • Don’t let administrators use PHP in your content. Seriously. The PHP filter module can get the job done quickly, but it’s incredibly dangerous to the security of your site. Think seriously about including JavaScript this way, too. If your staff can do it, so can a hacker.
  • Think about your infrastructure. The more sites you run on a single server, the less secure it is. And if Drupal is up to date, but your server operating system and software isn’t, you still have problems. Use web application and IP firewalls to take your security even further. 

Contact us at Kanopi if you need help keeping your site secure.

May 01 2018
May 01

When coming up with a security plan for your Drupal website, or any website for that matter, you need to take several key factors into account. These key factors include your server host, server configuration, and authorized users. Typically, the weakest link in that chain is how your authorized users access the server, so first we want to secure access to allow your admins and developers in, but keep hackers out.

Hosting Provider

Choosing your hosting provider is one of the most important decisions to make when it comes to site security. Your server is your first line of defense. Not all hosts have the options that you need to implement best practices for securing the server itself, let alone websites or other services that will be running on it too. 

At Zivtech, we use VPS servers for some hosting solutions for our clients, but we also use specialized hosting solutions such as Pantheon and Acquia when it makes sense. Taking the time to figure out which services your site(s) needs prior to moving to a host will save time later; you won’t need to move to another when you realize they don’t provide the services you really need. It’s the concept of “measure twice and cut once.”

Authorized Users

Many shared hosting solutions are set up with cPanel, which typically gives users FTP access to their web server environment by default. FTP is not encrypted like communications over SSH, so configuring sFTP is recommended if that’s all your host allows. 

The most secure way to connect to your server is through SSH, which is encrypted from end to end. Most VPS hosting companies give users access to their server through SSH by default, unless you install cPanel or other tools later. When using SSH, it’s much more secure to connect using an SSH key to authenticate with the server instead of a password. Typically, VPS hosts give you access to the root user to start with, so we need to stop authentication with that user as soon as possible.

Forcing SSH key authentication and configuring an authorized_keys file for each authorized user on the server is the best way to keep your server locked down from unauthorized access by malicious users. 

Get started by generating an SSH keypair on your local machine. I’m a security geek, so I use 4096-bit keys at this point for added security, but you can also use 2048-bit keys and still be secure at this point.

Below is an example of how you can generate an SSH key if you don’t have one already. The output files will be written to ~/.ssh. Without changing their name, they’ll be ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. Let’s go ahead and generate our key for our root user now.

ssh-keygen -t rsa -b 4096

After generating your SSH keypair, you’ll want to copy the contents of the ~/.ssh/id_rsa.pub file, as that’s the SSH public key we will be adding to that authorized user’s authorized_keys file. It’s okay to pass this key around in emails, chat programs, and other unencrypted methods of communication; it’s the public key, which can and should be seen by others. The ~/.ssh/id_rsa file, on the other hand, is the private key, which should never be shared through unencrypted methods, and typically should not be seen by anyone but the person who owns it.

Server Configuration 

File Permissions

File permissions are a huge hole for hackers to gain access if they’re not configured properly. Hosting platforms like Acquia and Pantheon typically handle all these permissions, so there isn’t much to worry about in those environments. 

Those running on their on VPS will want to ensure they have the permission for their Drupal codebase, Public Files, and Private Files directories locked down. I’m not going to get into the specifics of file permissions in this post, but there are some great resources on Drupal.org on how to lock down your site’s files.

There are also some great modules out there to help facilitate secure files on your Drupal site. The File permissions module uses Drush to handle setting your site’s permissions, which could be helpful for those not comfortable with command line. The Security Review module allows you to take a look at various security related settings on your site including file permissions, so that is something I highly recommend running every so often on your sites to make sure everything is still locked down.

Apr 03 2018
Apr 03

In part one of this post, I went over how Drupal Security Advisories, SSL/TLS certificates, and thorough user account security help lay the foundation for keeping your Drupal site secure. In part two, we’ll take a look at user roles and permissions, input filters and text formats, and third party libraries.

User Roles and Permissions

To keep your site secure, always make sure that your user roles and permissions are configured properly. Depending on the modules installed and third party integrations, there could be additional permissions and/or roles to configure to ensure the site is still secure after installing a particular module. It’s important to read the full module README and/or module documentation to verify that all configuration options and permissions have been set up securely. In many cases, modules with very important security related permissions will either set them to a sane default configuration, or put up a notice on the modules page within the admin UI. Some will do both. Some will do neither, so that’s why you need to be aware. 

For each module you enable, there can be optional or required permissions that need to be configured. This is one of the easiest things to overlook as a Drupal beginner, so keep an eye on which modules you’re enabling, and if you have permissions set for all your roles before launching the site. 

User 1, the superadmin account, has full access to a Drupal site without needing any additional roles or permissions assigned, so testing with that user is not the best. Create some test users within each role and test how the site works logged in and logged out to be certain that your roles and permissions are configured properly. You should only grant your most trusted admins access to the User 1 account. It’s also a great idea to rename the User 1 username from admin to something custom to avoid easily guessing or enumerating the superadmin username.

Obscurity is not security, but in some cases it does help to further secure the User 1 and other admin accounts on the site when using other security best practices. Disabling the User 1 user completely through MySQL is a more heavy-handed approach to locking down the superadmin user. 

There are also contrib modules that help facilitate additional obscurity on top of your user security, such as Rename Admin Paths and Username Enumeration Prevention. These modules can help keep potential hackers, script kiddies, and bots guessing instead of providing them with easy to use information in their hacking attempts.

Input Filters and Text Formats

Input filters and text formats are a huge part of ensuring a Drupal site doesn’t get hacked. The wrong settings on an input filter or the text format for a text field, such as a comment field, can be an easy way in for potential hackers. 

Content editors should be able to add the content they need without compromising security. Certain input filters should be enabled in the text formats for every format to ensure that HTML can’t be malformed and that markup can’t be added to exploit the site. 

The most common of these exploits is a Cross Site Scripting attack, which ultimately tricks the database into allowing code submissions to the database in a malicious attack. These types of attacks can end up with a hacker taking over your whole server, or just your database, but this can be prevented with the proper text formats and WYSIWYG settings. Let’s take a look at some of the most important settings to configure to ensure your fields are sanitizing all their data properly before being submitted to the database. 

The HTML filter is probably the most important input filter provided by a text format. It allows for specific tags, and even specific attributes of a given tag, in the actual HTML. Without the HTML filter, your site is open season for hackers, script kiddies, and bots to muscle their way in through possible exploits. 

It’s important to ensure that embedded objects, such as <script> and <iframe> tags, are not allowed, or only allowed by trusted users. They can easily be used to run malicious code on a site from external locations. There’s also a newer filter available that disallows usage of <img> tag sources that are not hosted on the site by replacing them with a placeholder image. Be aware that when you create a new custom text format, no input filters are chosen by default. It is highly recommended to use the “Limit allowed HTML tags and correct faulty HTML” HTML filter as a minimum.

There are four text formats available in Drupal core out of the box; Basic HTML, Restricted HTML, Full HTML, and Plain Text. In general, you probably want to give most users Basic HTML, but you might want to give your content editors more control over the markup they can add. Adding an editor role to the Restricted HTML format with some customized settings may be a good idea for those users. 

Text formats

You want to give the least permissive text formats to untrusted users, so Plain Text is a great choice for comments on blog posts to avoid spam links and malicious markup that isn’t filtered properly. Text formats can also be associated with a WYSIWYG, so be sure to enable or disable that for roles you trust or don’t trust as much.

Note: Keep in mind that new text formats and WYSIWYG settings can create new permissions on the site, so be sure to review all roles and permissions again after getting these configured.

Third Party Libraries

One of Drupal’s strengths is how easy it is to integrate with third party JavaScript libraries through contributed themes and modules. The problem is that these third party libraries are not covered by the Drupal Security Team, so they don’t get their own security advisories like Drupal core and Drupal contrib projects do. 

There have been a few cases when very popular libraries like CKEditor have received a Public Service Announcement on the Drupal Security Advisories page. PSAs like these are not very common unless there is a major security advisory for a third party library, or possibly a major incoming security issue for Drupal core that developers should be ready for. This is something that’s often overlooked, even by seasoned Drupal developers.

The lack of a true security advisory built into Drupal for these third party libraries means that it is up to you and/or your team to ensure that any libraries you have installed are still secure. This typically means that you need to sign up for security alerts for that project, if they have them, or keep an eye on the project releases that are security releases. Again, there are times that you might get a warning from the Drupal Security Team in a PSA about a library’s upcoming security release, but don’t count on this as a reliable way to prevent an attack; it’s not the Drupal Security Team’s job to monitor every third party library out there. Luckily, many third party libraries are hosted on GitHub and have an easy to follow releases page, although some do not and require a bit more due diligence to follow the latest security releases. Wouldn’t it be great if every open source project had such an amazing security team like Drupal’s?

Conclusion

A comprehensive Drupal security plan usually requires team effort. There are plenty of options out there to ensure that every Drupal site can stay secure, so don’t leave your site out in the cold for hackers to compromise it, or, even worse, steal user information and post it publicly for other hackers to use. This has become a common trend with sites that are hacked, which creates a bad situation for both the company that was hacked as well as for the users who had their data stolen. 

If you don’t have the time or resources to keep your site secure, seek the help of a team of experts. Keep calm and stay secure out there, fellow Drupalers!
 

Mar 27 2018
Mar 27

There’s no foolproof way to get an unhackable Drupal site; there could always be an exploit that we don’t know about yet. But there are quite a few ways you can help reduce the risk of getting hacked. Let’s dive into some of the most common ways Drupal sites get hacked, and how to secure your site against these points of entry.

Drupal Security Advisories

One of the most common ways to get hacked is to fall behind on known Drupal Security Advisories. Keeping up to date on the latest advisories is ultimately your first line of defense. 

There are security advisories for both Drupal core and contributed projects with varying levels of security risk for the exploits found. You can sign up for the security email list to make things easier to keep track of. You can do this by logging into your Drupal.org account and editing your user profile. From there you can subscribe to the security newsletter on the newsletters tab. This list will email you soon after Drupal Security Advisories are released to the public, which helps quickly notify you or your team of possible exploits that need to be fixed. 

You can use the Update Status module in Drupal core to see which sites are affected by these advisories. Then add an email address to send Security Alerts to daily or weekly. The Update Status alerts have also notified us in a few cases when the email list was backed up and took longer than it normally would. 

Typically, Drupal core security advisories come out on the third Wednesday of the month unless it’s a highly critical update that needs to be patched sooner. Contrib project security advisories can come out on any given Wednesday. 

Drupal 8 has a new release schedule that schedules upcoming minor releases. It’s important to note that with a new Drupal 8 minor version release, the previous minor version becomes unsupported and no longer gets security advisories or updates. It will be important for development teams to plan for these updates moving forward with Drupal 8, as these updates are not typical to the release schedules of Drupal 6 or Drupal 7 core. 

The Drupal core release schedule for both Drupal 7.x and 8.x can be found on the Drupal core release cycle page on Drupal.org. The overview page outlines the upcoming Drupal 8 core releases and major project milestones. Get familiar with them if you don’t want to be blindsided by some updates you weren’t planning on doing that quarter.

Specialized Drupal hosting companies, such as Pantheon and Acquia, have started applying security updates upstream to your codebase, which can be merged with the click of a button in most cases, or even automatically with some additional configuration. This allows Drupal core security updates to be applied with less effort to sites that are hosted on their platforms. Drupal contrib is still up to you to support though. Other companies like Drop Guard and myDropWizard provide various service plans to keep your whole site up to date and not locked into a specific hosting platform. 

Whether you’re looking to do your Drupal security in-house, host on a specialized hosting service, or pay for a support service provider to handle it for you, Drupal Security Updates are by far the most important aspect of your Drupal site’s security. Instead of derailing this whole post about why Drupal Security Advisories are so important, Google “Drupalgeddon” if you are unfamiliar with the term, and you’ll quickly see why they’re at the top of my list.

Laptop

Use SSL/TLS for All the Things!

Unencrypted login forms are an easy way for hackers to gain access to a Drupal site. All websites, especially those that have any sort of authentication process, should be using SSL/TLS encryption by default by now. 

SSL/TLS encrypts the communications between a client browser and the server to ensure that all data being transferred back and forth is encrypted from end to end. This stops hackers and malicious users from eavesdropping on data that you’re sending or receiving from the web server. 

This encryption is extremely important for any sites that require authentication, such as Drupal or WordPress sites, as they both have administrative users that can potentially be hacked if the login form is not secured. It’s imperative that sites that handle financial information and other personal identification information always use SSL/TLS, otherwise that data should be considered compromised. You’ll know when your browser is in a secure SSL session; you’ll see various levels of validation, starting with a green lock saying “Secure” next to it and https:// at the start of the URL in your browser address bar. 

SSL cert

Sites that are not secured by SSL/TLS are vulnerable to malicious users being able to “listen in” on the unencrypted communications between the client browser and the web server through various methods. This information could be login credentials, personal identification information, or something like payment information, which should always be encrypted when sending electronically. 

Encrypting these communications with SSL/TLS stops this from happening unless you are involved in a “man-in-the-middle” attack, which involves spoofing the SSL certificate itself and posing as a real, secure site. It’s good practice to verify that the certificate in the browser is actually owned by the site by clicking the green lock and viewing the valid certificate information. 

Any site can get an SSL cert now through the Let’s Encrypt service, so cost or availability is no longer an excuse for running non-SSL websites. Pantheon’s hosting service even provides SSL certificates powered by Let’s Encrypt for all domains on your account as part of their hosting plans.

Extended Validation (EV) certificates provide additional information about the owner of the certificate directly in the address bar, such as the company name and/or the country the cert was issued for. Generally, you’ll see these Extended Validation (EV) certificates used by financial institutions or larger corporations, but they can be used by any website that fills out the information needed for the Extended Validation certificate. At the time of this writing, Let’s Encrypt does not support Extended Validation certificates or wildcard certificates, so there are still some cases that it is not fully applicable, but it’s a great, free service for non-EV and non-wildcard certs.

Drupal User Account Security

We now know that our communications between the browser and the server are encrypted through SSL/TLS, but do we know how secure our Drupal users’ passwords are? To keep your site secure, ensure that all users, especially your content editors and admins, are not your weakest link. There are multiple levels of user security we need to be aware of when setting up our Drupal website. We’ll take a look at these levels and make sure we have all our users connecting as securely as possible.

Let’s start by taking a look at our most common weakest link, the user password. While there is a nice password strength suggestion tool in Drupal core, there’s nothing in core to force users to use secure passwords out of the box. 

Secure locks

At Zivtech, we use the Password Policy contrib module on most Drupal site builds to ensure that all users have password requirements that make them more difficult to crack. We typically require several elements to the password, such as numbers, capitalization, and punctuation, to add to the complexity of each user’s password. This is important to ensure that privileged users and those with the ability to add content to the site do not have their accounts compromised by a weak password. 

Drupal does have some mechanisms built in that will throttle failed login attempts, but these reset over time and the process can be repeated unless additional steps are taken to block the IP. Ultimately, weak passwords can be an easy point of entry for skilled hackers.

Proper administrator and content editor training is also important to ensure that these users don’t unintentionally negate other steps that were taken to secure the site. This means that site administrators and content editors should be informed that sharing login credentials over insecure communications like email should never happen. Credentials shared across email and other unencrypted communications should be considered compromised as soon as you hit the send button. There are some great password managers out there (we use LastPass) that store encrypted credentials and even allow sharing of credentials securely between team members. Always use one of these tools instead. 

PSA: If you are still sending any passwords or login credentials over email, please stop before you cause a major security breach in your organization or a client’s!

Check back next week for part two! We’ll go over security for user roles and permissions, input filters and text formats, and third party libraries.
 

Mar 02 2018
Mar 02

Happy Friday Everyone! On the eve of the Drupal Drive-in, happening tomorrow in Charlotte North Carolina, we welcome Mark Shropshire to the show to talk about his favorite topic, Drupal Security!

Jan 18 2018
Jan 18
January 18th, 2018

What are Spectre and Meltdown?

Have you noticed your servers or desktops are running slower than usual? Spectre and Meltdown can affect most devices we use daily. Cloud servers, desktops, laptops, and mobile devices. For more details go to: https://meltdownattack.com/

How does this affect performance?

We finally have some answers to how this is going to affect us. After Pantheon patched their servers they released an article showing the 10-30% negative performance impact that servers are going to have. For the whole article visit: https://status.pantheon.io/incidents/x9dmhz368xfz

I can say that I personally have noticed my laptop’s CPU is running at much higher percentages than before the update for similar tasks.
Security patches are still being released for many operating systems, but traditional desktop OSs appear to have been covered now. If you haven’t already, make sure your OS is up to date. Don’t forget to update the OS on your phone.

Next Steps?

So what can we do in the Drupal world? First, you should follow up with your hosting provider and verify they have patched your servers. Then you need to find ways to counteract the performance loss. If you are interested in performance recommendations, Four Kitchens offers both frontend and backend performance audits.

As a quick win, if you haven’t already, upgrade to PHP7 which should give you a performance boost around 30-50% on PHP processes. Now that you are more informed about what Spectre and Meltdown are, help with the performance effort by volunteering or sponsoring a developer on January 27, 2018 and January 28, 2018 for the Drupal Global Sprint Weekend 2018, specifically on performance related issues: https://groups.drupal.org/node/517797

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Dec 22 2017
Dec 22

Website developers considering code.

Website developers considering code.

Now that you’ve considered your user experience, there are a number of possible technical fixes that might help resolve your website problems.

What version of Drupal or WordPress are you using?

  • WordPress 2, while old, may or may not require a rebuild. You might be able to get by with updating and refactoring.
  • If you’re using Drupal 7 or WordPress 3, a rebuild is likely not needed. 
  • However, if you are on Drupal 6, it is at the end of its life, which may make rebuilding more cost-effective and viable for the long term.

Does your site use a lot of custom code?

If so, what does that code do, and are you still using that functionality? Look for ways to streamline where possible.

Is your site’s code a nightmare?

Did you use a professional firm with a North American team? An offshore team? A freelance developer? Or an internal employee who no longer works at your company? It’s a good idea to get the code reviewed so that you can determine its quality and understand whether it will be easy to update or if you’d be better off starting from scratch. Contact Kanopi for a low-cost assessment.

Are you up to date with the latest security patches and updates?

Lapses can expose the site to hacks and backdoors. Often just updating your site and modules/plugins can solve many issues.

Want to learn more about how we can help you understand every aspect of your site and determine if you need to rebuild or update to help achieve your goals? Contact us to book a free 15-minute consultation. Click here to book a time.

Jul 25 2017
Jul 25

This is an example of anti-virus implementation with an Ubuntu server.

Our back office management solution allows users to upload files in various sections of the application for storage or file sharing. For this reason, checking of files for virus is an important advantage.

We use the ClamAV module integration from Drupal 8.

1) Install ClamAV on Ubuntu

Installation on Ubuntu server is straight forward.  However, it is better to install with clamav-daemon clamav-freshclam options for later settings

You can test with clamscan -r /home for instance

For further options you may refer to ClamAV website.

2) Install and set-up Drupal module

Module installation on Drupal 8 has no specific requirements.

As indicated on the module page, "Daemon mode" is preferred when executing the scan.

In the settings page (/admin/config/media/clamav), select Daemon mode (over Unix socket) in scan mechanism

You need to indicate the path for the socket pointing file; it can be found in the configuration file  : /etc/clamav/clamd.conf.

Input the file path into next setting:

3) Test

When uploading a file on the server via any upload interface, the file is scanned and validated. Scanning process is logged:

The Eicar test virus file is filtered when uploaded:

If you have implemented ClamAV with Drupal and have further comments, please feel free input your own.

Thank you.

December 2016 – Scrutinizing Your Tests

Dec 01 2016
Dec 01
Aug 10 2016
Aug 10

So your site has been hacked ? Or more likely you wonder what to do when it eventually happens : the video for my "Life after the hack" is now available. From initial diagnosis to return online, with a healthy dose of forensics along the way. [embedded content]

The slides are also available for easier access, but of course absent the extra speaker comments :

Initially designed for the Drupalcon Dublin audience, it was given earlier at the DevDays Milan in june, so you may have missed it, due to the smaller audience at DevDays.

Jul 13 2016
Jul 13

The Drupal security team published a PSA to warn about upcoming security advisories. I shared my advice and predicted attacks within the hour after the security advisories are published. The security advisories are now published. Here is my followup.

I applaud the Drupal Security Team for warning about the highly critical updates. However the public service announcement (PSA) left the impression that this event was going to be much more serious than it was. Such a PSA would have been perfectly appropriate for SA-CORE-2014-005 "Drupalgeddon". But the only PSA there was in hindsight.

I guess it is resonable for the Drupal Security Team to be over cautious, especially given the lessons learned from Drupalgeddon fallout. And of course, such decisions and criticism is much easier with hindsight.

But now I am concerned how the Drupal Security Team can realistically raise the level further there is another vulnerability that is as serious as Drupalgeddon. Even if they raise the alert level using language in the PSA, will people still believe them? It reminds me of the boy who cried wolf.

Of course serious vulnerabilities like these are rare events in Drupal, so there is not yet a standard to compare alert levels to.

Jul 12 2016
Jul 12

Just arrived here? Read my followup first.

Original post

The Drupal security team announced multiple highly critical updates to Drupal contrib modules in PSA-2016-001. Expect attacks within less than one hour from the announcement; 18 hours from the time this article is published. This is probably going to be Drupalgeddon all over again.

My advice

If you are prepared, you will save yourself a lot of time. If you are late or too slow, you will probably find yourself with a lot more work, e.g. the rescue workflow for Drupalgeddon 1.

Today

Don't skimp on the first two. And do at least one of "3. Update a contrib module" or "4. Learn how to apply patches". Which one you choose depends on your skills and how out of date contrib modules are on your Drupal websites. Ideally, do both steps 3 & 4; You might find one of them is significantly challenging for you.

  1. Backup your Drupal 7 websites; Database, code & files directory
  2. Plan to be online at 1600 Wednesday 13 July 2016 UTC. In other timezones:
    America/Los_Angeles: 0900 Wednesday 13 Jul
    America/New_York: 1200 Wednesday 13 Jul
    Europe/London: 1700 Wednesday 13 Jul
    Europe/Paris: 1800 Wednesday 13 Jul
    Australia/Sydney: 0200 Thursday 14 Jul
    Pacific/Auckland: 0400 Thursday 14 Jul
  3. Update a contrib module on each of your Drupal 7 website(s) to make sure there will be no problems and you know how to do it. Do it manually by downloading the module from Drupal.org. The update server that Drush and Drupal use might be delayed, overloaded or under attack.
  4. Learn how to apply patches:
    1. Choose any popular module that your website uses, e.g. Views
    2. Navigate to the module's issue queue
    3. Filter for "Reviewed & tested by the community"
    4. Filter for the version of the module your website uses
    5. E.g. Views 7.3 RTBC issues
    6. Open any issue
    7. Download any .patch file
    8. Apply it using Drupal's documentation, which boils down to something like:
      1. cd sites/all/modules/views/
      2. patch -p1 < ~/Downloads/views-fix_hide_rewriting_if_empty-1428256-21.patch
      3. Test the patched module still works
  5. Restore your website from the backup into a new environment to make sure your backup is complete, you have sufficient access and you know how to do it. If you are on time and fast, this won't become necessary. But just in case...
  6. Subscribe to Drupal security email announcements: Log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the "Edit » My newsletters" tab.
  7. Consider taking servers that host highly sensitive data offline if your Drupal website can reach them. Drupal's maintenance mode may not be sufficient protection.
  8. If you can move to a Drupal-tailored web host easily, do so. They often offer additional protection while you work on applying updates. I usually recommend Pantheon.
  9. Take stock of any modifications (patches) to Drupal core and contrib modules. The Hacked! module automates most of this.
  10. Clean up and/or take stock of any unusual files in your website. A version control system like git makes this easy.
  11. Use the Security Review module to check if you have configured your Drupal website securely.
  12. Backup your website again if you made changes since the last backup.
  13. Subscribe to my blog;
    • I will post any important or relevant updates, more aggressively than what the Drupal Security Team is able to
    • Submit your email address in the right sidebar.
    • You can unsubscribe anytime (I won't be offended)

At T minus 1-hour

At 1500 Wednesday 13 July 2016 UTC, an hour before the scheduled time;

Do what you need to do to have the next few hours free from distractions; I.e. eat, use the bathroom, get comfortable.

At 1600 Wednesday 13 July 2016 UTC

  1. Look for contrib security advisories on Drupal.org.
  2. For each advisory that is published, check if your website(s) use the module. If yes, update it.
  3. Check you are recieving security advisory emails. Sometimes the highly critical updates require followup.

Drupal 6

The Drupal security team no longer supports Drupal 6. So we don't yet know if it is vulnerable or if there will be a patch. All of the above applies and you should do it, but if Drupal 6 is vulnerable patches or updates will probably be provided by the Drupal 6 long term support (LTS) programme.

Worst case, be prepared to roll-back to your backup from before the announcement.

Consider also;

  1. Accellerating your plans to upgrade to Drupal 7 or 8
  2. Taking your server or website offline
  3. Archiving it as a static HTML website (no PHP)
  4. Maintenance mode or locked-down permissions to be read-only is better than nothing, but may not offer any protection

Will I be affected?

The Drupal security team have added that the affected contrib modules are used on between 1,000 and 10,000 sites. That limits the affected modules to those ranked 522 to 2180; Just 1680 of the most popular 2000 Drupal contrib modules. Some Drupal websites, especially simple ones, will be lucky in that they won't be using an affected contrib module. But don't count on luck.

May 18 2016
May 18
teaser image for blog post

In this blog post I'll discuss some methods of ensuring that your software is kept up to date, and some recent examples of why you should consider security to be among your top priorities instead of viewing it as an inconvenience or hassle.

Critics often attack the stability and security of Open Source due to the frequent releases and updates as projects evolve through constant contributions to their code from the community. They claim that open source requires too many patches to stay secure, and too much maintenance as a result.

This is easily countered with the explanation that by having so many individuals working with the source code of these projects, and so many eyes on them, potential vulnerabilities and bugs are uncovered much faster than with programs built on proprietary code. It is difficult for maintainers to ignore or delay the release of updates and patches with so much public pressure and visibility, and this should be seen as a positive thing.

The reality is that achieving a secure open source infrastructure and application environment requires much the same approach as with commercial software. The same principles apply, with only the implementation details differing. The most prominent difference is the transparency that exists with open source software.

Making Headlines

Open Source software often makes headlines when it is blamed for security breaches or data loss. The most recent high profile example would be the Mossack Fonseca “Panama Papers” breach, which was blamed on either WordPress or Drupal. It would be more accurate to blame the firm itself for having poor security practices, including severely outdated software throughout the company and a lack of even basic encryption.

Mossack Fonseca were using an outdated version of Drupal: 7.23. This version was released on 8 Aug 2013, almost 3 years ago as of the time of writing. That version has at least 25 known vulnerabilities. Several of these are incredibly serious, and were responsible for the infamous “Drupalgeddon” event which led to many sites being remotely exploited. Drupal.org warned users that “anyone running anything below version 7.32 within seven hours of its release should have assumed they’d been hacked”.

Protection by Automation

Probably the most effective way to keep your software updated is to automate and enforce the process. Don’t leave it in the hands of users or clients to apply or approve updates. The complexity of this will vary depending on what you need to update, and how, but it can often be as simple as enabling the built-in automatic updates that your software may already provide, or scheduling a daily command to apply any outstanding updates.

Once you've got it automated (the easy part) you will want to think about testing these changes before they hit production systems. Depending on the impact of the security exploits that you're patching, it may be more important to install updates even without complete testing; a broken site is often better than a vulnerable site! You may not have an automated way of testing every payment permutation on a large e-commerce site, for example, but that should not dissuade you from applying a critical update that exposes credit card data. Just be sure you aren't using this rationale as an excuse to avoid implementing automated testing.

The simple way

As a very common example of how simple the application of high priority updates can be, most Linux distributions will have a tried and tested method of automatically deploying security updates through their package management systems. For example, Ubuntu/Debian have the unattended-upgrades package, and Redhat-based systems have yum-cron. At the very least you will be able to schedule the system’s package manager to perform nightly updates yourself. This will cover the OS itself as well as any officially supported software that you have installed through the package manager. This means that you probably already have a reliable method of updating 95% of the open source software that you're using with minimal effort, and potentially any third-party software if you're installing from a compatible software repository. Consult the documentation for your Linux distro (or Google!) to find out how to enable this, and you can ensure that you are applying updates as soon as they are made available.

The complex way

For larger or more complex infrastructure where you may be using configuration management software (such as Ansible, Chef, or Puppet) to enforce state and install packages, you have more options. Config management software will allow you to apply updates to your test systems first, and report back on any immediate issues applying these updates. If a service fails to restart, a service does not respond on the expected port after the upgrade, or anything goes wrong, this should be enough to stop these changes reaching production until the situation is resolved. This is the same process that you should already be following for all config changes or package upgrades, so no special measures should be necessary.

The decision to make security updates a separate scheduled task, or to implement them directly in your config management process will depend on the implementation, and it would be impossible to cover every possible method here.

Risk Management

Automatically upgrading software packages on production systems is not without risks. Many of these can be mitigated with a good workflow for applying changes (of any kind) to your servers, and confidence can be added with automated testing.

Risks

  • You need to have backups of your configuration files, or be enforcing them with config management software. You may lose custom configuration files if they are not flagged correctly in the package, or the package manager does not behave how you expect when updating the software.
  • Changes to base packages like openssl, the kernel, or system libraries can have an unexpected effect on many other packages.
  • There may be bugs or regressions in the new version. Performance may be degraded.
  • Automatic updates may not complete the entire process needed to make the system secure. For example, a kernel update will generally require a reboot, or multiple services may need to be restarted. If this does not happen as part of the process, you may still be running unsafe versions of the software despite installing upgrades.

Reasons to apply updates automatically

  • The server is not critical and occasional unplanned outages are acceptable.
  • You are unlikely to apply updates manually to this server.
  • You have a way to recover the machine if remote access via SSH becomes unavailable.
  • You have full backups of any data on the machine, or no important data is stored on it.

Reasons to NOT apply updates automatically

  • The server provides a critical service and has no failover in place, and you cannot risk unplanned outages.
  • You have custom software installed manually, or complex version dependencies that may be broken during upgrades. This includes custom kernels or kernel modules.
  • You need to follow a strict change control process on this environment.

Reboot Often

Most update systems will also be able to automatically reboot for you if this is required (such as a kernel update), and you should not be afraid of this or delay it unless you're running a critical system. If you are running a critical system, you should already have a method of hot-patching the affected systems, performing rolling/staggered reboots behind a load-balancer, or some other cloud wizardry that does not interrupt service.

Decide on a maintenance window and schedule your update system to use it whenever a reboot is required. Have monitoring in place to alert you in the event of failures, and schedule reboots within business hours wherever possible.

Drupal and Other Web-based Applications

Most web-based CMS software such as Drupal and Wordpress offer automated updates, or at least notifications. Drupal security updates for both core and contributed modules can be applied by Drush, which can in turn be scheduled easily using cron or a task-runner like Jenkins. This may not be a solution if you follow anything but the most basic of deployment workflows and/or rely on a version control system such as Git for your development (which is where these updates should go, not direct to the web server). Having your production site automatically update itself will mean that it no longer matches what you deployed, nor what is in your version control repository, and it will be bypassing any CI/testing that you have in place. It is still an option worth considering if you lack all of these things or just want to guarantee that your public-facing site is getting patches as a priority over all else.

You could make this approach work by serving the Git repo as the document root, updating Drupal automatically (using Drush in 'security only' upgrade mode on cron), then committing those changes (which should not conflict with your custom code/modules) back to the repo. Not ideal, but better than having exploitable security holes on your live servers.

If your Linux distribution (or the CMS maintainers themselves) provide the web-based software as a package, and security updates are applied to it regularly, you may even consider using their version of the application. You can treat Drupal as just another piece of software in the stack, and the only thing that you're committing to version control and deploying to servers is any custom modules to be layered on top of the (presumably) secure version provided as part of the OS.

Some options that may fit better into the common CI/Git workflows might be:

  • Detect, apply, and test security patches off-site on a dedicated server or container. If successful, commit them back to version control to your dev/integration branch.
  • Check for security updates as part of your CI system. Apply, test and merge any updates into your integration branch.

Third-party Drupal Modules (contrib)

Due to the nature of contrib Drupal modules (ie, those provided by the community) it can be difficult to update them without also bringing in other changes, such as new features (and bugs!) that the author may have introduced since the version you are currently running. Best practice would be to try to keep all of the contrib that the site uses up to date where possible, and to treat this with the same care and testing as you would updates to Drupal itself. Contrib modules often receive important bug fixes and performance improvements that you may be missing out on if you only ever update in the event of a security announcements.

Summary

  • Ensure that updates are coming from a trusted and secure (SSL) source, such as your Linux distribution's packaging repositories or the official Git repositories for your software.
  • If you do not trust the security updates enough to apply them automatically, you should probably not be using the software in the first place.
  • Ensure that you are alerted in the event of any failures in your automation.
  • Subscribe to relevant security mailing lists, RSS feeds, and user groups for your software.
  • Prove to yourself and your customers that your update method is reliable.
  • Do not allow your users, client, or boss to postpone or delay security updates without an incredibly good reason.

You are putting your faith in the maintainer's' ability to provide timely updates that will not break your systems when applied. This is a risk you will have to take if you automate the process, but it can be mitigated through automated or manual testing.

Leave It All To Somebody Else

If all this feels like too much responsibility and hard work then it’s something Ixis have many years of experience in. We have dedicated infrastructure and application support teams to keep your systems secure and updated. Get in touch to see how we can ensure you're secure now and in the future whilst enjoying the use and benefits of open source software.

Apr 18 2016
Apr 18

In our last post we talked about how the Drupal Community is supporting Drupal 6 after its end-of-life and what that means for your Drupal 6 site.  In this post we’ll get a bit more technical and talk about what exactly you need to do to keep your website up to date.

Step #1: Getting an accurate report of your site’s modules and themes

Ever since the Drupal 6 sunset date, your website’s report of Available Updates at /admin/reports/updates has been telling you that everything is unsupported and should be uninstalled.  That’s not very helpful :-)

Drupal 6 Update module report

So the first step is to get the myDropWizard module.  This is provided free (libre) to the Drupal Community by one of the Drupal LTS vendors. The main purpose of this module is to show whether a module is supported by the Drupal 6 Long-Term Support (LTS) vendors, so you’ll know if it’ll be getting security updates going forward.

Drupal 6 MyDropWizard report

Ahhh, that’s better.

Now you can continue to manage security updates for modules and themes just like you always have.  But there are some significant gotchas.

How problems are found and fixed

When vulnerabilities are found they will be posted as issues in the Drupal 6 LTS project.  Once the issue is  fixed, and if the module maintainer is still maintaining the D6 version, then the maintainer will simply release a new version, just like normal.  But if the maintainer is no longer maintaining it, then new releases are made on Github.  Drupal Core is no longer receiving any new commits on the 6.x branch,  so new releases will be made to the Pressflow project, also on Github.

How to obtain new versions

If new releases are scattered across Drupal.org and Github, the question becomes: How do we easily obtain new versions?  Assuming that you run security updates with Drush, then you can use the --update-backend=mydropwizard flag when calling any of Drush’s Project Management commands (pm-download, pm-refresh, pm-updatedstatus).  The MyDropWizard backend will automatically obtain the project from Github or Drupal.org.

New Drush

But this brings a new problem: The --update-backend flag only works with Drush 7 or later.  On a server that’s running Drupal 6, chances are high that it’s using Drush 6, and chances are also high that it’s using an old version of PHP (like 5.3.3 that is bundled with Debian/Ubuntu).  The old version of PHP means that you can’t upgrade to the latest Drush 7 (7.2.0).  But there’s a fix on the way for that.

Switching to Pressflow?

Since new releases are no longer made to Drupal Core, and only to Pressflow, this creates a bit of a dilemma for sites that are not running Pressflow.  In those cases it’s probably more cost effective to manually apply patches rather than move to Pressflow.  There’s a couple ways to be notified of these commits:

Add-on modules

The final tricky area that we’ve found is with modules that extend Update Status module. There’s two in particular that we use often: Update Exclude Unsupported, and Update Status Advanced Settings — neither of these will work anymore.  Instead you’ll need to implement hook_mydropwizard_status_alter().

/**
 * Implements hook_mydropwizard_status_alter().
 */
function mymodule_security_mydropwizard_status_alter($projects) {

  // Projects determined to be okay for this particular site.
  $projects_deemed_okay = array(
    // This is okay because of the finglewabble.
    'foo', 
    // This is okay because of hard-coded site configuration. 
    'bar',
  );
  foreach ($projects_deemed_okay as $module) {
    if (isset($projects[$module])) {
      $projects[$module]['status'] = 'deemed-okay';
      $projects[$module]['extra'][] = array(
        'class' => 'deemed-okay',
        'label' => t('Deemed okay'),
        'data' => t('This project was analyzed and determined to be acceptable to run on your site.'
      );
    }
  }
}

Conclusion

I’m sure there will be a few more hiccups along the way, but this should get you started.

Image by: Henri Bergius

Apr 08 2016
Apr 08

Those of you who still have a Drupal 6 site are by now aware that you need to do something with it since this version is no longer supported.  Your options in short are:

  • Upgrade to Drupal 7
  • Upgrade to Drupal 8
  • Choose one of several options to limit your vulnerability (e.g. convert the site into a static HTML website, or close logins to all but a handful of trusted people and harden the security of the login form)

But that’s a big decision.  What do you do until you’ve decided which path to choose?  Now that Drupal 6 is past its sunset date, is your site suddenly vulnerable to having its data stolen and being turned into a spam factory?

The short answer

As long as you have someone keeping an eye on the security of your site, you’re just fine.  Take some time to make your decision — just don’t wait too long.

Interested in our Drupal security services?  Contact us to find out more.

The long answer

The long answer is a bit more nuanced.  When the Drupal 6 end-of-life was approaching, the Drupal Security Team asked for vendors to apply to become recognized as official Drupal 6 Long Term Service Vendors.  These LTS vendors have clients running Drupal 6 websites.  As security vulnerabilities are found and fixed in Drupal 7 (and Drupal 7 modules) the vendors are committing to make those same fixes to the Drupal 6 versions, but only for the modules that their clients are using.  

That exception has significance for other Drupal 6 sites and it all boils down to the question of:

How much security is enough?  

Low risk websites

Many (most?) websites only need to be worried about automated security attacks: Villains and mischief makers will try to attack every website on the Internet using every known vulnerability.  A tiny fraction  of the time they’ll be successful and turn a website into a spam factory, or virus spreader.  If they do their work well the site owner won’t even notice.  There’s a very low success rate, but there’s a billion websites out there.  You do the math.

High risk websites

Other websites have to worry about someone trying to actively hack their website.  There’s usually three possible reasons for this:

  • Your website has information worth stealing — Maybe your site has an e-commerce component, or a database of hundreds of thousands of membership records (with full names and e-mail addresses).
  • Your website has a lot of visitors — This is really just a subset of the first point.  If someone could infect all those visitors with a virus they could make a lot of money.
  • Someone wants to shut your website down — Maybe your organization has a political bent that some people strongly disagree with.

So what does this mean for my Drupal 6 site?

If your site is in the low risk category, then nefarious individuals will be using the vulnerabilities fixed by the LTS vendors in their automated attacks.  As long as your site continues to be updated with these fixes you are probably fine.  

There is still some risk if:

  • your site runs a module that the LTS vendors do not support,
  • and a vulnerability is found in the Drupal 7 version of that module,
  • and that vulnerability exists identically on the Drupal 6 version.

That’s possibly enough “ifs” to keep the risk at an acceptable level.

Also be aware that this support won’t last forever.  As more sites get off of Drupal 6, the LTS Vendors will have fewer clients paying for those services, and the number of supported modules will diminish.  Eventually your Drupal 6 site could be the last one standing with no one looking out for it.  How long this support is “good enough” is impossible to say.

If your site is in the high risk category, then you need to take a more active role in preventing successful attacks.  You could:

  • Move the information worth stealing somewhere else.
  • Move your site off of Drupal 6 faster.
  • Become a client of a Drupal 6 LTS Vendor to ensure that all of your modules are supported (not just the ones that other LTS Vendor clients happen to be using).

If you need help figuring out what you need, just contact us.

Photo by Billie Grace Ward

April 2016 – Off the Island: Drupal

Apr 01 2016
Apr 01

Drupal 8 Entity Validation and Typed Data Explained

Mar 29 2016
Mar 29
Oct 24 2015
DA
Oct 24

Configuring Drupal with a remote database is possible and in some cases recommended.

Our EK management tools application is a particularly good case where this setup is very helpful. EK manages Drupal system configuration database and content database separately. In other words, the installed database from Drupal 8 and the database where all EK custom modules save their data are different.

This configuration brings few benefits:

  • security: is system data are compromised (i.e. user login information) the content data which is of high value for the organization have less chances to be affected. This also reinforced as the 2 databases are physically and geographically separated;
  • backup management; you can have a better backup management cycle with separated databases;
  • updates management; when updating Drupal, having a configuration database distinct from where the content is store will make it more efficient and faster;
  • as a vendor, you can keep control on the service by reserving control on the system configuration without having any interference on the customer content and information;

 The diagram below shows how we can implement an EK installation with remote database:

remote Drupal database setup

One important point is to keep the connection between the main server (this server can be the customer server for instance) and the configuration server secured with encrypted communication (ssl).

A good solution (we are experimenting now) comes with Amazon RDS service. The service can supply on demand access to mysql databases or any other database engine) and provide the necessary encryption keys.

Oct 07 2015
Oct 07

This morning, during my usual scan of Feedly/Twitter/Reddit I read Secure the data of visitors on your Drupal website better. The post shows you how to use the Field encryption module.

The Field encryption module ensures that the values stored in the Drupal database are encrypted. When the database ends up in the wrong hands, then nobody can read the data since this module has encrypted it. This way, you are prepared for a worse case scenario.

It all seems straight forward enough, but I suspected it wouldn’t be so simple and in fact doesn’t look as secure as purported. My main concern was with the 3 options presented for storing the private key used to encrypt data. So I asked on Twitter:

How secure is this if Drupal needs to read the key? http://t.co/q8wzlLy2dM /cc @enygma @Awnage @ircmaxell

— Oscar Merida (@omerida) October 7, 2015

Now, this post isn’t meant to denigrate the work of that project or to completely discount the advice on openlucius.com. Let’s see why some of the ways to store the key are problematic.

@enygma @omerida @Awnage the key is stored in the db? o_O

— Anthony Ferrara (@ircmaxell) October 7, 2015

The first option is to store the key in the database, and at least the article recommends against selecting that. If your key is in the database, and a malicious attacker manages to steal your database or find some way to read it’s contents via SQL Injection, they will have your key. With the key, nothing will stop them from unencrypting your data.

The second option is to specify it as a variable in settings.php. The key is a little harder to get but is only a variable_get('encrypt_drupal_variable_key') call away. Since settings.php is in the public web root, misconfiguring PHP or having PHP files show the source code will leak your key too. Finally, if you’re committing your settings files to git or SVN (hint: you shouldn’t be), anyone with access to your repository will also have your key.

@omerida imho they should only offer the last option. @ircmaxell @Awnage

— Chris Cornutt (@enygma) October 7, 2015

The final option, to use a File should be the recommended way to specify the key. Ideally, the file is somewhere outside of your web root and, again, not in your code repository.

Only in option 1 is your key vulnerable to SQL injection attack. For the other 2 options, an attacker would have to gain access to your code to get your key. Given how Drupal 7 stores routes in the database, all that takes is and SQLi vulnerability in another module or core itself and someone could install a back door or shell on your site.

@omerida @enygma @Awnage depends on a lot of factors. If done correctly (haven't looked yet), could make SQLi virtually useless by itself.

— Anthony Ferrara (@ircmaxell) October 7, 2015

No matter how you store it, if you have the PHP module enabled, anyone who can build a view or execute PHP code from the Drupal UI can retrieve your key. There’s also a temptation to share the key across development, testing, and production environments so that your database snapshots are portable between them all.

Others brought up issues on as well. The original module author added a comment highlighting that the Field Encryption module is still marked as Beta, which was released in 2013.Also, there are better key management solutions for Drupal.

@enygma @ircmaxell @omerida @Awnage the default options are bad, bad, and bad. Modules like townsec_key & key attempt to provide real KMS

— Cash Williams (@cashwilliams) October 7, 2015

Also, there are better algorithms for encryption than those in the module.

@ircmaxell @enygma @omerida @Awnage It's worse than that, the suggested plugin Encrypt, uses ECB & mcrypt with no authentication. *shrug*

— Ashley Pinner (@NeoThermic) October 7, 2015

Security is a Continual Process

This illustrates that security is a continual process, with a lot of considerations to take into account. It’s not as easy as installing a single module or ticking a box on a check list. If you’re storing really sensitive user data, ask yourself if you really need it. If this data is credit card information—get to know what it takes to be PCI compliant. Then ask if you aren’t better off using a payment processor instead. But please, don’t be lulled into a false sense of security after adding a single component.

Jul 15 2015
Jul 15

Regardless of industry, staff size, and budget, many of today’s organizations have one thing in common: they’re demanding the best content management systems (CMS) to build their websites on. With requirement lists that can range from 10 to 100 features, an already short list of “best CMS options” shrinks even further once “user-friendly”, “rapidly-deployable”, and “cost-effective” are added to the list.

There is one CMS, though, that not only meets the core criteria of ease-of-use, reasonable pricing, and flexibility, but a long list of other valuable features, too: Drupal.

With Drupal, both developers and non-developer admins can deploy a long list of robust functionalities right out-of-the-box. This powerful, open source CMS allows for easy content creation and editing, as well as seamless integration with numerous 3rd party platforms (including social media and e-commerce). Drupal is highly scalable, cloud-friendly, and highly intuitive. Did we mention it’s effectively-priced, too?

In our “Why Drupal?” 3-part series, we’ll highlight some features (many which you know you need, and others which you may not have even considered) that make Drupal a clear front-runner in the CMS market.

For a personalized synopsis of how your organization’s site can be built on or migrated to Drupal with amazing results, grab a free ticket to Drupal GovCon 2015 where you can speak with one of our site migration experts for free, or contact us through our website.

_______________________________

SEO + Social Networking:

Unlike other content software, Drupal does not get in the way of SEO or social networking. By using a properly built theme–as well as add-on modules–a highly optimized site can be created. There are even modules that will provide an SEO checklist and monitor the site’s SEO performance. The Metatags module ensures continued support for the latest metatags used by various social networking sites when content is shared from Drupal.

SEO Search Engine Optimization, Ranking algorithm

E-Commerce:

Drupal Commerce is an excellent e-commerce platform that uses Drupal’s native information architecture features. One can easily add desired fields to products and orders without having to write any code. There are numerous add-on modules for reports, order workflows, shipping calculators, payment processors, and other commerce-based tools.

E-Commerce-SEO-–-How-to-Do-It-Right

Search:

Drupal’s native search functionality is strong. There is also a Search API module that allows site managers to build custom search widgets with layered search capabilities. Additionally, there are modules that enable integration of third-party search engines, such as Google Search Appliance and Apache Solr.

Third-Party Integration:

Drupal not only allows for the integration of search engines, but a long list of other tools, too. The Feeds module allows Drupal to consume structured data (for example, .xml and .json) from various sources. The consumed content can be manipulated and presented just like content that is created natively in Drupal. Content can also be exposed through a RESTful API using the Services module. The format and structure of the exposed content is also highly configurable, and requires no programming.

Taxonomy + Tagging:

Taxonomy and tagging are core Drupal features. The ability to create categories (dubbed “vocabularies” by Drupal) and then create unlimited terms within that vocabulary is connected to the platform’s robust information architecture. To make taxonomy even easier, Drupal even provides a drag-n-drop interface to organize the terms into a hierarchy, if needed. Content managers are able to use vocabularies for various functions, eliminating the need to replicate efforts. For example, a vocabulary could be used for both content tagging and making complex drop-down lists and user groups, or even building a menu structure.

YS43P

Workflows:

There are a few contributor modules that provide workflow functionality in Drupal. They all provide common functionality along with unique features for various use cases. The most popular options are Maestro and Workbench.

Security:

Drupal has a dedicated security team that is very quick to react to vulnerabilities that are found in Drupal core as well as contributed modules. If a security issue is found within a contrib module, the security team will notify the module maintainer and give them a deadline to fix it. If the module does not get fixed by the deadline, the security team will issue an advisory recommending that the module be disabled, and will also classify the module as unsupported.

Cloud, Scalability, and Performance:

Drupal’s architecture makes it incredibly “cloud friendly”. It is easy to create a Drupal site that can be setup to auto-scale (i.e., add more servers during peak traffic times and shut them down when not needed). Some modules integrate with cloud storage such as S3. Further, Drupal is built for caching. By default, Drupal caches content in the database for quick delivery; support for other caching mechanisms (such as Memcache) can be added to make the caching lightning fast.

cloud-computing

Multi-Site Deployments:

Drupal is architected to allow for multiple sites to share a single codebase. This feature is built-in and, unlike WordPress, it does not require any cumbersome add-ons. This can be a tremendous benefit for customers who want to have multiple sites that share similar functionality. There are few–if any–limitations to a multi-site configuration. Each site can have its own modules and themes that are completely separate from the customer’s other sites.

Want to know other amazing functionalities that Drupal has to offer? Stay tuned for the final installment of our 3-part “Why Drupal?” series!

Jul 01 2015
Jul 01

Earlier this year, we launched a new site for the ACLU. The project required a migration from Drupal 6, building a library of interchangeable page components, complex responsive theming, and serious attention to accessibility, security and privacy. In this post, I’ll highlight some of the security and privacy-related features we implemented.

Privacy

As an organization, the ACLU has a strong commitment to protecting individual privacy, and we needed to translate their passion to this issue to their own website. This meant meeting their high standards at a technical level.

The ACLU ensures that technical innovation doesn’t compromise individual privacy, and most of our work around user privacy involved ensuring that third-party services like Facebook and YouTube weren’t accessing user data without their consent.

Social sharing

Facebook “Like” buttons on the site offer a quick way for visitors to follow ACLU content on their Facebook feed. But even if you don’t click to “Like” a page, the tracking scripts behind them – coming straight from Facebook – log your behavior and make note of your visit there. That data can be used for targeted advertising, and the data itself is also a sellable product. Because these buttons are all over the web, Facebook can piece together quite a bit of your browsing history, without your knowledge.

To prevent this from happening to ACLU site visitors, we hooked up a jQuery plugin called Social Share Privacy to make sure that visitors who want to “Like” ACLU can do so while others can avoid Facebook’s data tracking. The plugin initially loads a disabled (greyed-out) button for the Facebook “Like”. If the visitor wants to use the button, they click once to enable it, which then loads Facebook’s iframe, and then a second time to “Like” the page.

ACLU.org Facebook button

The Social Share Privacy jQuery plugin keeps Facebook from tracking you without your consent.

A nice side effect is a faster page load for everyone since we don’t have to load content from Facebook on the initial page render.

Video playback

YouTube and other video sharing sites present a similar privacy problem – the scripts used to embed videos can also dig into visitor data without their consent.

MyTube video embed

A MyTube video embed on ACLU.org.

MyTube is a script that was written by the Electronic Frontier Foundation as a Drupal 5 module, then updated as a Drupal 6 module by students in the Ohio State University Open Source Club. For the ACLU site, we worked on porting the module to Drupal 7 and updating various parts of the code to work with updated APIs (both on the Drupal end and the video host end).

Similar to the Social Share Privacy plugin, MyTube initially loads a static thumbnail image from the embedded video, and to play the video, the visitor gives it an extra click, opting-in to run code from the third-party site.

If you’re interested in helping complete Drupal 7 version of the module, take a look at some of the patches our team submitted, and test them out!

Security

Due to the ACLU’s high profile and involvement with controversial topics, security was a major concern throughout the development process. While we can’t go into too much detail here (because, well, security), here are a few steps we took to keep the site safe.

  1. Scrubbed database back-ups. When developers copy down database instances for local development, sensitive information – such as user emails and passwords – are removed. This is made pretty easy using Drush sql-sync-pipe.
  2. Secure hosting on Pantheon with controlled development environments. In addition, though our development team can make code changes, only a handful of authorized ACLU web managers can actually deploy change to their live site. 
  3. The site runs entirely over SSL via HSTS headers
  4. The previous version of the site had various “action” tools where visitors could log in to sign petitions and send letters to their elected representatives. During the redesign this functionality was moved to a separate site, on a separate codebase, running on separate infrastructure. Any site that allows anonymous visitors to create accounts is, by definition, more susceptible to attack. By splitting into two sites, a successful exploit of one web property will not affect the other.
  5. All custom code was reviewed by multiple members of the Advomatic team, and Tag1 Consulting performed an additional security review, in which our codebase received excellent marks and a glowing recommendation.

When your organization champions a cause, all your activities should embody it, including your website. The ACLU takes these standards very seriously, and so do we. Take a look at some of our other projects to see how we worked with nonprofits on sites that reflect their values. 

You should also check out

Jun 10 2015
Jun 10

One of the things that makes Drupal great is its flexible user permission system. The out of the box permissions grid we are all familiar with covers most uses cases of controlling what users can and cannot do. It is also very easy for module developers to create new permissions and roles that restrict the logic they implement.

Drupal logo

Nevertheless, I have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible.

In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list. Article nodes will have a field where you can select users and only these users (or those who have full access) will be able to edit that particular node. You can find the module already in this git repository and you can install it on your site for a quick start. Do keep in mind that it has a dependency on the Entity Reference module as we will see in a minute.

I will keep the code comments to a minimum to save space but you can find them in the repository if you want. Basic knowledge of Drupal 7 is assumed in the remainder of this tutorial.

Scaffolding

We first need the editor_list.info file for our module to get us going:

name = Editor List
description = Module illustrating a custom solution for having multiple editors on a node.
core = 7.x
dependencies[] = entityreference

Next, we need our editor_list.module file where most of our business logic will be located. So go ahead and create it and we will populate it as we go on.

Finally, though not covered here, we can have an editor_list.install file where we can implement hook_install() and hook_update hooks to create fields and/or deploy configuration. In the repository, you’ll find that I provided an install hook that already creates an entity reference field called field_editors and attaches it to the Article content type. If you are following along but not using the code in the repository, you should go ahead and create the field manually through the UI. It’s a simple field that references User entities and allows for unlimited selections. Nothing major.

Node access

Going back to our .module file, it’s time to implement our access logic. First though, to make things as flexible and reusable as possible, let’s have a simple function that returns an array of node types to which we apply our access logic:

function editor_list_node_types() {
  return array('article');
}

Since we are only targeting articles, this will suffice. But we will use this function in multiple places so in case we need to target other types as well, we just have to update this array.

Next, let’s write another helpful function that returns all the user IDs set in the editors field of a given node. We will also use this in multiple places:

function editor_list_uids_from_list($node) {
  $users = field_get_items('node', $node, 'field_editors');

  $allowed_uids = array();
  if ($users) {
    $allowed_uids = array_map(function($user) {
      return $user['target_id'];
    }, $users);
  }

  return $allowed_uids;
}

I believe the function is quite self explanatory so I won’t go into details here. Instead, we can turn to our hook_node_access() implementation that gets called by Drupal whenever a user tries to do something with a node (view, edit or delete):

/**
 * Implements hook_node_access().
 */
function editor_list_node_access($node, $op, $account) {
  $node_types = editor_list_node_types();

  if ( ! is_object($node) || ! in_array($node->type, $node_types) || $op !== 'update') {
    return NODE_ACCESS_IGNORE;
  }

  $allowed_uids = editor_list_uids_from_list($node);

  if (empty($allowed_uids)) {
    return NODE_ACCESS_IGNORE;
  }

  if (in_array($account->uid, $allowed_uids)) {
    return NODE_ACCESS_ALLOW;
  }
}

So what’s happening here?

First, we use our previously declared helper function to get the list of node types we want to target, and we basically ignore the situation and return if the node type of the currently accessed node is not within our list or if the operation the user is attempting is not of the type “update”. Then we use our other helper function to check if there are any users in the editor list for this node and again ignore the situation if there aren’t. However, if there are, and our accessing user is among them, we return the NODE_ACCESS_ALLOW constant which basically gives the user access to perform the attempted operation. And that’s it.

You can check out the documentation for more information about how this hook works.

Let’s say you have admin users who can create and edit any type of content and regular authenticated users who cannot edit articles (apart from maybe the ones they created themselves). Adding one of these latter users to a node’s editor list would give them access to that particular node. And another great thing is that since this is all nicely integrated, contextual filters and tabs also take these dynamic permissions into account.

Field access

We now have a working module that does what I initially set out for it to do. But let’s say that your admin users are the only ones responsible for adding users to the editor lists. In other words, you are afraid that if your editors can edit their nodes and remove themselves from the list, they’ll get locked out of the node they are supposed to work on.

To account for this situation, we need to implement a field access check and remove the possibility that editors tamper with that field. Implementing hook_field_access should do the trick nicely. And if you are wondering, this hook is similar to hook_node_access() but is responsible for individual fields rather than the entire node (+ a couple of other small differences).

/**
 * Implements hook_field_access().
 */
function editor_list_field_access($op, $field, $entity_type, $entity, $account) {
  $node_types = editor_list_node_types();
  if ($entity_type === 'node' && is_object($entity) && in_array($entity->type, $node_types)) {
    return editor_list_control_field_access($op, $field, $entity_type, $entity, $account);
  }
}

And here we have it. There are a few more parameters because this hook gets called for all entities, not just nodes. But again, we check if the currently accessed node is one of those we defined earlier (and that the entity is in fact a node) and this time delegate to another function to keep things tidier:

function editor_list_control_field_access($op, $field, $entity_type, $entity, $account) {
  if ($op !== 'edit') {
    return;
  }

  $uids = editor_list_uids_from_list($entity);
  if (!in_array($account->uid, $uids)) {
    return;
  }

  $deny = array('field_editors');
  if (in_array($field['field_name'], $deny)) {
    return false;
  }
}}

Since we only care if the user is trying to update a particular field, we return nothing if this is not the case. Keep in mind that the op string here is edit and not update as it was in the other hook. This is just one of those Drupal quirks of inconsistency we all came to love so much. And like before, we ignore the situation if the current user is not part of the editor list.

Then, we define an array of field names we want to deny access to (in our case only one but we can add to it depending on the use case). Finally, we return false if the currently accessed field is part of our $deny array. Yet another difference here in that we have to return a boolean instead of a constant like we did before.

Now the editors in the list of a given node cannot remove themselves or add anybody else to the list. But then again, in some cases you may want this functionality and in others not. It’s up to you.

Tidying up

The last thing I am going to show you here relates to organization and maybe a bit of user experience. With our current implementation, the editor list field on the Article nodes is present somewhere on the form (wherever you dragged-and-dropped it when editing the field settings). However, wouldn’t it be nice if it were automatically part of the Authoring information group at the bottom of the page? Something like this:

Drupal 7 multiple editors per node

I think so. Let’s see how we can do that.

First, we need to implement hook_form_alter or one of its variations. I prefer the most targeted one to avoid unnecessary calls to it and a bunch of conditional checks:

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function editor_list_form_article_node_form_alter(&$form, &$form_state, $form_id) {
  $form['#after_build'][] = 'editor_list_node_form_after_build';
}

We went with the BASE_FORM_ID of the article nodes here so if we extend our application to other types we would do the same for those as well. Inside, we just define an #after_build function to be triggered when the form has finished building. This is to ensure all the form alterations have been already done by contributed modules. All that is left to be done is to write the function responsible for making changes to the form:

function editor_list_node_form_after_build($form, &$form_state) {
  $field = field_info_field('field_editors');
  if ( ! field_access('edit', $field, 'node', $form['#entity'])) {
    return $form;
  }

  if ($form['author']['#access'] === 0) {
    return $form;
  }

  $field_editors = $form['field_editors'];
  $field_editors['#weight'] = 0;
  $form['author']['additional_authors'] = $field_editors;
  $form['field_editors'] = array();

  return $form;
}

This looks complicated but it really isn’t. We begin by loading the field definition of our editor list field. This is so that we can run the field_access check on it and just return the form array unchanged if the current user doesn’t have access to the field. Next, we do the same if the current user does not have access to the author group on the form (this is the Authoring information group we want to place the field into). And lastly, we make a copy of the field definition, change its weight and place it into the group, followed by unsetting the original definition to avoid having duplicates.

And that is pretty much it. Now the editors list field should be tucked in with the rest of the information related to authorship.

Conclusion

In this article, we created a solution to a content editing problem that Drupal 7 could not fix out of the box. However, it did provide us with the development tools necessary to make this an easy task inside of a custom module.

We now have an editor list field on the article node form by which we can specify exactly which users have access to that particular node. Though do keep in mind that in order for this to be of any use, the users you add to these lists must not have a role that allows them to edit all article nodes. Otherwise you won’t see much of a difference.

Mar 16 2015
Mar 16

Security is an important aspect to keep an eye for, and this time it’s about preventing clickjacking on Drupal and other Apache web applications.

Edit apache’s configuration file, which may be your declared vhost or such, usually at a location like /etc/httpd/conf.d/default.conf and make sure the  following

<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>

This will disable embedding your website as an iFrame.

0013_clickjacking

Mar 09 2015
Mar 09

Apache Obfuscation can be achieved very easily and the benefits are great – it doesn’t disclose server information such as versions, OS, and does output verbose errors when ‘bad things happen’, and they happen.

2870445260_82be0db1db_z

Edit apache configuration, usually available here for RedHat based distributions: /etc/httpd/conf/httpd.conf

Make sure the following settings are present, save, and restart apache:

TraceEnable Off
ServerSignature Off
ServerTokens Prod

How do we test that this is actually working?

How to TraceEnable:
1. curl -v -X TRACE http://…
2. Confirm you get a forbidden response

How test ServerTokens:
1. Make a request to the website and check the response headers
2. Confirm the response contains only “Apache” information in the Server header

How to test ServerSignature:
1. Make a request to the website for a URL that should respond with Apache server error
2. Confirm you don’t see information about the apache server software version, OS, etc.

Mar 07 2015
Mar 07

Previously we read how to be a webmaster at drupal.org , Now I became the git administer at drupal.org. So I think to write a blog post so that others can benefit and also get to know how to become git administer.

In simple words: "Start Contributing". Git Administer privileges are granted to the users with proven record of contributions in the Project Applications issue queue. A solid history of consistent contributions on drupal.org is a must to get consideration for an elevated role.

How to start contributing & where you can contribute :

  1. Join the code review group
  2. Read How to review full project applications
  3. Some helpful tools for reviewing :
  4. Learning Sources : 
  5. if you found any problem while contributing,just comment on the below post/ if you need immediate answer you can try and find one of the git administer on IRC - #drupal-codereview IRC channel on Freenode.

Benifits of becoming git administer :

  1. You will see a new challenging case in every new project application.
  2. Your drupal apis knowledge will become sharp.
  3. Many more....

I would encourage you to learn more about that process and join the group of reviewers.
Next article:  A guide to review project applications
Feb 23 2015
Feb 23

Security of the Drupal website is a important stuff for the site owners, site developers.This blog post has my presentation at the Drupal Camp Mumbai that  intended for Drupalers who want to avoid security loop holes while writing code or architecting solutions. We delved into common security issues that ails custom code and has both vulnerable and secure code snippets.This is mostly about my encounters and experience after doing 50+ project application reviews and also a good guideline for new contributors.

[embedded content]

Hack Proof Your Drupal Site from Naveen Valecha

Next article:  A guide to review Project Applications.


Jan 23 2015
Jan 23

Was looking out some good English Speaking training course website for my cousinto become a fluent English speaker.


On opening the homepage I found the section "Free trial".

I did the same thing as all guys do.Click on the Free trial link,created my account.I personally feeling happy to get the 5 free audio English lessons.
I clicked on one of my lessons link and come to the page, found the download link of the audio file.



Copied and pasted the url in the browser and the downloaded the file. https://www.dailystep.com/en/download/file/fid/13531 Just change the fid in the url and tried to download some random file with file id. I thought what the Shit!   I then look around which drupal module has provided this route.After checking I got to know that this is the download file module which provides this route.After checking I assume that it might be permission stuff problem.
I found the similar permission problem on the drupal.org as well https://www.drupal.org/node/2394993
Trust is the Major Strategy in Security of any web application.We should be sure which user role we should assign which permissions.
Note: Published the post after suggesting the fix to the site owner Jane
Oct 31 2014
Oct 31

The recent announcement of Drupal SA-CORE-2014-005 caused a global scramble amongst Drupal site owners, developers and hosting providers to patch their sites and protect themselves from the vulnerability. Unfortunate site owners who weren’t quick enough were left with a site audit to ensure all traces of any successful attacks were removed from their environments.

Firstly, hats off to the Drupal Security Team, Core release co-ordinators and the Drupal community in general for a rapid, considered and clear response to the issue. The early warning that a security release was coming was well stated enough to make it clear to many that it would be a major issue. The normal release time was brought forward to a more suitable timeslot to ensure the maximum audience saw it early, and the post-release guidance, FAQs and blog posts covered all aspects from how to patch, what to do if your site had been hacked, and what to look out for to indicate if you had been affected. A follow up public service announcement PSA-2014-003 was published drawing further attention to the risks to unpatched sites and offering further guidance.

Secondly, excellent work from Sektion Eins, the penetration testing experts who detected the vulnerability. This was a defect that has existed for many years, and many organisations will have run penetration tests that haven’t previously detected it. Having been creative enough to find the vulnerability, it was then reported and managed responsibly, which should be praised.

Now, I don’t want to focus on SA-CORE-2014-005 any further, but instead I want to talk about some ways we can protect our Drupal sites and minimise our exposure to vulnerabilities. Whilst bugs will always happen (whether security or functional), there are steps we can all take to mitigate our exposure and respond quickly to incidents.

Early warning systems

The best cure is prevention, and the next best is to catch it early. There are lots of ways to keep up to date with what is going on in Drupal security:

  • The Drupal Security pages contain the most recent core, contrib and public service announcements for Drupal and include RSS feeds
  • Sign up for the Security Announcements mailing list (login to Drupal.org, go to your user profile page and subscribe to the “Security announcements” on the Edit » My newsletters tab)
  • Follow @drupalsecurity on Twitter

All three of these routes will ensure you’re on the quickest possible route to hearing about new security releases. It then becomes quick and easy to review the latest threats, decide if you’re vulnerable (by reviewing the mitigations - a lot of vulnerabilities depend on elevated roles or other mitigations, and these will be clearly described on each Security Advisory), and how quickly you ought to upgrade your core installation or other modules.

It’s also worth having the Update module enabled in your dev environment to phone home and check if there are updates for any of your modules available - however if like me you only login to some sites occasionally then you’ll want a backup strategy for keeping you informed.

It should then become almost ritual that for each alert you:

  • Determine if your core version is affected
  • Determine if you use the contributed module reported as affected
  • Reviewing any mitigations (vulnerability requiring elevated permissions etc) that may keep you safe from the vulnerability and reduce the urgency of patching/upgrading
  • For any urgent updates, apply as soon as practically possible
  • For any non-urgent updates, apply to normal dev/test/release cycle and deploy in your next release slot

Don’t leave the back door open

The great thing about Drupal is the wide range of contributed modules that you can use to kickstart your development and re-use functionality that other people have already built for you. However, this comes with its own risks - as you’re effectively installing code that you’ve not written and so have no guarantees of how secure it may be.

With this in mind, it’s essential to review the modules you download, rather than just installing them right-away. Just as we check if modules contain any potential performance gotchas, we also look to see if there are any obvious security flaws - use of $_GET or $_POST variables in templates, data directly concatenated into SQL queries, no roles or permissions defined, all gives clues, and we can use Drupal secure coding guidelines, and awareness of the OWASP Top 10, to inform our reviews.

To some degree, these checks can be automated by running things like Coder, which includes some basic security checks and has some good proposals to add more security sniffs. Modules like Security Review can also check for some easy-to-make mistakes which may render your site insecure - and are invaluable, particularly if you’re new to site security. However, automated checks are only as good as the information they’re fed with, so there is no substitute for getting in and reading the code - you were going to look to see how it worked anyway, right?

Remember - if you do spot any security flaws in Drupal Core or Contrib, don’t raise issues in the public issue queues, make sure you follow the process to report a security issue to the security team, so that it can be fixed in private and released before the vulnerability is made public.

Constant vigilance

It’s not just Drupal that can be exposed to vulnerabilities such as these, PHP itself has had its share over the years, and realistically no large body of code is going to go its entire life without some vulnerabilities creeping in. There are also many more people trying to find vulnerabilities to take advantage of than there are people trying to fix them.

This means keeping your entire platform secure becomes a constant activity, so a reliable and repeatable test and release cycle becomes essential - if pulling down the latest updates and deploying them takes a significant amount of time, the odds are that you’ll get lazy and skip an udpate or two. This soon becomes the security guys nightmare as sites, services and platforms become more out of date and more vulnerable to attack.

Watch the watchman

All the attention paid to Core and Contrib security updates is very valuable, but it becomes worthless if you don’t give the same care to the code you and your team write in custom modules. An awareness of how to follow Drupal best practices to write secure code is an essential part of the training and education of any good Drupal developer. Fortunately Drupal provides some excellent abstraction layers to remove some of the thinking on these topics, so make sure you use the database layer correctly, handle text securely, and create forms in a safe way, as well as all the other best practice.

It’s also well worth commissioning penetration tests from external specialists to test your implementation and validate that it is secure. We use the expertise of these companies regularly, and rotate through a list of preferred companies to ensure that we’re constantly getting fresh eyes on the solutions, and varied approaches to testing, so as to maximise the chances of finding issues. The tests often prove their worth, and whilst every developer hates having defects raised, we’d all much rather the security issue be in a test environment than in production!

Reading list

To finish, here are some excellent resources to keep up to date with best practice approaches to keeping your Drupal installation secure:

Oct 22 2014
Oct 22

I estimate hundreds of thousands of Drupal websites now have backdoors; between ten and ninety percent of all Drupal websites. Automated Drupageddon exploits were in the wild within hours of the announcement. Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal. Backdoors give attackers admin access and allow arbitrary PHP execution.

If your Drupal 7 (and 8) website is not updated or patched it is most likely compromised. If your website was not updated within a day of the announcement, it is probably compromised. Even if your website was updated within a day, it may be compromised.

If you did not know, Drupageddon is the highly critical SQL injection vulnerability in Drupal core announced 15 October. It is also known as Drupalgeddon (with an "L"), CVE-2014-3704, Drupal SA core 2014 005 and #DrupalSA05. Drupageddon (no "L") is the original name selected by Stefan Horst, who initially reported to the Drupal security team. See Drupageddon.com.

I have drafted this flowchart to help Drupal website administrators understand their options for recovering from Drupageddon. Review, feedback and collaboration is welcome.

The flowchart is a living document. Currently version is number 7.

Updates

How to fix a Drupal site compromised by Drupageddon

Creative Commons License

Oct 16 2014
Oct 16

Are you done updating your nginx and apache servers to no longer support SSLv3 and prevent the POODLE attack? Well, now it’s time to upgrade your Drupal 7 sites to version 7.32, as a significant SQL injection vulnerability has been fixed in that update. Exploits are sure to follow, if they aren’t already in the wild.

SA-CORE-2014-0044

The technical writeup of the exploit is, in my opinion, actually very light in providing technical details. Helpfully, there’s a simple patch to prevent the attack. If you can’t do a full upgrade right now, go apply the patch. The exploit can be used by anonymous attackers, so an ounce of prevention here will pay off. Let’s take a look at the patch:

diff --git a/includes/database/database.inc b/includes/database/database.inc
index f78098b..01b6385 100644
--- a/includes/database/database.inc
+++ b/includes/database/database.inc
@@ -736,7 +736,7 @@ abstract class DatabaseConnection extends PDO {
// to expand it out into a comma-delimited set of placeholders.
foreach (array_filter($args, 'is_array') as $key => $data) {
$new_keys = array();
- foreach ($data as $i => $value) {
+ foreach (array_values($data) as $i => $value) {
// This assumes that there are no other placeholders that use the same
// name. For example, if the array placeholder is defined as :example
// and there is already an :example_2 placeholder, this will generate

The fix is to change the foreach loop to ensure it loops through a numerically indexed array of values. Without the call to array_values, malicious attackers could inject SQL conditions via the array’s keys, which are used to name the expanded placeholders. The post on sucuri.net about the exploit shows the manipulated SQL statement. A good discussion of the attack can also be found on the PHP subreddit.

But…PDO?

I was a bit stumped at first. Drupal 7 is using PDO and prepared statements, so it should be safe from SQL injection. Right? Diving into the affected file, this foreach loop is in a function, expandArguments that “supports an alternate syntax for doing arrays of values”. Looking at the example from the advisory:

The function assumes that it is called with an array
which has no keys. Example:

  db_query("SELECT * FROM {users} where name 
    IN (:name)", array(':name'=>array('user1','user2')));

Which results in this SQL Statement

  SELECT * from users where name IN (:name_0, :name_1)

with the parameters name_0 = user1 and name_1 = user2.

The Problem occurs, if the array has keys, which are 
no integers. Example:

  db_query("SELECT * FROM {users} where name IN (:name)", 
     array(':name'=>array(
       'test -- ' => 'user1',
       'test' => 'user2')
     )
  );

this results in an exploitable SQL query:

  SELECT * FROM users WHERE name = :name_test -- 
    , :name_test AND status = 1

with parameters :name_test = user2.

Since Drupal uses PDO, multi-queries are allowed. So this 
SQL Injection can be used to insert arbitrary data in the 
database, dump or modify existing data or drop the whole 
database.

So, because the array keys were not filtered nor sanitized, attackers can change the resulting SQL. Coupled with the fact that PDO allows multi-queries by default, a single call could execute an insert, update, delete, drop statement along with the original select statement.

Disabling Multipe Queries

Don’t use Drupal? Because PDO uses emulated prepared statements, If you’re using PDO to interact with MySQL, you may want to disable multiple queries in your PDO statements as a safeguard. Though you’ll also lose the ability to “use a named parameter marker of the same name more than once in a prepared statement”. Read the PHP documentation for PDO::prepare, first. To disable it:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Security is Ongoing

This attack reinforces that security is hard and ongoing. You can’t trust user input, so remember to always Filter Input, Escape Output (FIEO). Kudos to the Drupal security team for addressing and publicizing the vulnerability. While it’s unfortunate that an exploit was found, it’s comforting to know that the project has a team dedicated to security.

Jun 26 2014
Jun 26

TimeBanks USATimeBanks USA is a 501c3 nonprofit organization that promotes and supports timebanking. Timebanking was created by Dr. Edgar S. Cahn, who founded TimeBanks USA in 1995.

Timebanking is a tax-exempt alternative currency system that works like this: if I spend one hour helping you build your website, I earn one credit, or time dollar. You can then turn around and exchange that time dollar by giving it to someone who fixes your refrigerator, coaches you on your resume, or gives you a ride to the airport.

The possibilities are endless,” according to TimeBanks USA. “An hour of gardening equals an hour of childcare equals an hour of dentistry equals an hour of home repair equals an hour of teaching someone to play chess.” It’s different from bartering, because this type of timebanking is based on services (and not goods) between members of a network.

This wasn’t the first time Exaltation of Larks has worked with alternative currencies. We created a virtual economy for Digital Dollhouse, a casual game where girls are empowered to become their own interior designers. In this virtual world, it’s possible to trade or regift items like dolls, plants and pets, and work with an in-game currency named ddCoins.

In addition to our work with TimeBanks USA, our experience with timebanking includes working as volunteers with two Los Angeles-area timebanks: Arroyo S.E.C.O. Time Bank and the West LA timebank cleverly named Our Time Bank. Our Time Machine project is an experimental Drupal installation profile for communities and organizations looking for turnkey timebanking software for their members and participating businesses and organizations.

TimeBanks USA founder Dr. Edgar S. Cahn has spent more than four decades striving for social justice. He began his career working for the Kennedy administration, focusing on alleviating poverty and hunger. He then opened the Citizens Advocate Center, an organization dedicated to protecting the rights of community groups as they interacted with the government. In 1972, Dr. Cahn founded the Antioch School of Law, whose curriculum was designed to teach students to practice law for the greater good of society.

Here at Exaltation of Larks, we have enormous respect for Dr. Cahn: at the age of 80, he is still a rabble-rouser and hell-raiser who is fighting to change the world, and we’re proud to provide him with the technical assistance to further this goal. Dr. Cahn is a true visionary and we hope to work with — and write about — him and his partner, Chris Gray, TimeBanks USA’s CEO, more in the future.

TIMEBANKS USA’s ROLE IN TIMEBANKING

TimeBanks USA TimeBanks USA supports timebanking in myriad ways, including offering onsite trainings nationwide; organizing an annual timebanking conference; hosting webinars and teleconference calls; and consulting individually with clients. The organization helps members connect with local timebanks or create their own.

One of the parts of TimeBanks USA infrastructure is a large scale social networking platform named Community Weaver, which has a software-as-a-service subscription model. There are more than 400 timebanking websites all around the world that rely on it to help manage and organize their timebanking processes, community activities and other needs.

TIMEBANKS USA’s NEEDS

Exaltation of Larks performed a substantial security and performance audit on Community Weaver, a complex Drupal multisite system. We helped TimeBanks USA fix critical issues affecting one of their essential online organizational tools — their Community Weaver software. This software platform runs a quickly evolving and iterating network of Drupal websites, so it was vital that the software could be updated and developed sustainably and seamlessly, yet without overriding the autonomous decision-making processes of each chapter website.

In addition, we worked with TimeBanks USA to develop a project plan for version 3.0 of Community Weaver and raise the funds to build it; we addressed problems arising from the system’s simultaneous use of both WordPress and Drupal; and we helped streamline the organization’s decision-making process.

TimeBanks USA needed extensive rework on their Community Weaver software, specifically with regard to security, performance and usability issues. Community Weaver is an online organizing and tracking tool for timebank members: it records time exchanged, displays service offers and requests, keeps track of memberships, and displays announcements for the community. Any local timebank can subscribe to TimeBanks USA’s software-as-a-service (SaaS) system to manage their members’ work. TimeBanks USA hired Exaltation of Larks to audit and rework Community Weaver 2.0, with the plans to eventually migrate all their technology, online memberships and e-commerce data to version 3.

TimeBanks USA was also experiencing security problems with its self-hosted WordPress website, which was outside our original scope of work. TimeBanks USA used our emergency support system and we quickly mobilized to resolve this new issue. We determined that security had been compromised and implemented several solutions to tighten it up, from checking the code integrity to updating MySQL access and hardening file permissions.

In addition to our work with TimeBanks USA, we worked with the Arroyo S.E.C.O. Time Bank, one of the many timebanks affiliated with TimeBanks USA. Arroyo S.E.C.O. serves neighborhoods in the eastern and northeastern Los Angeles area, which meant the Larks who were in the Downtown Los Angeles area could work with them one-on-one.

OUR SOLUTION

We began by tackling the security issues found in Community Weaver. Fortunately, TimeBanks USA had an in-house Drupal developer, who we worked with on a massive infrastructure audit, focusing on security and performance. This multisite installation had been built by its previous developer with development practices that were common in 2007, before Features and configuration-in-code became popular. We identified which multisite instances had been modified by their local chapters’ coordinators — which meant examining data structures, views, and content types across hundreds of Drupal websites — and which had unsafe code or configuration. We found security vulnerabilities through the entire stack, from the Drupal systems and websites down to the server operating system, all of which we documented, prioritized and / or resolved.

This was an extensive audit that had both technical and political ramifications. Each chapter is run by its coordinators and volunteers and sometimes in completely different ways than other chapters. In a multisite environment, making technical decisions for the entire fleet of hundreds of websites would impact all local chapter websites that had been modified for their own business cases.

We worked in conjunction with TimeBanks USA to devise policies and joined them on many global community conference calls — open to all coordinators of all the timebanks in the world — to describe our technical approach and to solicit feedback. Our task was to provide technical leadership for the entire organization. We needed a set of standards for sustainable development of this enormous network, but we also needed to respect each individual chapter’s right to make its own decisions.

The project plan we provided included time estimates to address the security problems we found. TimeBanks USA’s tech coordinators reviewed our list of most-needed fixes and then we consulted with a local timebank coordinator and Community Weaver user to make sure these fixes matched their timebank’s list of essential tasks.

We worked with several popular web hosting providers, including Drupal-as-a-service platform companies, to negotiate competitive pricing on behalf of TimeBanks USA. Due to their unique system and web application architecture, we recommended SoftLayer based on their features and pricing.

TimeBanks USA Community Weaver

The unfortunate multisite architecture that the prior developers had devised had the result of creating exponential complexity precluding any proper maintenance and further development on the system. We navigated our way through thousands of lines of uncommented custom code. We also found that the Linux server environment was an abandoned and unsupported custom distro. In both cases, we replaced as many unknown components as possible with stable, peer-reviewed alternatives and we documented the rest. We also stabilized the system by locking down the kinds of changes that individual coordinators could make to their individual timebank chapter websites, thus reducing future maintenance costs.

We fixed several security issues in the system by altering file permissions, MySQL accounts, and text input filters. We used PHP Filter Lock, a module we developed that disables the text form fields that contain PHP code, thereby mitigating the risk of CSRF and XSS security threats on websites that have the core PHP Filter module enabled.

On the same server as the Drupal multisite network was a WordPress marketing website. This in itself is not a problem. Exaltation of Larks’ position is that WordPress is great for simple websites and Drupal is great for complex systems and web applications. Having both on the same server created unnecessary security issues, however. The WordPress installation was technically able to overwrite anything on the Drupal side as well as access the Drupal database. We changed all MySQL usernames and passwords and locked down the file permissions so that the WordPress website could no longer be overwritten or be a risk to other software on the server, including Community Weaver.

Next, we worked with TimeBanks USA to develop the requirements for the next version of Community Weaver. The materials we developed included specifications for a fully featured mobile app, a business plan with financials and pitch deck, and more, and were designed to help TimeBanks USA secure additional funding. In the meantime, we trained a member of their community to maintain the software so they could further reduce their total cost of ownership.

Exaltation of Larks also provided TimeBanks USA with communications strategy consulting services. We performed a 360-degree organizational audit and came up with a more streamlined decision-making process. We created flowcharts of all the key players and stakeholders at TimeBanks USA and highlighted the points at which they had both strengths and weaknesses, and made recommendations where more efficiency was needed.

COMMUNITY INVOLVEMENT

Timebanking has evolved very differently in other parts of the world in ways that no one could have predicted. Nowhere is this emergent behavior more apparent than in highly populated cities, where the numbers, density, and different practices around timebanking create vastly different needs. One such advanced timebank is the Arroyo S.E.C.O. Time Bank in Los Angeles, which has thousands of members across dozens of separate neighborhoods. They needed several custom workflows implemented on their individual timebanking website to manage the scale that had resulted from their impressive growth. By its very nature, the timebank had no money for further development on their individual website.

Barnraisings are a concept taken from Amish culture, where the community comes together to build a barn for a newly married couple who wouldn’t be able to afford the time or expense of building a barn on their own. In the context of web development, barnraisings are like code sprints where the programming community gets together with a deserving nonprofit, and works with them to create or improve their software. For the development community, this is a teaching experience, and newer developers get to learn from seasoned veterans about client relationships, requirements gathering, project planning and the tools used for effective teamwork. The nonprofit brings food — usually excellent food — and everyone benefits.

Starting in April, 2012, the Larks partnered with Droplabs and arranged three separate barnraisings to build new features for the Arroyo S.E.C.O. Time Bank. Not only was a good time had by all, the team built functionality that the Larks turned into Features-based modules that could then be securely distributed to the other timebanks, to be turned on, or not, according to the wishes of each individual timebank coordinator. Features built included a custom registration workflow, neighborhood-specific blogs, and structured data types for content, among others.

PROJECT OUTCOME

Previous to Exaltation of Larks coming on board, TimeBanks USA had been working with a different development company. The Community Weaver software proved challenging to rework and over the 2 years we worked together we ensured that key security and performance problems with the software were resolved.

TimeBanks CEO Chris Gray says of the project: “Given the importance of the software for the mission and vision of TBUSA, and given how much we had to learn, this was a very intense experience for us.”

In addition, with the help of the volunteers at the barnraisings, we added several new features to the Community Weaver software, including a blog post content type and RSVP feature that integrates with the Signup module. These features directly benefit all the hundreds of TimeBanks chapters around the world that use the same Drupal distribution of Community Weaver.

All members of the Larks team, from the principals to the project leader to the programmers, demonstrated that they cared deeply about the quality of the work undertaken,” Chris Gray said. “[They] provided many hours of consultation to this endeavor. We are truly grateful for those contributions. Under challenging circumstances, they provided highly professional services to TBUSA. We greatly appreciate the professionalism of the Larks and the ongoing willingness to go above and beyond.”

Jun 02 2014
Jun 02

You’ve probably come across this situation before. When visiting a certain site, you see a browser warning that the website is using mixed content — both HTTP and HTTPS together.

Avoiding mixed content is nothing new to some web developers, but read on if you’re looking for a quick fix to prevent both mixed content warnings and CSRF attacks, which are the underlying reason why browsers have those warnings in the first place.

Introducing HSTS

HSTS, or HTTP Strict Transport Security, is a security implementation that was created in 2012. It’s been part of our standard security package for a while and we would love to see more websites using it.

read more

Jul 15 2013
Jul 15

Most experienced Drupal developers have worked on sites with security issues. Keeping modules up to date is a pretty straight forward process, especially if you pay attention to the security advisories. Coder can find security issues in your code.

Recently I needed to perform a mass security audit to ensure a collection of sites were properly configured. After searching and failing to find a module that would do what I needed, I decided to write my own. The Security Check module for Drupal checks basic configuration options to ensure a site configuration doesn't have any obvious security flaws. This module isn't designed to find all flaws in your site.

Security Check works by checking a list of installed modules, settings for variables and permission assignments. I hope that others in the community will have suggestions for other generic tests that can be implemented in the module. If you have any ideas (or patches), please submit them as issues in the queue.

This module isn't a substitute for a full security audit, which can be conducted in house or by a third party such as Acquia's Professional Service team. Security Check is designed to be run as part of an automated site audit to catch low hanging fruit.

To use Security Checker install it in ~/.drush and then cd to any docroot and run "drush security-check" or if you prefer to use an alias run "drush @example secchk" from anywhere.

Bookmark/Search this post with

Mar 30 2013
Mar 30

At the Boston Drupal meetup that was at Acquia this month, several presentations were focused on “what’s new in Drupal 8” from the view of several people who now work at Acquia. I loved it. There were other presentations, as well (including one of my own!), and I really enjoyed seeing the Boston Drupal group again after many months.

During the questions and answers part of the meetup, I asked Dries if he was considering naming a security maintainer for Drupal 6 when Drupal 8 is released. (In case you didn’t know, support for Drupal 6 will be discontinued by the Drupal core and security teams. See the handbook page on backwards compatibility at https://drupal.org/node/65922 for more, including Dries’ original statement on the subject in 2006.)

read more

Feb 04 2013
Feb 04

It's a question we all ask ourselves: What would I do if my site or server was compromised? Security professionals have loads of checklists to follow, and experienced server administrators drill for those moments. As we saw when Twitter.com was recently compromised by hackers, "Reset everyone's passwords, right away!" is almost always one of the important steps. If you run a Drupal site, that particular step can be frustrating. Resetting user passwords one by one is incredibly time consuming, and there's no way to do it for everyone in one fell swoop. At least, there wasn't until the release of the Mass Password Reset module…

Screenshot of administration screen

This recently-released module gives administrators a simple, straightforward admin page where they can reset every user's password with a single click. Notification emails can optionally be sent out to each user, just as if they'd requested the password reset themselves. (If you're using the module as part of the response to an actual security incident, it's probably a good idea to modify the standard password reset email before you click the "reset" button -- explaining why they've been reset is important, and unfortunately the module doesn't let you override it right from its bulk reset screen.) You can also choose to reset the root administrator's password (User 1 on the Drupal site), though the option is disabled by default.

There are a few situations in which you'd want to issue a mass password reset in calmer times. Just before launch, for example, you might want to ensure that a large batch of users migrated from another system all select new, secure passwords. For the most part, though, Mass Password Reset is a good tool to keep in your back pocket for a time when you need it. Hopefully you won't, but it's great to have when you do.

*/
Jan 28 2013
Jan 28

Node Access: Who wins?

While Drupal has always had a pretty robust access control mechanism, it was difficult in the past to handle multiple contributed modules who wanted to impose different types of access control. Who wins? If a node is within a private Organic Group, but is also in a public Forum, is the node private or public? In Drupal 6, multiple access control modules could conflict and had to take special care to co-exist. It was messy.

In Drupal 7 the access control API was cleaned up and now it is relatively easy to handle multiple access control systems. Let’s learn the best way to implement your own access control system in Drupal 7.

The Perils of hook_node_access

Drupal 7 added a cool new hook for developers: hook_node_access($node, $op, $account). On the surface, this seems like the ultimate hook to control access. You simply return NODE_ACCESS_ALLOW, NODE_ACCESS_DENY, or NODE_ACCESS_IGNORE. In reality, this hook can be very dangerous! It allows you to override the access control of any other modules on your site. For example:

1
2
3
function mymodule_node_access($node, $op, $account) {
   return NODE_ACCESS_DENY;
}

This would deny access to all of your content regardless of any other access control. If it returned NODE_ACCESS_ALLOW it would *allow* access to all of your content! Unless some other module returns NODE_ACCESS_DENY, in which case access would still be denied.

Even worse, your custom hook_node_access function is ignored by Views, Menus, and other content queries on the site. Even though you have denied access to all content, you’ll still see all of your normal menu links, and will see your nodes listed in Views. Only when you click on a node to view it’s full detail page will you then be denied. You might be violating content privacy just by showing that certain content exists!

A “Deny” based approach

Drupal is a “deny-based” access control system. In other words, if anybody denies access to a node, then the node is blocked. This is similar to having multiple locks on your door: you need to open ALL the locks to enter your door. Using hook_node_access to return NODE_ACCESS_ALLOW access violates this convention and is generally a bad idea. Instead you should design your modules to DENY access when needed, and otherwise return NODE_ACCESS_IGNORE to allow other modules to decide if access should be granted. The hook_node_access results are the “last line of defense” for denying access and don’t stop Views or Menus from showing parts of the content anyway.

The correct approach is to use the Drupal “Grant” system. This API existed in previous versions, but in Drupal 7 it was cleaned up and works much better. The key hooks are hook_node_grants($account, $op) and .hook_node_access_records($node). The documentation can be hard to follow and talks about “realms” and “grant ids”. Instead, let me explain this API using the concepts of Locks and Keys.

hook_node_access_records are Locks

LocksThe hook_node_access_records is called to determine if a specific node should be locked. Your module has the opportunity to create a Lock with a specific “realm” and “id”. The “realm” is like the color of your lock and is typically the name of your module. This allows a single node to have multiple locks with different colors (multiple modules). To open the door, you would need keys that match each color of locks on the door.

Within a realm, you can have multiple locks with different “ids”. This is like giving the colored lock a specific serial number corresponding to a key with the same color and serial number. If you have a key with the correct color and serial number, than all of the locks of that color are opened. To summarize:

  • Each lock Realm (color) must be opened to access the node
  • Only one ID (serial number) within the Realm needs to be unlocked to open that entire Realm.

These node Locks are stored in the node_access database table, which means they are cached. This table is only rebuilt when you run the Rebuild Permissions in the Status Report area of your Drupal admin. When you save a node, hook_node_access_records is called only for the node being saved to allow it’s locks to be updated. If changing a node can affect the locks on other nodes, then you’ll want to call node_access_acquire_grants($node) to update the locks on the related nodes.

hook_node_grants are Keys

KeysThe hook_node_grants is called to create a “key-ring” for a particular user account. This is called dynamically at each page load to determine what keys the current user has. As mentioned above, a particular node can be accessed only if the user has the appropriate keys for each Realm (color) of locks on the node. Because this key-ring is not stored or cached, it is important to make your hook_node_grants function very fast and efficient.

When implementing hook_node_grants, you are typically only concerned about the Realm implemented by your module (remember that Realm is usually your module name). You probably don’t want to be messing with keys for other modules. Your hook just needs to decide if the user has any of *your* keys. Specifically, your hook needs to return a list of key IDs (lock serial numbers) within your Realm for the specified user account.

REAL Node Access!

The beauty of using the two Grant API hooks described above is that they are respected by Menus, Views, and optionally other queries within the database API. If the user does not have the proper keys to open the locks on a node, then the node will never display in any Menu or View. Unlike hook_node_access(), this properly protects the privacy of your content.

With Views, you can turn off the node access filtering in the Query Options of the Advanced section of the View. Turn on the “Disable SQL rewriting” option and now Views will return all results regardless of the keys and locks.

If you create your own database queries using the Drupal database API, you can also easily filter results based upon node access. Simply add a “tag” to the query called “node_access”. For example:

1
2
3
4
$query = db_select('node', 'n');
  ->fields('n', array('nid', 'title'))
  ->addTag('node_access');
$result = $query->execute();

The above example would only return the nid and title of nodes the current user can access.

UPDATED: It is important to include this addTag(‘node_access’) for ANY query that you perform that returns node results to a user. Otherwise you’ll be introducing a security hole into your module. You can also use EntityFieldQuery which automatically filters results based upon node access.

An Example from Open Atrium 2

In Open Atrium 2, we implement a flexible node access system. All content is assigned to a specific “Section” within a normal Organic Group. Each Section can be locked based upon Organizations, Teams, and Users. For example, if Mike and Karen are assigned to the “Developer” Team, and the “Developer” Team is assigned to a specific Section, then only Mike or Karen can see the existence of that Section and the content within it. To accomplish this, we implement hook_node_access_records to assign locks, and hook_node_grants to assign keys.

First, let’s assign the locks for content within a Section:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
 * Implements hook_node_access_records().
 */
function oa_node_access_records($node) {
  $sids = array();
  // handle the Section node itself
  if ($node->type == OA_SECTION_TYPE) {
    if (!oa_section_is_public($node)) {
      $sids[] = $node->nid;
    }
  }
  // Now handle pages within the Section
  else if (!empty($node->{OA_SECTION_FIELD})) {
    foreach ($node->{OA_SECTION_FIELD}[LANGUAGE_NONE] as $entity_ref) {
      $section = node_load($entity_ref['target_id']);
      if (!oa_section_is_public($section)) {
        $sids[] = $entity_ref['target_id'];
      }
    }
  }
  if (empty($sids)) {
    return array();
  }
  foreach ($sids as $sid) {
    $grants[] = array (
      'realm' => OA_ACCESS_REALM,
      'gid' => $sid,
      'grant_view' => 1,
      'grant_update' => 0,
      'grant_delete' => 0,
      'priority' => 0,
    );
  }
  return !empty($grants) ? $grants : array();
}

For a Section node, we just grab the node ID. For pages within a section we grab the referenced section IDs. Once we have a list of section IDs, we loop through them and create a $grants Lock record giving our module name OA_ACCESS_REALM as the Realm (color), and the Section ID as the ID (serial number). This adds our colored Lock to the nodes that are protected within Sections, using the specific Section ID as the lock serial number.

Next, let’s build the key-ring for the user account (*Note, this is a non-optimized version of code for instructional purposes):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * Implements hook_node_grants().
 */
function oa_node_grants($account, $op) {
  $sections = oa_get_sections();
  // returns a list of all section IDs
  foreach ($sections as $sid) {
    // determine if the user is a member of this section
    if (user_in_organization($sid, $account) ||
      user_in_team($sid, $account) ||
      user_in_users($sid, $account)) {
        $grants[OA_ACCESS_REALM][] = $sid;
    }
  }
  return = !empty($grants) ? $grants : array(); }

For each Section that the user is a member of, we return the Section ID for that Realm in the $grants array. If a particular node has Section locks, only users with a key to that Section will be granted access. For example, if a node has locks for $sid 1, 2, and 3, but the user only has a key for $sid 4, then access is denied. But if the user has a key for $sid 1, 2, or 3, then access is granted. You only need a single matching key within the Realm to grant access.

Conclusion

If you think about the Drupal node access system as a system of Locks and Keys, then it’s pretty easy to understand. It’s a very powerful system and one of the key strengths of Drupal. Try using this Grant API and only use the new hook_node_access as a last resort, especially when building other contributed modules where your hook_node_access might conflict with other modules.

Sep 27 2012
Sep 27

Lullabot's Drupal training site turns 2

It's been almost 2 years since we launched Drupalize.Me and I'd like to take a moment to appreciate some of the site's recent accomplishments.

Over 600 Videos

A few weeks ago, Drupalize.Me product manager Addison Berry announced the 600th video posted to Drupalize.Me! Members now get access to over 233 hours of content on an immense range of Drupal-oriented topics from simple content creation to site building tricks and database server performance optimization. Drupalize.Me's most popular videos cover coding for and using Views, using the Calendar and Date modules, configuring WYSIWYG editors, Display Suite, Organic Groups, Drupal 7 module development, and more. The Drupalize.Me team has been really amazing – posting new videos every week and paying close attention to member requests for new topics.

Over 2,000 Subscribers

Word about Drupalize.Me has spread and I often see people on Twitter telling one another that for them, Drupalize.Me has become the way to learn and keep up with Drupal techniques. Drupalize.Me has iPhone/iPad, Android, and Roku apps so members can watch the videos on their mobile devices or televisions. Drupalize.Me has also partnered with Acquia to offer discounted memberships to Acquia Network subscribers.

As word has been getting around about Drupalize.Me, subscriber numbers have been growing and recently crossed 2,000 simultaneous subscribers. We're reaching more people on a monthly basis than most large-scale Drupal events. We couldn't be more excited about the response!

Drupalize.Me now has a staff of 3 full-time people creating videos, maintaining the site, adding features and handling customer support. This team is augmented by others at Lullabot who step in to help with expert video training, development, design and support. Drupalize.Me now represents more than 15% of Lullabot's budget and has become a great outlet for the Lullabot team to share the knowledge that we've gained building the high-profile websites that represent the majority of our work.

New Features

The Drupalize.Me team has been listening closely to subscriber feature requests and we've gotten lots of new features over the past 2 years. They've arranged videos into "series" collections and allow users to watch them consecutively. They've also added curated "guides" collecting videos into linear curriculum for different types of members. They've also greatly improved the user dashboard pages allowing users to manage their queue as well as see the listing of recently watched videos and even displaying a line graph so members can see their progress within the videos they've watched. The team also added the ability to store pause points and allow users to resume from exactly where they left off - even if they're resuming on a different device such as their phone or connected television.

And speaking of connected televisions, we've got apps! We've got an iOS app for your iPhone/iTouch/iPad which can AirPlay to your AppleTV. We've also got an Android app and an app for the Roku Streaming Player box. You can pick up a Roku box for as little as $50, hook it up to your television, and watch all of the Drupalize.Me videos from your couch. It's a great way to learn.

Group Memberships

Drupalize.Me also offers group memberships. If you want Drupal training for your entire group, department, company, or institution, we offer that too. Group accounts greatly reduce the price of individual accounts while still allowing each group member to manage their own video queue, resume videos, and see their own history. We offer both managed group plans and IP-range plans to allow access to all devices at a physical location such as a library or campus.

Subtitles, Transcripts & Translations

Perhaps the greatest new features at Drupalize.Me are the ability to offer subtitles, transcripts, and translations for the videos. We have many international subscribers who, while they speak and understand English, sometimes can't keep up with the rapid-fire technical information in the videos. They've been asking for English-language subtitles and transcripts so they can follow along better. We're proud to say that we've added this functionality as well as functionality to provide complete translations with subtitles in other languages! 60 of our recent videos as well as the complete Introduction to Drupal guide already have transcripts and subtitles. And all new videos published on Drupalize.Me in the future will have transcripts and subtitles.

We're currently looking for volunteers to do foreign language translation for Drupalize.Me. If you're a bi-lingual Drupalist and you'd like to help make bring these Drupal training videos to the world, please contact us!

Drupalize.Me & Videola

One of the Drupalize.Me team's biggest accomplishments is building the Drupalize.Me site itself. The team has built a great Drupal-based platform which manages both the permissions and delivery of adaptive bitrate streaming video; recurring subscription billing and administration; video content categorization, listing, and organization; mobile app and IPTV delivery with seamless pause-on-one-device-resume-on-another functionality; and now even multi-language subtitles and transcripts.

As we've been building Drupalize.Me, we've been funneling this work and knowledge into Videola, a platform to provide this functionality to others wanting to build subscription-based or IPTV-oriented video sites. In short, Videola is a framework for building sites like Drupalize.Me... or like Netflix, Hulu, or Amazon video-on-demand. Videola can do everything that Drupalize.Me can do and more. If you'd like to build a site like this, please contact us and we can talk to you about getting you set up with a Videola site of your own.

Onward

Addi and the rest of the Drupalize.Me team have been doing a lot of training at DrupalCons, DrupalCamps, and other events. They've been very involved in the Drupal Ladder project and have posted a series of free videos to help new Drupalers get involved with core development.

Drupalize.Me recently started its own podcast (which picks up where the long-running Lullabot Drupal Podcast left off). Every other Friday, the Drupalize.Me team is posting a new podcast with interviews and discussions to help listeners keep up with the ever-changing world of Drupal. The team is also constantly upgrading and improving the site and they've got lots of great feature ideas for the future.

I couldn't be more proud of the work that's been done by Addi Berry, Joe Shindelar, Kyle Hofmeyer, and everyone who's helped with Drupalize.Me over the past 2 years. The site just keeps getting better and better. At this rate, I fully expect that 2 years from now I'll be bragging about their Drupal training neural implants and interstellar 3D streaming. But for now, I'm really happy with where we are – doing great, having fun, and sharing knowledge with people, empowering them to do great things.

Jul 09 2012
Jul 09

For Humans and Androids

Out of the box, Drupal includes many useful features that are helpful for sites where one person wears the developer, site builder, and content administrator hats all at the same time. However, some of these features could be considered dangerous when a broader group of individuals are administering a Drupal site. The Paranoia module aims to help keep your site secure by disabling places where PHP code might be executed or important data might be changed.

Installing Paranoia follows the usual steps for any other Drupal module; download to sites/all/modules, and enable it from the modules page. If the PHP module is enabled on your site, you will be warned that such content will now be "plain text" and should be audited.

PHP module and text filter is disabled

Other changes that the Paranoia module makes include:

  • Only letting user 1 (the site administrator) edit the user 1 account
  • Disabling using PHP for block visibility
  • Prevents disabling Paranoia without direct database access (or using Drush)

By default, Drupal 7 permissions tagged as being "restricted access" are prevented from accidentally being added to anonymous or authenticated users. As well, permissions exposed by other modules can be hidden entirely by implementing hook_paranoia_hide_permissions().

Paranoia is a great example of a short and simple module that gets the job done. If you're running a site where you're sharing administrative duties, consider installing it to increase your site's security.

*/
Mar 06 2012
Mar 06
image/jpeg icondrupal-security-release_rgb-cc-by-nd.jpg

If you've ever wondered how the security of Drupal's core software and contributed modules is regulated, it might be interesting to check out this info-graphic as well as the Drupal Security Report - a downloadable white-paper.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web