Category Archives:
Security Archives

Photo by Ricardo Viana on Unsplash

A WordPress site with web-facing forms will be spammed. If there’s a form to be filled in, it will be filled in by spammers, even when there is no clear motivation for doing so. Spammers register for membership of any site they find, they fill in forms for gated content, they submit fake email addresses that clutter mailing lists, they take surveys, and they bombard comment forms with gibberish and SEO spam.

Spam is more than an annoyance: it skews the data web-based businesses have available to them, lands the site’s domain on email blacklists when it sends mail to people who didn’t sign up, presents a security risk, consumes hosting resources, and makes a mess. All of which takes time and money to deal with.

I’ve discussed spam registrations and random form-filling with many WordPress users, and a common question is why do spammers do it? What benefit does the spammer get from signing up to a membership site or submitting fake addresses to a mailing list? It’s hard to work out from the point of view of site owners because often there is no real benefit to the spammers.

WordPress spammers hope to find sites that let them send spam emails, submit spam comments, publish spam posts, or to join the site as a prelude to a deeper attack. All of this web form spamming is automated. Simple bots scour the web for forms to fill in. It’s not difficult to automate the filling in of web forms: the bots are unsophisticated and the spammers aren’t skilled developers. Because bandwidth is cheap, it’s easier to spam every form than it is to be selective. So, if a form has an email field, they’ll put an email in it, a name field gets a name, and so on.

In many cases, WordPress sites are spammed as a side effect. If the site is properly secured, the spammers don’t gain anything, but they don’t lose anything either, and in the morally challenged mind of the spammer, that means building more sophisticated bots isn’t worth the effort.

All of which is interesting, but it doesn’t help WordPress site owners handle spam. The only way to stop spam data reaching databases is to implement systems that can distinguish between authentic submissions and junk — preferably without asking users to jump through hoops to demonstrate their status as a human being.

The best way to filter out spam today is Google’s most recent iteration of reCaptcha: Invisible reCaptcha. Old versions of reCaptcha asked users to carry out vision-based tasks that were easy for humans and difficult for machines. This system annoyed users and is based on an outdated assumption: in 2017, sophisticated machine vision is accessible, accurate, and inexpensive. Invisible reCaptcha uses a mixture of on-page behavior and data analysis to automatically categorize visitors as bots or humans in a way that is largely transparent to users. If you’re having WordPress spam problems, take a look at the Invisible reCaptcha for WordPress plugin.

Posted in:
Security, WordPress

Image by RLJ Photography NYC

There are lots of hacked WordPress sites on the web. Hacked sites are often the victims of botnets that brute force the login process, trying lots of different combinations of usernames and passwords until they hit one that lets them in. After they have access they can plant malware or other undesirable content on a site.

The success of this sort of attack has almost nothing to do with the security of WordPress itself and everything to do with the behavior of WordPress users. In principle, username and password combinations are a very safe way of securing a site. In practice, people don’t understand how to use passwords properly and value convenience over security. If they can get away with having “pa55word” or an equally guessable combination as their password, many will.

We can rail against this sort of complacency all we like, but as responsible site owners we just have to accept lax password security as a part of the landscape. Education helps, but not much; we need to implement other mechanisms for ensuring that our sites don’t fall when the botnets come knocking.

Usernames and passwords work because the number of possible combinations is enormous. For a sufficiently long, complex, and random password, it would take even the most powerful computer many years to hit on the right combination. For a sufficiently simple password, it can take fractions of a second. If users aren’t willing to use random and complex passwords, the solution is to implement another verification mechanism — a second factor – that will ensure the chances of guessing a valid combination remain remote.

There are various ways of implementing two-factor authentication — biometrics such as fingerprinting are one, but that’s more complex to implement than the method I’m about to suggest, one-time passcodes.

Unlike a password, a one-time passcode works for a short amount of time, usually about 30 seconds. The TFA service and the user share a secret — frequently a long string of numbers — which is used in combination with the time to create a unique passcode known to the TFA service and the user without it ever having to be communicated between them. It’s much safer than using passwords alone and because the choice of passcode isn’t up to the user, they can’t circumvent security by using an easily guessable combination.

The typical scenario would go as follows: the user wants to log in to your WordPress site. They enter their username and password, after which they are asked for a further passcode. They will have an application from the TFA service provider installed on their smartphone or a dedicated device, which will generate a passcode that can only be used for a short time. When they enter the passcode correctly, they are logged in.

There are a several good TFA services that integrate well with WordPress, but I’m going to suggest you take a look at two: Duo Security and Authy 2FA.

If you run a multi-user WordPress site, particularly if you have several admin users, implementing two-factor authentication will make it almost impossible for casual brute-force attackers to successfully breach your site. It’s well worth the minimal effort to avoid the risk of becoming a vector for malware or a hacker’s playground.

Posted in:
Security, WordPress

A WordPress site is made of files. Database aside — which is a special set of files — everything else is a chunk of data stored on the server’s file system. That includes content like images and the executable PHP files that comprise WordPress Core, themes, and plugins.

