by David Snopek on March 28, 2017 - 9:58am

This is the third 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 first 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 the second article, we looked at how to do the most common Drupal customizations without patching.

In this article, we're going to look at some common misconfigurations that make a site less secure, and how to avoid them!

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 ;-)

5. Insufficient filtering on text format

Security is more than just updating modules when security releases come out.

It's possible to inadvertently create security vulnerabilities in your site, just through bad configuration!

One of the most common examples is creating a cross-site scripting (XSS) vulnerability by not putting sufficient filtering on text formats that can be used by untrusted users.

Let's unpack that...

What is Cross Site Scripting (XSS)?

This is the most common security vulnerability in Drupal. Most of the security advisories that you see come out on Wednesdays are to fix XSS vulnerabilities.

Basically, if an attacker can put <script> tags into content that will be viewed by other users, they can perform actions on your site as those other users. So, if they manage to get an admin user to view the <script> tag they added, they can do anything the admin user can do!

There's developer APIs for module authors to filter user input so that XSS isn't possible, but if the developer doesn't use it or uses it incorrectly, it can open up a vulnerability.

What is a text format?

At many of the places in Drupal where a user is creating content, they get a text box where they can choose the "Text format", for example:

Screenshot showing the Body field and pointing out the Text format selector

This controls how the text you entered is turned into HTML that's displayed by the web browser.

The text format could allow entering raw HTML, use a WYSIWYG editor, or use some other type of text markup format (ex. Markdown). The text format configuration allows you restrict which resulting HTML tags (like <script>) the user is capable of creating.

When building a site, you can create multiple text formats for use in different situations or by different user roles. So, Comments could allow users to enter Markdown but when creating content get a WYSIWYG editor. Or, administrators could use "Full HTML" and normal users only get "Restricted HTML".

What is an untrusted user?

When raising this issue with our customers, many of them believe that all of their staff members' accounts should be "trusted users" because they trust each of their staff as people. And so, they give them access to potentially dangerous text formats.

However, trusting a user also means that you trust their choice of password (and that they didn't reuse the same password on another service!) and that they use their computer in a secure way. You may trust someone personally, but they might have a virus on their computer that's watching their keystrokes and stealing all their logins and passwords.

Unless you have a stringent security policy that applies to all of your staff (and it's actively enforced!), you probably shouldn't consider all your staff's accounts to be trusted users.

What should I be careful about?

The two most important HTML tags that you need to worry about are <script> (allows XSS) and <img> (allows CSRF), but there's also several HTML attributes that allow Javascript (like onclick="...").

Those should all be filtered out on any text formats that can be used by untrusted users!

Screenshot of text format edit screen where you can choose the allowed HTML tags

You should also be sure to review which user roles have permission to use any text formats that don't filter them out, and evaluate which users have those user roles. You might have to split some roles into two roles to seperate "normal administrative activities" from the ability to use dangerous text formats.

6. Unsafe file extensions

In Drupal, you can add a File field to any content type. Each field can have a different set of allowed file extensions.

Similar to the last point, allowing untrusted users to upload files with certain extensions can open an XSS vulnerability!

Screenshot showing the allowed extensions configuration for a File field

The unsafe extensions include: HTM, HTML, JS or SVG. Basically, any file extension where the web browser would execute Javascript would allow XSS!

7. PHP in the database

To the more experienced Drupal site builders that may be reading this article: this is waaaaay more wide-spread than you think it is!

In short... If you're thinking about typing some PHP code into the Drupal admin interface somewhere: DON'T DO THAT! :-)

Even having modules installed that allow admin users to enter PHP code can allow attackers to exploit lesser vulnerabilities and escalate to a Remote Code Execution (RCE) vulnerability. Remember, XSS vulnerabilities are the most common, and they allow an attacker to perform the same actions as another user. If your admin user can execute PHP, than an attacker can do it too via XSS!

But beyond the security issues, PHP code that is saved in the Drupal database is hard to maintain and easy to break. It can also lead to site "magic" which is difficult to even find in order to fix or change it later.

Recommendations?

  • On Drupal 6 & 7, disable and remove the PHP module (doesn't exist on Drupal 8!) or any other module that allows PHP in the database. Or you could use the Paranoia module that prevents any such modules from being enabled, or disables the features in modules that allow entering PHP as part (but not all) of what they do.
  • Find a module to do what you want - there's lots (~20k)! Many beginning site builders might be using PHP code simply because they don't know that there's a module for what they want. This is a big part of the Drupal learning curve: just learning what's out there! Take a look at some of the big, mainstays of site building like: Panels, Views, or Rules
  • If there's no module and you really need PHP to do something in PHP... Guess what? You're a developer now! ;-) It's time to learn how to write proper Drupal modules.

How to become a Drupal developer?

This is an enormous topic! It'd take several more multi-part articles to cover, so I'll just give a couple resources here to get you started:

Conclusion

If you haven't already, please check out part 1 and part 2 of this series! This concludes the 7 most common pitfalls that we've seen when looking back over the site audit reports we sent out in 2016.

Have you encoutered Drupal sites that include any of the pitfalls discussed above? Are there any other important examples that you've encountered when building a Drupal site or reviewing a site built by someone else? Please write a comment below!

Or, if you'd like us to audit your Drupal site, please contact us about a FREE site audit!

Want to read more articles like this?

myDropWizard.com blog Subscribe to the myDropWizard.com blog and recieve e-mail updates when new articles are published!

Comments

Really helpful information for me as i am an intermediate drupal developer.

One request, can you share pitfalls for Drupal 8 vs Drupal 7 and vis-a-vis too. That will help me choose the right one for my project.

Thanks

Thanks!

All the same pitfalls apply to Drupal 6, 7 & 8. If you think you can do your project with either Drupal 7 or 8, do it with Drupal 8! At this point, I'd only build a new project on Drupal 7 if you needed something that wasn't available for Drupal 8 yet.

I hope that helps!

The addition of Twig and automatic auto-escaping of variables passed to Twig templates will greatly reduce the number of XSS vulnerabilities on D8. Plus the removal of PHPTemplate means you have to work hard to do something stupid in your template files. In my opinion, the Drupal's front-end is much more secure in D8 than in D7.

WORTH REPEATING ONE MORE TIME

If your admin user can execute PHP, than an attacker can do it too via XSS!

Add comment