Security and Privacy Considerations for Website Owners and Developers – WebDevStudios

by Suzette Franck for

As a multiple website owner and WordPress front-end developer, I am passionate about website security and privacy practices, and the applications and requirements as a modern web developer. I have come to learn that just because you can do something, doesn’t mean that you should. Care must be given to the type of information stored, where it is stored, and how it is transmitted through the interwebs, the resulting consequences range from moderate to severe, but most are avoidable through a little bit of old-fashioned research and prevention.


W3 Total Cache Implementation Vulnerability | Sucuri Blog

Just in time for Christmas, it was announced on the full disclosure list a security (configuration/implementation) bug on W3 Total cache (W3TC), one of the most popular WordPress plugins.

The issue is connected to the way W3TC stores the database cache (in a public accessible directory). It can be used to retrieve password hashes and other database information.

By default the plugin will store the caches inside /wp-content/w3tc/dbcache/ and if you have directory listing enabled, anyone can browse to and download them. The second issue is that even if you don’t have directory listing enabled, it is still possible to guess those directories/files in order to extract the database cache queries and results.

Full article at W3 Total Cache Implementation Vulnerability | Sucuri Blog.


Robots.txt Google Security Alert from Wordfence

I am a huge fan of the free WordPress Security plugin, Wordfence. I received this email yesterday regarding robots.txt and I thought I’d publish here for everyone’s reference:

Dear WordPress Publisher,

There is a subtle vulnerability that has emerged in the robots.txt standard and how Google indexes data. The issue may cause the existence of administrative areas on your site to be exposed by Google, even if you specifically tell Google to not index those areas.

Exec summary:
Google respects the rules in robots.txt, but indexes robots.txt itself. With a specially crafted search query to Google, a hacker can find administrative areas on websites that publishers have told Google to exclude from the index. A possible solution is to exclude the admin areas from robots.txt and instead use HTTP basic authentication to prevent the areas from being indexed.

Full details:
As a brief reminder, robots.txt is a way to tell crawlers like Google which pages you don’t want indexed on your website. You can read more about how robots.txt works here.

It has become common practice among website administrators to place administrative areas in their robots.txt telling Google that they don’t want that area indexed.

Unfortunately Google indexes robots.txt itself which creates a resource for hackers trying to find sites with an admin area they might be able to exploit.

Hackers can craft a query to Google which contains a URL of a known vulnerable application’s admin area to find vulnerable sites.

The following examples were posted to the Full Disclosure security mailing list which demonstrates this attack:

The query specifies that “robots.txt” must be in the URL, that the filetype must be a text file, and that the file contain a “Disallow” statement which tries to prevent Google from indexing an admin area, an area that stores backup files which would allow download of the entire website, and an area called “password”.

This is a catch22 situation because if you don’t use robots.txt to prevent indexing of your admin areas, Google will expose the fact that they exist by indexing whatever is publicly visible. If you do include the admin area in the robots.txt, Google indexes the robots.txt which exposes their existence anyway.

Naturally security through obscurity is not a good policy. Your admin areas should be protected using authentication. But using a crafted Google query to find vulnerable systems has long been a part of the hackers toolkit. So if you want to remove yourself from a potential target list, you should consider how to solve this issue.

My advice is the following:

If you have any directories where you store backups or sensitive data, don’t include them in your robots.txt and add a layer of “basic authentication” using an .htaccess file in addition to the existing authentication you have. So if you have a web based login screen, create a .htaccess file that protects that login screen from being indexed by Google.

Expect Google to respond to this in the coming weeks or months with a change in policy in how it indexes the content in robots.txt.

Mark Maunder
Wordfence Creator & Feedjit Inc. CEO.

PS: If you aren’t already a member you can subscribe to our WordPress Security and Product Updates mailing list here. You’re welcome to republish this email in part or in full provided you mention that the source is If you would like to get Wordfence for your WordPress website, simply go to your “Plugin” menu, click “add new” and search for “wordfence”.


Sucuri SiteCheck Malware Scanner Plugin for WordPress | Sucuri Blog

If you’re a WordPress user, love our free SiteCheck scanner, or already use our free SiteCheck Malware Scanner Plugin for WordPress, we have an update for you.

Last night we released version 1.2 of the plugin which cleans up various parts of the plugin. There’s still a lot more work to do but this was the first step towards prepping our free SiteCheck plugin for future awesomeness.

Not to be confused with the commercial Sucuri WordPress plugin offered with all of our Sucuri service plans, the Sucuri SiteCheck Malware Scanner plugin for WordPress offers SiteCheck scanning of your WordPress site, right within your WordPress dashboard. We have also rolled in the Sucuri 1-click hardening options to help improve your overall security risk posture.

Here are the changes that were made to the plugin in version 1.2:

  • Tested to WordPress 3.5
  • Cleared PHP warnings
  • Framework Refresh
  • Styling Refresh
  • Removed old malware page

via Sucuri SiteCheck Malware Scanner Plugin for WordPress | Sucuri Blog.


How to Scan Your WordPress Site for Potentially Malicious Code

My personal favorite is, but I also love WordFence, which is not mentioned in this great article…

Often we get asked by our users, is there a way to scan your WordPress site for potentially malicious code? The answer to that question is YES, YES, and YES. There are both free and paid tools available to scan your WordPress site for potentially malicious or unwanted code. It is always good to do a regular checkup of your site by scanning it for potentially malicious code. In this article, we will show you a few ways on how to scan your WordPress site for potentially malicious code.

via How to Scan Your WordPress Site for Potentially Malicious Code.