Most common Drupal site building pitfalls and how to avoid them! (Part 2 of 3)

by David Snopek on March 21, 2017 - 11:24am

This is the second in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

And we've seen a lot of sites! Besides our clients, we also do a FREE in-depth site audit as the first step when talking to a potential client, so we've seen loads of additional sites that didn't become customers.

In the last article, we looked at security updates, badly installed module code and challenges ith "patching" modules and themes, as well as specific strategies for addressing each of those problems. In this article, we'll look at how to do the most common Drupal customizations without patching!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

Most common Drupal site building pitfalls and how to avoid them! (Part 1 of 3)

by David Snopek on March 14, 2017 - 3:44pm

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

Before taking on a new client, we do an in-depth site audit looking for security issues and checking if the site follows best practices or has any problems that would make it harder to maintain the site going forward.

In 2016 alone, we did 64 site audits!

Looking at that many sites has taught us A TON about the most common mistakes that people make when building Drupal sites. Some of them were very surprising to us as experienced Drupal site builders!

This is the first in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

Drupal 6 security update for Services

by David Snopek on March 8, 2017 - 12:41pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Highly Critical security release for the Services module to fix a Remote Code Execution (RCE) vulnerability.

The Services module provides a standardized solution for building API's so that external clients can communicate with Drupal.

The module accepts user submitted data in PHP's serialization format ("Content-Type: application/vnd.php.serialized") which can lead to arbitrary remote code execution.

This vulnerability is mitigated by the fact that an attacker must know your Service Endpoint's path, and your Service Endpoint must have "application/vnd.php.serialized" enabled as a request parser.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

NOTE: there's a pre-existing, unfixed security issue in the Drupal 6 version of Services from 2013 (see SA-CONTRIB-2013-051 - Services - Cross site request forgery (CSRF)), so using Services in Drupal 6 isn't recommended in general, however, that issue is much less critical than the one announced today.

If you have a Drupal 6 site using the Services module, we recommend you update immediately, or disable the Services module entirely.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

It's NOT Amazon's fault the internet broke yesterday - it's OURS!

by David Snopek on March 1, 2017 - 10:26am

You probably noticed that many sites and apps were having serious problems yesterday due to an Amazon AWS outage.

Some sites/apps were completely down, and others had partial or reduced functionality. In the Drupal world, Pantheon was affected: sites didn't go down (huzzah for Pantheon!), but everything was in read-only mode for several hours, so users couldn't upload files to their sites and many dashboard functions didn't work.

Already, many are talking about how this outage is proof that the public cloud is a bad idea. Or, that Amazon messed up big time and maybe we should look at other cloud providers.

However, I'm going to argue that it wasn't Amazon's fault that this outage took down so many sites and apps.

And by extension, this isn't proof that the cloud is a bad idea, or that we should look to providers other than Amazon. The cloud is great, and so is Amazon AWS.

I'm going to argue that it's OUR fault -- the web developers who make all these great apps and sites -- that this outage broke the internet.

Please read more to find out why!

Drupal 6 security update for Views

by Elliot Christenson on February 22, 2017 - 3:12pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Views module to fix an Access Bypass vulnerability.

The Views module allows site builders to create listings of various data in the Drupal database.

The Views module fails to call db_rewrite_sql() on queries that list Taxonomy Terms, which could cause private data stored on Taxonomy Terms to be leaked to users without permision to view it.

This is mitigated by the fact that a View must exist that lists Taxonomy Terms which contain private data. If all the data on Taxonomy Terms is public or there are no applicable Views, then your site is unaffected.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Views module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

My security resolutions for 2017! #SecurityResolutions

by David Snopek on January 31, 2017 - 11:58am

I'm a member of the Drupal Security Team, and many of the services offered by myDropWizard involve assisting our customers to improve the security of their Drupal sites -- so, I know quite a lot about security and try to be mindful about my own computer use.

However, computer security is an on-going process: it can always be improved and so you're never truly done.

In this article, I'm going to share my personal list of security resolutions for 2017!

Maybe you'll find something you'd like to implement as well?

Or perhaps you'd like to share your own security resolutions for this year?

Please share your thoughts in the comments (or on Twitter)!

Drupal 6 workaround for the highly critical vulnerability in PHPMailer

by David Snopek on December 26, 2016 - 5:45pm

You may have noticed that CVE-2016-10033 came out yesterday, which discloses an Remote Code Execution (RCE) vulnerability in the PHPMailer library which is used by popular contrib modules like SMTP or PHPMailer.

This is a highly critical vulnerability because Remote Code Execution means an attacker can run arbitrary code on your server!

Are you a spammer without knowing it? Beware the Print Mail module!

by David Snopek on December 13, 2016 - 1:52pm

One of the really interesting things about providing support and maintenance for lots and lots of sites is that you get to see patterns or certain issues affecting several sites, that you might not notice if you're only responsible for a handful of sites.

Not only does this add to our knowledge base of solutions when a customer has a problem, but it can sometimes allow us to preemptively find a problem before a customer even knows they have it (or point it out when we do a FREE site audit).

Anyway, here's a request we've recently gotten from a couple of customers:

Is our web site compromised?!

Our hosting provider says that we've been sending hundreds of e-mails a day that are setting off alarms with their SPAM filter.

Please help!!!!

It turns out that none of the affected websites were hacked -- it was just a matter of spammers taking advantage of a particular Drupal module: "Print Mail" a sub-module of Print.

It's not a security vulnerability - they're using normal features of the module, just at scale with automation.

If you use this module on any of your sites, or are considering enabling it, please read on for an explanation of the problem and some possible solutions.

Drupal 6: Are You Out of Time?

by Elliot Christenson on December 6, 2016 - 6:35pm

Do you still operate a Drupal 6 website? Are you getting questions from your management team, technical teams or even board of directors on pending upgrades? Are they afraid of the Drupal 6 "End of Life"? What should you do? What should you tell them? Read more to hear some brief thoughts on the big decision!

Elysia Cron on Drupal 6? Audit your permissions!

by David Snopek on November 30, 2016 - 2:07pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, a security update for Elysia Cron was released for Drupal 7 per the SA-CONTRIB-2016-062 security advisory.

All the update does is mark the permission to administer Elysia Cron as "dangerous" because it allows users to execute arbitrary PHP code. This is by design, it's an explicity feature of Elysia Cron - if it wasn't intended by the module authors it would have been a Remote Code Execution vulnerability. However, users might not be aware that permission grants the ability to execute PHP, hence the security advisory!

Unfortunately, there isn't a way to mark a permission as dangerous under Drupal 6. There isn't even a way to have seperate machine name and human-readable labels for permissions, so there isn't a straight-forward way to add a user visible message. :-(

So, the Drupal 6 Long-Term Support vendors (us included) have decided to simply announce the problem and ask anyone using the Elysia Cron to audit which users/roles have the "administer elysia_cron" permission and make sure it's OK that they can execute arbitrary PHP code.

We're going to be auditting the permission on our client's sites, so, if you're one of our customers - no need to worry! We'll contact you if we have any concerns.

If you'd like us to handle this and similar issues, as well as have all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Articles aggregated for consumption on Drupal Planet!

o