Posts categorized: Security
I think many WordPress users probably underestimate the amount of data that is made available via the REST API. Just about everything is available to anyone or anything that asks for it: posts, pages, categories, tags, comments, taxonomies, media, users, settings, and more. For most of these types of data, public access is useful. For example, if you have a JSON-powered news reader, it can basically replicate your entire site structure virtually anywhere. But that easy access invites potential abuse. Just like with RSS feeds, RESTfully delivered JSON content is easily scraped and used for spam, phishing, plagiarism, adsense, and other foul things.
With each passing day, strong security becomes more important. This article explains some ways to keep WordPress secure while improving the overall security of your WordPress-powered site. Most of the tips provided here are practice-based security steps that require no plugins or hacks. The idea here is that you don't need to make changes to any code, or modify WordPress in any way in order to maintain strong security. These are security steps that most any WordPress user can use to help protect their site and keep WordPress safe and secure.
As discussed, it's important to protect your site by setting proper file permissions on the server. This can be tricky for certain directories such as
/backups/, which need to be writable by the server in order for things like uploads, upgrades, and backups to work.
When cleaning up hacked sites and testing .htaccess tricks, it's nice to have a list of WordPress directory and file names for checking patterns and finding strings directly via Search/Find. Especially when working remotely, having a complete list of WordPress files available online can help expedite the attack-recovery process.
One of my clients was hacked with the so-called "Cannot redeclare" hack. It seems closely related to the nefarious TimThumb hack, so if you've been hit by either of these hacks, you should check for the other. Apparently these hacks affect shared servers, so if you host multiple WordPress sites, chances are high that they're all infected.
Everyone loves a good comment. Readers benefit from the shared information and authors appreciate the conversation and feedback. But you gotta keep the spam out. Akismet and other anti-spam plugins do an excellent job of automating the process, but it's a good idea to watch out for false positives: legitimate comments marked as spam. Rescuing ham comments from the spam pile promotes healthy comment threads and improves the quality and reputation of your site. In this DiW post, we explain how WordPress & Akismet deal with spam, discuss anti-spam strategy, and share some ham-saving tips and tricks.
It sucks, but a lot of plugins require certain directories to be set at CHMOD 777 for its file permissions. Of course, you should not use any plugin that requires 777 directories, but if you absolutely must, you can help protect the folder by adding a thin slice of htaccess. This works great for any directory requiring "loose-ish" permissions (i.e., anything greater than 755), and may also be useful for other key folders as well.
During the recent book update, we needed to make some room for the new WordPress-3.1 content. The book is already over 400 pages and growing. So we have to make some hard decisions about which content is useful but maybe not needed in the book.
And, as useful as long lists of anti-spam plugins might be, moving them from the book to the blog seems like a good way to free up some room while keeping the information available. So without further ado, here is a quick list of 15 anti-spam plugins to help you run a more user-friendly, hassle-free comment system on your WordPress-powered site.
One of the awesome things about WordPress is that it’s a dynamic publishing system that uses a database to store your site’s information: posts, options, plugin and theme settings – all of this data is stored in your site’s database. It’s like the brain of your WordPress installation.
Unfortunately the WordPress database is also a prime target in many website attacks. Spammers and other bad guys target various database tables with automated scripts, SQL injection, and other malicious code. Needless to say it’s critical to protect your database and keep recent backups. One of the smartest ways to protect your site’s database is to change the default table prefix to something obscure and difficult to guess. Sort of like a password.
It looks like Media Temple WordPress installs have been hit with a WordPress Redirect Exploit1. We got hit here at DigWP.com, but have cleaned things up and are taking steps to prevent it from happening again. This post briefly explains the hack, and provides some steps that you can take to remove the payload and get back on track.
This article is split into two parts for ez reference. First some information on the evil WordPress “Pharma Hack”, and then a recipe for protecting your site with a solid security lockdown. Choose your own adventure:
Looking for a good book on WordPress security? If so, we’ve got great news! John Hoff’s new security e-book WordPress Defender provides 30 practical ways to secure your website from the evil forces of spam, bad bots, and malicious hackers. The book is packed with practical, common-sense security techniques that virtually any WordPress user can use to protect their site from malicious threats.
I usually reserve most of my blacklisting content for Perishable Press, but after posting about using WordPress’ built-in tools to stop comment spam, several DiW readers have asked about a good custom blacklist that may be used for the “Comment Moderation” and/or “Comment Blacklist” features in the WordPress “Discussion Settings” screen. Over the years, I have built up an extensive custom blacklist of terms that has proven quite effective at keeping spam and other garbage out of the comments section, even without using any anti-spam plugins such as Akismet. It’s strictly plug-n-play, and should help protect your site (and reputation) against all sorts of malicious nonsense.
Update: Media Temple is saying1 that:
- They aren't 100% sure of the cause, but yes, the hack is their fault.
- About 10% of all (gs) users were affected.
- It's not WordPress specific, it's PHP specific.
- Definitely change your passwords, definitely don't change it back to the original password.