It’s vitally important that only the right people and programs — represented by user accounts on the server — have access to those files. If every user on a server has access to all the files, there’s no end to the mischief they could make, and that’s before considering unauthorized users like hackers.

If you just want to know about sensible permissions for your WordPress site’s files, skip to the last paragraph. If you want to understand how permissions work, read on.
Most WordPress sites run on Linux servers, and the Linux operating system has a permission mechanism that controls who can read from, write to, and execute files. It’s useful for WordPress users to understand how these permissions work, because assigning the wrong permissions can leave a site open to security problems or stop it working altogether.

The permissions are stored as attributes. Each file has attributes for its owner, group, and everyone else.

Owner, Group, The World

The owner is a single user account on the server. The user account doesn’t have to be associated with a particular person: user accounts are often created for programs (the web server owns some files, for example) and the root user automatically has permission to do anything with any file.

In addition to belonging to a user, a file also belongs to a group. A group is a set of user accounts that can be given permission to interact with a file. For example, you might have a group of user accounts who can write to a file, but only allow the owner to execute it.

Finally, there’s the “world” or everyone else on the server, which allows for the setting of permissions that cover all user accounts.

Each of these types of user — the owner, group members, and the world, can have three levels of access: read, write, and execute. So, a file might have permissions that allow the world and the file’s group to read and write to it, but only allow the owner to execute it.

There are two ways file permissions are displayed. You’ve probably come across notations that look like 744 or drwxrw-rw-. Let’s look at the last of these first. It’s easy enough to understand if you’ve followed what we’ve talked about so far. The first letter (“d” in this case) represents access modes for the file, which we’re not going to get into here.

The rest of the string — rwxrw-rw- — is split into groups of three, with each triplet referring to the permissions of the owner, the group, and the world respectively. In our example, the owner has read(r), write(w), and execute(x) permissions. The group has read and write permissions, and so does the world.

Now to the other notation, which is the one you’re most likely to see in articles discussing WordPress. If we take 744 as an example: the numbers refer to the owner, group, and world permissions. The 7 is for the owner, the first 4 for the group, the second for everyone else.

Each of those numbers represents read, write, and execute permissions. No permission is worth 0, execute permission is worth 1, write permission is worth 2, and read permission is worth 4. Adding those numbers together gives you the permission for each of the sets of users.

This can be hard to get your head around, but it makes sense after seeing a few examples. Consider 744. The 7 is for the owner, and the only way to get a 7 given what we’ve seen is to add execute(1), write(2), and read(4) together. The second number — the group permission — is 4. That has to be a read-only permission. If, for example, it was a 6, it would indicate read(4) and write(2) permissions.

The permissions on files can be changed from the command line using the chmod utility. You can look at chmod’s manual page for full details, but to set a file’s permissions to 766 you’d run this command:

chmod 766 file.php

Finally, which permissions should your WordPress files have? The best defaults are 775 for directories and 644 for files. I haven’t really discussed directory permissions here, but the the basics principles are the same. These are are relatively safe defaults, providing file ownership permissions are properly set, as is discussed in the WordPress Codex.

Posted in:
Security, WordPress

One of the WordPress ecosystem’s most attractive features is its endless variety of themes. Thousands of developers have created tens of thousands of themes, many of them free. There’s almost certainly a theme in the official repository or premium marketplaces to suit any style or functional requirement.

For the most part, that’s a good thing, but finding and choosing the right theme from the thousands available is no easy task. Developers and designers range from the slipshod to the expert, and themes vary in quality accordingly. In addition to which, developers are incentivized to create themes and demo pages that look incredible, but that can prove disappointing in real-world use.

It’s useful for WordPress users to have a simple set of questions they can ask themselves before choosing a theme. At the risk of being negative, I want to focus on reasons a user shouldn’t choose a theme. Rejecting themes is an essential part of the process of selecting the right theme, so let’s take a look at three red flags that cause me to walk away.

It’s Slow

A fast website depends on two fundamental components: performance-optimized hosting and a speedy front-end. There’s a lot a theme can do to make a site slow even if it’s hosted on the fastest server. In fact, some of the most feature-rich and impressive themes are guilty of this: the demos look awesome, but that’s because they’re packed with so much poorly optimized JavaScript that site visitors are left twiddling their thumbs.

Respected designer Ethan Marcotte tested a number of prominent theme demo pages, and found them to be unacceptably slow, particularly on mobile devices. Some of the themes he tested took 90 seconds to load. If you want a front-end that doesn’t embarrass your back-end, run demo pages through a performance-testing service like WebPageTest or Pingdom tools before you install the theme on your site.

It’s Old

When I choose a WordPress theme, I expect to be able to use it for a couple of years at least. I want to be confident that a theme will be maintained and updated while I’m using it. I don’t want to be stuck with a theme that is incompatible with the most recent versions of WordPress.

Of course, there’s no guarantee that a developer won’t abandon a theme a month after I start using it, but I automatically reject any theme that doesn’t have a pattern of regular updates. If it’s a new theme without much of a history, I take a look at the developer’s other themes to see how often they are updated.

Poor Customer Support

