Trouble-Shooting the WordPress Security White Paper.

line Tags: , , , , ,

I’ve been following the activity over at blogsecurity, their activities are very interesting and quite commendable. After some shameless delay I decided to read though their WP Security White Paper and apply some of the steps… yes I did say some, harden security folk will insist that you should follow all of the whitepaper to be security, which is probably true, but one should never forget that security is about risk… and in basic terms accessibility vs security, for example I won’t ever lock my wp-admin down to a single IP as I’ve been know to blog at work, home, around my parents place and even moderate comments on the train! Thus my wp-admin isn’t as secure as someone who did lock it down, but this is a risk I’m willing to live with.

One of the area’s that I did like was the tightening up of wp-includes & wp-content, but before you jump in and copy/paste what’s in the pdf into .htaccess, you should be prepared for some work. Basically


Order Allow,Deny
Deny from all
<Files ~ ".(css|jpe?g|png|gif|js)$">
Allow from all
</Files>

when applied stops any file except .css,.jpeg/jpg, .png, .gif & .js from being accessible; now this is great for stopping zero-day remote file includes from php files but it will mean that any php file (even those you may want access to) will be restricted. What I’ve decided to do below is document what changes you need to make to the recommendation to get some popular plugins to work…. This approach will also have a long term impact on the “hardening plug-in” that the blogsecurity team are planning; basically the issue is - the default recommended .htaccess will break plugins, the number of plugins avilable for a wordpress install is unlimited thus they will need to provide a community driven configuration repository that the plugin can draw upon to open things up for specific plugins.

For the purpose of this documentation, I’m going to assume wordpress is installed in /var/www/html so please change appropriately.

For those who use the rich editor and need the spell checker, you’ll need to add this to your /var/www/html/wp-includes/js/tinymce/plugins/spellchecker/.htaccess


# Open up the spellchecker
<Files "tinyspell.php">
Allow from all
</Files>

To get the popular WP-Cache plugin to work changes are made to:/var/www/html/wp-content/.htaccess

Order Allow,Deny
Deny from all
<Files ~ ".(css|jpe?g|png|gif|js|html)$">
Allow from all
</Files>

This will allow the static html files in the cache to be downloaded, now I didn’t get to the bottom of this, but I believe that the wp-cahe php files might be called directly, so if you are having problems see if this resolves it…

<Files ~ "wp-cache">
Allow from all
</Files>

This will open up the wp-cache files as if you hadn’t installed the .htaccess in the 1st place - you have been warned, now you evaluate the risk :)

If you are using the google site map generator, then you can create a .htaccess file in/var/www/html/wp-content/plugins/google-sitemap-generator to allow the xml style sheet through:

<Files "sitemap.xsl">
Allow from all
</Files>

The final one that might interest people is Share This, you’ll need at .htaccess in /var/www/html/wp-content/plugins/share-this with:

<Files "share-this.php">
Allow from all
</Files>

As you might have gathered this does involve creating a lot of .htaccess files, which is a bit of a pain, if you’re fortunate enough to run your own web server and have access to your httpd.conf you can actually keep these all in one file, keeping with the last share this example, instead of creating a .htaccess in /var/www/html/wp-content/plugins/share-this you can edit your httpd.conf and just wrap the code in <Directory>, so you could actually paste this:
<Directory "/var/www/html/wp-content/plugins/share-this/">

<Files "share-this.php">
Allow from all
</Files>
</Directory>

I hope this all makes sense, and is of some use to someone…good luck to the blogsecurity team, if you need any help feel free to shout ;)

nick

 

8 Comments

  1. David Kierznowski Says:

    Great initiative Nick.

  2. Philipp Says:

    Really nice work Nick. We’ll see what we will come around but something like a user driven repository is needed, as we have not the time to check every Plugin to see which access is needed in order to get it running. A good starting for sure, thanks for your help!
    Btw. you can add everything you added to your httpd.conf file as well to the main .htaccess file we described. So you don’t even need access to the httpd.conf file.

  3. Nick Says:

    Thanks for your responses guys :D

    Btw. you can add everything you added to your httpd.conf file as well to the main .htaccess file we described. So you don’t even need access to the httpd.conf file.

    You’re right, you can add the <Files> directives to .htaccess, but you cannot add the <Directory> directives, I think I should have explained better, if you add <Files "share-this.php"> to ~/wp-content/.htaccess then any file called share-this.php whether it be in the themes or plugins directory gets permitted, I was trying to be more granular by either using <Directory> in httpd.conf or by creating htaccess files in the correct directory… does that make more sense?

  4. Philipp Says:

    Thanks Nick for your addition, I’m not too well within Apache and you’re right. It’s mostly even better to use httpd.conf and disable .htaccess for increased performance. And even some more security. But many users may not be able to access httpd.conf so .htaccess will be the only solution.

  5. AskApache Says:

    This is a really nice, well-thought-out effort, but unfortunately it is very much so NOT the best way to accomplish these goals. Using the (or filesmatch) is a good idea but the problem is it blocks INTERNAL and EXTERNAL requests alike. Plus anyone but a seasoned htaccess admin can easily cause some atrocious security holes by misusing the allow and deny commands..

    The BEST way to block all of these files is to only block EXTERNAL requests for them. IOW, if your wp-cache requests a file, it should be allowed. If a visitor on your webpage requests the same file, it should be denied. This seems impossible to accomplish but actually mod_rewrite provides a really cool way…

    for example, this blocks all external requests (except those generated by ErrorDocument code /index.php?error=code) for files ending in .php in either the wp-includes or wp-content directory, but it doesn’t block your server or WP install!

    RewriteCond %{QUERY_STRING} !error
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(wp-includes|wp-content)/(.+)\.php\ HTTP/
    RewriteRule .* - [F]

    code from htaccess tutorial

    Another way to secure your wordpress with .htaccess is by using my wordpress plugin: htaccess password protect on AskApache.com

  6. Nick Says:

    Thanks for the info “AskApache” :D

  7. pingback from: Sicherheit / WordPress absichern
  8. iwebie Says:

    I used to use Wordpress, but I got sick of all the security holes and switched back to MovableType.

Got something to say?

 

Some other things that might interest you...

---