by David Snopek on October 5, 2015 - 9:09am

Every Wednesday, the Drupal Security Team publishes "Security Advisories" (or SA's) to tell users about security vulnerabilities in Drupal core and contrib modules, with advice on how to solve the issue so that their site is secure.

This is the second in a series of articles about how to better understand all the information in a security advisory, so that you know how to take the appropriate action for your site!

There are several different types of security vulnerabilities, each with a cryptic (and highly technical) name like Cross Site Scripting (XSS) or SQL Injection.

There's plenty of technical articles on the internet explaining what those mean from a coder perspective, including how to prevent them (by writing better code) or even how to exploit them.

But what do they mean for you, the site builder or site owner?

The most important question for you is: If an attacker exploits your site with a particular vulnerability, what will they be able to do to your site or users?

Of course, you should take action on any security advisory that affects your site as soon as possible (or hire someone else to do it). But what could happen if you didn't?

Some vulnerabilities would allow an attacker to completely take control over your site, whereas others would only allow them to access some non-public data. How can you tell which are which?

Read more to learn how the different vulnerability types could impact your site or users!

How to find the "Vulnerability" type

At the top of every Security Advisory, there a number of standard fields. Today, we're looking at the "Vulnerability" field:

A Security Advisory with the "Vulnerability" field highlighted

The "Vulnerability" field from SA-CONTRIB-2015-152

The vulnerability type is also called out in the title of the security advisory.

What does each vulnerability allow the attacker to do?

If the vulnerability were exploited, the attacker would be able to ...

Get complete control of your site

If an attacker can gain complete control over your site - all bets are off! They could:

  • Delete all your content and replace it with porn
  • Get the e-mail addresses and password hashes for all your users and start trying to crack them (which means sending an unpleasant e-mail to your users in case they reused the same password for their bank, for example)
  • Try to infect your visitors' computers with viruses
  • Use your server to attack or take down other servers (as part of a "botnet")

And since there's no telling what they could have done or changed, or what backdoors they left for themselves, the only 100% safe way to remediate your site is to restore from a backup that was made before the exploit. :-/

So, what vulnerability types, if exploited, will give attackers complete control of your site?

The infamous Drupalgeddon vulnerability was SQL Injection, which is why that issue was so dangerous.

Also, it's important to know that you can create your own Arbitrary PHP code execution or SQL Injection vulnerability (or make it easy to escalate a lesser vulnerability) just by configuring your site badly! For example, you should never have the PHP module (included in Drupal 7 core - removed in Drupal 8) or the Devel module enabled on a live site.

It's highly recommended to use the Paranoia module, which can make these types of bad configurations difficult or impossible!

In any case, it goes with out saying that you should take any SA with one of these vulnerability types very seriously.

Perform actions as other users

The next most serious types of vulnerabilities, are those that allow attackers to perform an action on your site as other users. This includes:

  • Cross Site Scripting (XSS): This is currently the most common type of vulnerability in Drupal 7 modules and themes (it'll be much harder to write bad code that allows this type of vulnerability in Drupal 8)
  • Cross Site Request Forgery (CSRF)

Both vulnerabilities require the attacker to get the user to visit a particular URL, but this is easier than you think!

If the attacker injected their special code into a comment (via XSS), an administrator is likely to read the comments at some point to see what people are saying. Or if not, the attacker can e-mail an administrator and tell them there's spam, or porn, or cute kittens at that URL or something.

And as soon as an administrator visits that URL, the attacker's script will be able to silently perform whatever actions they like as that administrator, including granting themselves administrator access!

This is why having the PHP module enabled is so dangerous. Even if only administrators have permission to use it, an attacker can use XSS (a super common vulnerability) to escalate to an Arbitrary PHP code execution vulnerability (a rarer vulnerability).

Between the two vulnerabilities (XSS and CSRF), XSS is generally more powerful because the attacker can do anything the user can do, where as with CSRF they are limited to the actions which lack CSRF protection.

I'd recommend also taking these types of vulnerabilities seriously!

Perform actions they don't have permission to

An Access bypass vulnerability allows an attacker to perform some action that they shouldn't have permission to, according to the permissions assigned to them.

The level of risk depends heavily on:

  • What that action is? Is it just viewing non-public information? Or can they delete, edit or create things?
  • What sort of data do you have on your site? Is it all public data anyway? Or do you have any confidential information?

You'll need to read the security advisory carefully to determine how this impacts your site.

Take down your site

Denial of Service (DoS) vulnerability allows the attacker to easily take your site or server offline.

While it's generally possible for an attacker to take your site down using a Distributed Denial of Service (DDoS) attack even without any vulnerability (unless you use a CDN like CloudFlare), that requires having a botnet to access your site from many computers at once.

With simple DoS vulnerability, an attacker can do it with much less effort, possibly only accessing your site from a single computer.

If you run an e-commerce site or similar type of site that needs to remain online in order for you to make money, then a DoS vulnerability should be taken very seriously!

Send your users to malicious sites

An Open Redirect vulnerability allows the attacker to send your users to an arbitrary URL without them necessarily knowing that they've been redirected.

An enterprising attacker could then create a malicious site that looks just like your site, but all the information is submitted to them rather than you!

This is particularly dangerous for e-commerce sites that allow submitting credit card information!

But it could be used to gather e-mails and passwords on any site that allows users to log in.

Access non-public information

An Information disclosure vulnerability reveals non-public information or information intended for another user.

Sometimes the information that is disclosed isn't valuable in it's own right, but allows the attacker to learn more about your site or server in order to find another vulnerability.

You'll need to read the security advisory carefully and determine how sensitive the revealed information is in the context of your site.

Keeping your site secure!


After all that, I wouldn't blame you if you were a little more scared about your site's security than before you read the article. :-)

There may have been ways that attackers could damage your site, or harm your users that you hadn't even considered.

However, now that you know what the different vulnerability types mean, hopefully you'll be able to make more informed decisions in order to keep your site secure!

Don't want to worry about making security updates yourself, but still want your site to be secure? You can hire to take care of security updates for you! Contact us for more information!

Want to read more articles like this? blog Subscribe to the blog and recieve e-mail updates when new articles are published!

Add comment