A vulnerability in the W3 Total Cache plugin was revealed Christmas Eve. It’s one that site owners who use the plugin need to take seriously and get fixed. Plus, another recent report on the real speed improvements has been released and, for me, call into question whether using such a plugin is worth the potential risk and hassle. See what I found in these two reports and more, and then decide for yourself.
The initial report of the W3 Total Cache plugin vulnerability came from Jason A. Donenfeld on SecLists.org. He said, “Directory listings were enabled on the cache directory, which means anyone could easily recursively download all the database cache keys, and extract ones containing sensitive information, such as password hashes.” He was even kind enough to provide the script to do it.
The Problem
In non-geek terms, that means hackers, or anybody really, can easily run a little script and grab the encrypted info that contains passwords. It’s VERY easy to decrypt those keys. In fact, there are free Web apps that do it. I’ve used them myself to recover passwords for clients.
The Fix
Jason’s post was picked up and further explained by Daniel Cid on the Sucuri blog, which is very popular and brought everyone’s attention to the problem on Christmas day.
Daniel also provided more info on the fix, which is to install a new .htaccess file in the plugin’s directory to deny access. It’s easily done, if you know what you are doing.
In the initial report, Jason suggested that the plugin itself should be creating this change, which may happen now that this security issue has been widely reported. Then again, the plugin’s page states that it is only compatible up to WordPress version 3.2.1 and hasn’t been updated since August 2011. So, don’t hold your breath, and consider hiring someone like me to fix it if you don’t know how. Better yet, consider getting rid of the plugin. Here’s why.
Is it Really Faster?
Craig Grella has a post on WPMU.org titled 2 Plugins to Put Your Site in the Fast Lane that’s going to fall into my Really? pile. He cited an Amazon study that showed a 20% traffic loss on pages that loaded a half second slower than others. He ran speed tests on his site and found that W3 Total Cache made his site load 7% faster, which equated to 300ms. That’s the time it takes to blink your eyes. I looked it up. One bar less of reception on your wi-fi will slow page load time way more than that.
Will this Work for You?
If you’re Amazon and you have billions of visitors to billions of pages then that revenue loss adds up. But think about it. Amazon is a store that delivers tons of static content per page. If that’s the type of site you run, the W3 Total Cache plugin is going to do you no good. You need to be on a dedicated server and/or using CDN, which is a cloud service to store and deliver your static content, and a different type of plugin like WP Minify, or some other similar combination.
Setup is Key
I also belong to a few WordPress groups and caching plugins are one of the topics that come up frequently. The number one comment about W3 Total Cache is that it has to be set up properly for your hosting, because each host provider handles caching differently. In fact, WP Engine, one of the premier WordPress hosts, doesn’t even allow caching plugins because they do all of that for you at the server level.
The Reality
Here’s the truth about caching plugins like W3 Total Cache.
Just because a host service like HostGator recommends W3 Total Cache doesn’t mean that the plugin works correctly out of the box. You have to follow their setup recommendations to the letter.
What W3 Total Cache and other such plugins really do is not speed up page load times directly. They decrease server load. And that indirectly increases page load time, but by a miniscule amount per page. The real measurable effect is to the server overall. That is why hosts recommend these plugins. A faster server means faster page loads for everyone on that server.
The Hassle
Another complaint about caching plugins is that you can’t see changes you are making to a page in real time. That drives site owners so crazy that W3 even includes a link you can click in the admin bar to turn the thing off so you can see your edits. The trick, of course, is to remember to turn it back on.
My Advice
Stop chasing every shiny thing that is recommended and ensure that it is a good fit for your site first.
I don’t use a caching plugin on BlogAid. Most of my clients don’t either. They are more trouble than they are worth in my opinion. There is simply not enough speed difference in site load time to matter.
However, I have found plenty of other things to fix on sites that do significantly affect load time, like other slow plugins. Caching won’t fix that. Getting a better plugin, or simply finding another way to do whatever it was doing, does fix the problem.
There’s a little plugin called P3 (Plugin Performance Profiler) that will tell you what plugins are slowing down your page loads. And you can delete it after you use it.
Graphics are another speed killer. If you have a graphic-heavy site, consider CDN or other cloud storage options to deliver those. I use Amazon S3 to store and deliver over 50 videos to the BlogAid Video Library. Works like a charm.
Get it Fixed
If you want to use W3 Total Cache and want the .htaccess file fix, but don’t feel comfortable poking around in your core host files, contact me.
If you want to have your whole site checked for security vulnerabilities, I can do that too. Get a 20 Point Site Inspection and tune up. It’s live and you see what I see. Takes 30 minutes and you get a written report immediately afterward.
If you use W3 Total Cache, and I have done such a site inspection on your site, and have already secured your files, contact me and I’ll add this new security patch for free.
Wrap Up
Do you use the W3 Total Cache plugin or something similar? Does it really help? How do you know? Have you had any issues with it? I expect that I’ll draw some fire for this post, especially from the WordPress groups I belong too. I’m hoping you’ll consider leaving your comment here on the blog for everyone to read and reply to. It’s a conversation worth having and hearing about from all angles.
Christine Cobb says
December 27, 2012 at 9:12 amSometimes people install a caching plugin because their host’s support department told them to do it. That’s one of the few beefs I have with Hostgator. “Install a caching plugin” is their canned response kind of like “take two aspirins and call me in the morning”.
Also these plugins cause havoc with membership scripts and ecommerce plugins. I’m not a fan either.
MaAnna Stephenson says
December 27, 2012 at 10:12 amI’ve heard that same canned response from way too many folks too, Christine, while never mentioning that it needs to be set up correctly. And, never addresses the root of the problem. I do like HostGator, but think they, and all other host providers, need to seriously consider supporting WordPress issues better, since that’s what so many of their client’s use now. On the other hand, I can see how they would loose their shirts on free support of a product they didn’t make and that is so easy for end users to goof up.
Dee says
December 27, 2012 at 11:59 amThank you, thank you, thank you for taking the time for this in depth report for us, MaAnna! The cache plugin was on my to-do list, so you’ve saved me the trouble and explained the reason I don’t really need it on our site. You’ve saved us again!
MaAnna Stephenson says
December 27, 2012 at 12:49 pmYou’re welcome Dee!
Frederick Townes says
December 29, 2012 at 1:59 amFor those of you that use W3 Total Cache to make your sites more performant, thank you. Security issues are always of paramount interest, no matter the scope. Unfortunately some of the advice in this post is not correct because the author is failing to consider the various moving parts that slow down a site and impact user experience, rankings and hosting costs. There are numerous guides out there (not to mention the installation steps) that will help folks get off to a good start.
The root of the possible vulnerability lies in the intersection of two configuration settings, one at the Web Server level and the other at the W3 Total Cache database caching level. You may be vulnerable if the following are true: your server is configured to allow directory listing with enabled public access on W3TC’s database caching directories and also use database caching via the disk caching method. These settings would allow a hacker to break the md5 hashing used for the then publicly accessible cached database objects. The manner, extent and timing of the vulnerability’s report leave much to be desired; nonetheless, the versions have now been patched on wordpress.org. Thanks to those that offered remediation advice. I’m sorry for the delay in turning this around, none of the proposed solutions were satisfactory.
The hotfix (tested with WordPress version 3.5) will help those who are just now upgrading to 0.9.2.4 or are otherwise getting started with W3 Total Cache. Specifically, the hash logic is improved via wp_hash(), significantly stronger than the previous md5 hashing at the compromise of a bit of speed. I’ve also made sure that a web server’s lack of security around directory listings and the standard file structure of W3TC’s hashing logic are no longer of consequence for those attempting to download them from your server.
For those who are using database caching to disk already, please be sure to disable directory indexing and deny web access to the “wp-content/w3tc/dbcache/” directory in your web configuration, then empty the database cache for good measure. Or, simply deactivate W3 Total Cache, uninstall it, and re-install it via wordpress.org to have the hotfix applied upon re-activation. Again, empty the database cache for good measure. Your settings will not be lost during this process. If all of this is gibberish to you, then simply disable database caching to disk until the next release or use another method if available. Once again, empty the database cache using the button of the same name available on the database caching settings tab.
If you’re reading this and have seen a post about the issue that does not have this response on it, please do post this for me. Thanks in advance. Happy Holidays.
MaAnna Stephenson says
December 29, 2012 at 11:00 amThanks for the extra info Frederick. But, I’ll say again that I have very few clients that get enough speed benefit to go through all of this to make caching work.
Frederick Townes says
December 29, 2012 at 11:05 amBased on what tools like Google’s Page Speed indicate and what I’ve seen over the past 9y in this industry, I’d have to humbly suggest that sites simply aren’t dialed fully dialed in. Simple. For example: https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fwww.blogaid.net_2F&mobile=false
Fixing those high priority issues would make a measurable impact on performance and the simple fact that Google’s Web Master tools expose this data to web masters is a clear signal that the Web Performance Optimization movement is not going anywhere. It’s a mistake to recommend that publishers not consider a performant web site and user experience as significant qualities of a successful site.
MaAnna Stephenson says
December 29, 2012 at 11:23 amWell, Frederick, if gaining 300ms is important to you, than it is. To me, it’s not enough of a ranking factor compared to all else that a site owner needs to concern themselves with to have a site that gets found, read, and acted upon. Google is not the only way folks get found. In fact, relationship marketing is far, far more powerful. Even if a site loads lightening fast, if all the other factors are not given top priority, folks leave just as quickly and there is no conversion. That is where my clients need the most help. Perhaps your clients already have those things taken care of and can make load speed a higher priority.
Frederick Townes says
December 29, 2012 at 11:43 amSorry we’re not talking about the same things at all. If this was all about 300ms then I wouldn’t bother. Also I mentioned user experience, Google has the same goal as any publisher would, creating a speedy experience for users. Addressing performance issues are low hanging fruit to unlock page views, increase conversion rates, time on site and other metrics and your reference to “300 ms” is irrelevant. Typical web pages today average around 1MB and there are steps publishers should take to get that total size down especially as mobile continues to grow as a media consumption channel. Again sorry we simply are not talking about the same things.
MaAnna Stephenson says
December 29, 2012 at 11:59 amOkay, let’s put it to the test, Frederick. If you are agreeable to it, let’s make a test case of BlogAid. I’m happy to make the changes if you will suggest specific ones and point me to some how-to posts, including any that you may have. And then come up with measurable goals that we can report later.
Frederick Townes says
December 29, 2012 at 12:16 pmI can’t seem to reply to the thread again. Anyhow, I gave you the link to Google page speed. You can use W3TC to make many of these changes (because W3TC is not just about caching despite the name, caching is a concept that people understood, that’s why it was used) or you can make them yourself. The metrics shown in the table here: http://www.webpagetest.org/result/121229_NX_AK0/ will give you empirical evidence that you’re improving user experience. Faster pages mean simply mean it’s easier for people to consume your content, there’s too much empirical evidence to dispute the point. I’ll leave it to you to use the tools you wish to address the issues that are preventing you from unlocking all of the traffic you’re earning with your content. Right now it takes me 3 seconds to BEGIN to see your pages when I visit this page, which I’ve already visited before; if I didn’t have the intent of replying there’s no way I would wait.
Naser says
December 31, 2012 at 5:31 amThanks for sharing it Anna, I am also using W3 total cache on my blog but didn’t apply any security patches above. I will do it at the earliest.
MaAnna Stephenson says
December 31, 2012 at 8:53 amHi Naser. The developer’s jumped right on this and there is already a fix for it. So, simply update your plugin and that should take care of it.