Finally, I take a look at the developer’s support channels to see how responsive they are to support requests. This is especially important for premium themes — if I intend to use a free theme then I’m willing to accept that the developer doesn’t owe me anything, including their time. But if I pay for a theme, I want to see evidence that the developer quickly and politely responds to support requests. If I visit their support forums and the only thing moving is a tumbleweed, I’m likely to look elsewhere.

There are thousands are elegant, feature-rich themes available for WordPress, created by talented developers and designers who care about giving their customers the best possible experience. If you know what you’re looking for (and what to avoid) you’ll have no trouble finding a great-looking theme that you can rely on for years to come.

Posted in:
Security, WordPress

Many WordPress users were disappointed to hear that two-factor authentication provider Clef is shutting down. Clef was popular with WordPress site owners because it let them add an extra layer of security to their site without the complexity associated with other two-factor authentication systems. With over a million installations, the loss of Clef was a serious blow to WordPress site owners.

In March, the team behind the UpdraftPlus backup service announced that they planned to step into the space vacated by Clef. Their brand new two-factor authentication service, Keyy, is now live, and it has many of the same features as Clef.

For those who are unfamiliar with two-factor authentication, it allows site owners to demand an identifying credential in addition to the usual username / password combination. Username and password combinations can be very secure, but in the real world they tend to be a liability. Users often fail to choose a secure password, they may use the same password on more than one site, or otherwise make the life of criminals easier than it should be.

To take a common example, simple passwords can often be quickly cracked by brute-force bots. Many WordPress sites are compromised because an admin user picked “pa55word” as their password, or an equally guessable combination.

The second factor of authentication is typically associated with an item in the possession of a user: a smartphone or dedicated device that displays a one-time code. In addition to their username and password, the user has to enter the code presented to them by the authenticated object in their possession.

It’s much harder for attackers to compromise a site using two-factor authentication, but many users find the process of logging in with two-factor authentication overly burdensome. Clef, on the other hand, was supremely easy to use, as is Keyy.

With Keyy, users don’t have to enter usernames, passwords, or one-time codes. Instead, when they are ready to log in, users are shown a graphic which they scan with the Keyy app on their phone. Keyy works in essentially the same way Clef did. The app on the user’s smartphone creates a public key pair, the private part of which remains on the device, while the public key is shared with Keyy’s server. When the user wants to log in, the Keyy service generates an image tied to the session. The app scans that image and signs it with the private key before sending it to the Keyy servers, which verify the user has possession of the private key and logs them in using OAuth.

Clef provided other services like single-sign on, which aren’t available yet with Keyy, but the company plans to launch an SSO service in the coming months.

It’s worth mentioning that Keyy is a very new service, and it may be subject to the occasional glitch as the team works out the kinks. But it’s great to see an established and sustainable WordPress company with a track record of successful WordPress services step up to provide such an important security service.

Posted in:
Security, WordPress

It has recently come to light that several critical vulnerabilities were fixed in the Avada theme in April, although ThemeFusion, the developers of the theme didn’t widely announce the patched release until several weeks later. If you use the Avada WordPress theme on your site, you should upgrade to Avada 5.1.5 as soon as possible.

The Avada theme is among the most popular themes on ThemeForest, and its developers boast that it’s been the single most popular paid WordPress theme for four years in a row. That means tens of thousands of sites could be vulnerable until they update to the most recent version.

It’s unusual for a developer to release a fix for a known vulnerability and then to decline to publicize it. Although information about the patch was available in the release’s changelog, it’s unlikely that many of the theme’s users avidly read changelogs.

Typically, a developer wants as many people as possible to update as soon as possible when a security vulnerability is discovered, although they may choose not to disclose the exact details of the vulnerability. The average user may not scrutinze changelogs, but it’s a fair bet that hackers and criminals do, which means there’s little benefit to keeping quiet about the existence of a security problem.

But regardless of the wisdom of waiting, a full explanation of the vulnerabilities along with code examples is widely available now. The smart choice is to update all sites using the Avada theme before they’re targeted.

The details of the vulnerability can be read about on WordPress Hütte, but the nutshell version is that several cross-site scripting and cross-site request forgery vulnerabilities were discovered by a security researcher. Both are common critical vulnerabilities in web applications that can potentially be used by an attacker to take over a WordPress site or exfiltrate private data.

We’ve discussed cross-site scripting vulnerabilities on this blog before because they’re the number one security problem on the web. Cross-site scripting is caused by a failure to properly sanitize user input. The protoypical cross-site scripting attack occurs when an attacker submits code to a web form and that code is displayed somewhere on a web page without being rendered inert. When a browser loads the page, it executes the code, which is very bad news if the browser belongs to a user with admin privileges.

Cross-site request forgeries are a little more involved, but — as with XSS attacks — they can be used by an attacker to execute arbitrary code in the trusted context of a browser. Attackers often use CSRF vulnerabilities in conjuntion with social engineering attacks or phishing attacks against existing trusted users to make sites perform an action, like create an admin user with a password the attacker knows.

In conclusion, upgrade Avada now, because it won’t be long before hackers start looking for sites they can exploit with these vulnerabilities.

Posted in:
Security, WordPress