I had the pleasure to speak at this month’s Pint Sized Marketing in Dublin. If you’re an SEO in Ireland, or just need an excuse for a quick trip to Dublin, Pint Sized Marketing is a very worthy free event to attend run by the same organisers as the must-see Irish marketing conference Learn Inbound and features very interesting talks from some of the brilliant speakers – just check the previous podcasts to get an idea.
Anyway, here’s a recap of my talk for those who did not attend or would like to refresh it in their memory. The slide deck is embedded below.
Why You Should Care About Security
Talking to a room full of SEOs and marketers, why would I choose a topic related to security? Not just because the GDPR requires you to bear responsibility for your site’s security, although that’s an important point to keep in mind as well. Because it’s not just Internet security professionals who should care about the security of your WordPress site, especially since WordPress powers sites of small businesses who do not have dedicated security staff to take care of them, and many decisions leading to security issues are taken by non-technical staff. Yet, the consequences can be ruining to your SEO efforts as much as to your server infrastructure.
Have you ever noticed your site get a spike of traffic out of the blue, only to discover the keywords it now ranks for and gets traffic have nothing to do with your site’s original idea? Congrats, most likely you’ve been hacked. There are many reasons why sites get hacked, including but not limited to creating parasite pages on third party domains, which is something we most often see in the SERPs and unrelated traffic/rankings.
Hacked sites appear in the SERPs quite often, especially for spammier, high-competition queries (e.g. anything pharma-related), and in many cases they are not even marked in the SERPs as hacked sites, because they start ranking sooner than Google figures out they are hacked. Technically, there is a dedicated security issues report in Google Search Console, but often by the time you see anything there, it is too late. You will likely know you’re hacked from sudden spikes of traffic and rankings for unrelated keywords.
Yet, Google’s Webmaster Guidelines clearly hold website publishers responsible for timely discovery of hacking attempts on their sites and cleaning up the results of hackers’ activity. So yes, as a site owner, you are the only person responsible for your site’s security. Below are some things you should be aware of to stay on top of the security issues.
The amount of known vulnerabilities keeps increasing every year. 2018 has seen the record high number of new reported vulnerabilities. In the first few months of this year, the amount of vulnerabilities discovered has already exceeded that of the whole year 2004. There are different kinds of vulnerabilities out there, targeting different systems and products, aiming to achieve different results in the interests of those exploiting the vulnerable systems. There is a constant race between the software developers and hackers to discover new vulnerabilities and exploit them – and patch known vulnerabilities to improve the software security.
Any minute, there are countless attempts to hack your own site you are not even aware of – to get a glimpse of what’s really going on, you could check your server logs for all the requests resulting in 404s – many of those will be scanning attempts to discover if your site uses any of products or scripts with known vulnerabilities. However, most likely that’s not anything personal against you or your site – it’s a bulk attempt at a popular platform. An estimated 1/3 of the internet is powered by WordPress, so this makes it a very popular target. If a hacker discovers a vulnerability applicable to the whole platform, they automatically gain access to all sites powered by it and that’s a huge payout for their efforts.
WordPress is also an interesting target because of how it’s built. There’s the core CMS code, but on top of that there are plugins and themes used by sites powered by it. It’s like you’re building your site out of a bunch of shiny, bright Lego blocks – or choosing your poison out of a bunch of available flavours, because each and every one of these components can have a vulnerability of their own!
“The larger the system, the greater the probability of unexpected failure”, says one of the laws describing the principles of complex systems. Among known WordPress vulnerabilities, some target the core code, while others affect various plugins. Even the best known and most popular plugins are not invincible – infact, the fact that they are popular makes them a more interesting target for hackers. Ironically, even Wordfence, a plugin designed to protect WordPress sites, has a history of vulnerabilities! It is of course down to the developers’ proactive attitude and fast action to help protect their users as soon as possible after the vulnerability has been discovered.
For those interested to learn more about plugin vulnerabilities and what they can lead to, here are a couple of links:
- Recent incident with a popular plugin doing stuff it was not supposed to do at all
- An older story about another popular plugin, this one is interesting because it affected not just standalone plugin installations but also many themes using it
The Problem With Plugins
Most WordPress users are getting their plugins from WordPress.org plugin directory – it sounds like an official source would be the most secure, right? What not many WordPress users are probably aware of is that once a plugin is approved for the directory inclusion, nobody ever checks it any more. Should the developer update their plugin, the update will not be checked. Moreover, there is no requirement for developers to update their plugins for future WordPress versions compatibility or patching known vulnerabilities. Despite the fact you downloaded the plugin from the official plugin directory, nobody bears any responsibility for what that plugin can do to your site. Even with paid plugins, you get no guarantees whatsoever. Moreover, if a popular plugin with thousands of installed instances gets purchased from the original developer by somebody with malicious intent, and that person gets control over the sites running the plugin and does whatever they want with those sites, you can’t really hold anyone responsible. It’s also important to note that while you can easily update a standalone plugin should there be a patch release to fix a discovered vulnerability (or even disable it if there is no patch), you cannot easily do so with plugins used by themes – so if you’re using a theme which uses a vulnerable plugin, you’re at the mercy of the theme developer to update their theme with a secure new version of the plugin and roll out the theme update for you.
So what’s a website owner to do?
1. Only use plugins you ABSOLUTELY need. So many things could be accomplished without using a plugin, by a simple tweak of the code – if you know at least a little bit about PHP there is no excuse to use plugins for those things, that’s just a lazy approach. Case in point: When WordPress rolled out Gutenberg, everybody seemed to hate the new interface, and somebody jumped on the opportunity and released a plugin to disable Gutenberg. That’s really helpful and I’m sure many people appreciated the quick solution – only, the same can be easily achieved with exactly one line of code added to your functions.php file:
2. The less plugins you have, the better – you are reducing the complexity of your system, thus reducing the number of possible vulnerabilities. I have never understood the need for the search box to search installed plugins – if you have to search to know what plugins you have installed, you clearly have a problem.
3. Remove unused plugins to reduce the clutter, this will benefit your site speed too. If you have inactive plugins you don’t need, remove them too – the only reason why you might want to keep an inactive plugin for some time is in case you’ve been hacked and you need to preserve things the way they are for further investigation.
WordPress Themes and Security
If you are choosing a theme for your WordPress blog, only use themes from reliable sources. As tempting as it might seem to use a hacked version of a paid theme, this is just asking for trouble. However, even if you are using a paid theme, and/or a theme that comes from the official WordPress.org theme directory, same warnings apply as to the plugins above. No developer is insured against vulnerabilities in their theme, or using plugins which at some point may become vulnerable.
Hence, the next important point is whatever theme you choose, you should be aware of all plugins it uses. If you are aware of a vulnerability affecting a plugin used by your theme, demand a theme update.
Also, and this can’t be stressed enough, keep a clean copy of your theme somewhere safe – i.e. not on the same server as your site, preferably keep an offline copy. This is especially important for custom developed themes. If your site gets hacked, it will be extremely difficult to restore it without a clean theme copy.
User Accounts and Access
How many users have access to your WordPress site? Do all of these users need to have access? Do all of these users have the level of access they absolutely need? WordPress has an option for anyone to register as a user – while some sites need this, most do not – check if it’s enabled on your site. Also, if it is enabled and you need it, what is the default role assigned to the new users? The less users have access, and the less access level each user has, the safer your site is.
Ideally, there should be only one administrator user, and their role should be to only administrate the site, not to post content. Set separate users for posting.
Also, the admin user created during the installation of a WordPress site normally has the user ID of 1 in the WordPress user database. By knowing the user ID of the admin user, hackers can potentially have an easier job getting the database and site access (e.g. via brute force attacks). What you could do as a little security-by-obscurity measure is change the default user ID of your admin user to some random number – this can be done via running an SQL query and changing the ID in two tables: users and usermeta (three tables if your admin user has been posting any content – posts table as well in this case). While doing this, pay attention to your actual database name (by default it is wp, but some WordPress installers use their own security-by-obscurity tactics and replace the default database name by something random like wpds – that’s actually helpful) and the correct syntax of your version of SQL.
Other Security Measures
Check regularly if everything you have installed (WordPress Core, themes and plugins) is the latest version and if that latest version is secure. Monitor for any newly discovered vulnerabilities affecting everything you use. There are a number of useful resources for that, for example CVE Details or Shodan Exploits database. Sometimes, it’s enough to just use a search engine and search for the name of a plugin + exploit or vulnerability to find some relevant information.
WPScan is a very helpful command line tool to scan any WordPress site for installed plugins and see if the installed versions have any knows vulnerabilities – the tool’s database keeps track of them. If that’s a bit too technical, there is a simpler solution in the form of an online site scan by Sucuri.
However, here’s a word of warning regarding Sucuri or any other external scanning tool: it can only see so much from the outside! If it reports your site as clean, it does not 100% guarantee that it is indeed clean. In the meantime, Sucuri is a great firewall solution I can recommend as an extra protection measure for any site as they are good at stopping possible hacking attempts even for sites which use vulnerable software by blocking requests to the elements the hackers may try to interact with to invoke the vulnerability.
If My Site Uses SSL Is It Secure?
Many people believe if their site uses an SSL certificate it is invincible and cannot get hacked. That is not true. An SSL certificate is responsible for the traffic accessing the site via a secure protocol (HTTPS as opposed to HTTP), but this has nothing to do with sites getting hacked. Sites using SSL can get hacked as much as sites not using SSL. Infact, all 3 hacked domains in our initial pharma SERPs example are on HTTPS, although in one case SSL is not implemented correctly. It is worth noting that more harm than good can come from an incorrect implememntation of SSL, hence it is a good idea to check your SSL implementation every once in a while (this concerns not only WordPress sites but any other platform as well). Also, remember that your SSL implementation is only completely secure if you consistently link to secure external resources only.
Most important takeaway of this talk: always have a clean backup of your site, this will save you a lot of headache if your site gets hacked. Make a clean backup today, store it safely and make new backups regularly, depending on the frequency of your site’s updates.
While the course of actions in case your site gets hacked is beyond the scope of this talk, here are some power tips which can clue you about the fact you got hacked if/when it happens:
- Do you see any unusual URL requests in your server logs?
- Do you see any unusual URLs reported by Majestic as indexed or linked to?
- Do you see any unusual queries, URLs or crawl errors in your Google Search Console?
Any of the above is not necessarily a sign of a hacked site but most certainly should prompt you to dig deeper and investigate.