Instant Cookie Expire – my first WordPress plugin

Recently, I published my first WordPress plugin: do5enef. It’s a very basic and simple plugin that does just one thing: setting the expire-time of a cookie when using a password protected post to “instant” instead of “10 days”.

This solves the problem that, once the password has been entered, you can access a password protected post for the next 10 days without having to enter the password again. In some cases, this isn’t wanted behaviour and so I crafted this one-line plugin.

Primarily, this was a testcase though. I wanted to learn the workflow of building WordPress plugins and publishing them to the repository. Currently I’m building my very own WordPress Security plugin (over 1500 lines of code already and still counting), which I hope to release by the end of 2016.

Of course I’ll keep you all posted!

WordPress and user enumeration through Author Pages rant

Yes. This will be a bit of a rant about WordPress.

Don’t get me wrong. I love and adore WordPress. Hell, I live WordPress. But there are just some things I really don’t like about it (at least from a security perspective).

Most of my major issues are with the default settings of a clean install of WordPress. I’m talking about features such as the XML-RPC protocol, author pages, file editing in the backend (on themes, plugins and core files).

Let’s take “author pages” as an example. I know from experience that this feature of WordPress is being used by just a fairly limited number of sites running WordPress.
However, when author pages are active, it’s easy to derive the usernames. This only leaves hackers the necessity of ascertaining the password and they’re inside your backend.

If you’d like to know the impact, just add “/?author=1” behind your domainname in the address bar. If author pages are active, it’ll redirect to a url that contains something like “/author/username”. And this “username” is actually the one you use to log into your wp-admin-backend.

And yes, I know there are plugins that can block this for you (such as and several security plugins that offer it as an option), but that’s not my point.

The thing is that these settings are active by default, without an option in the WordPress backend to easily disable them.

My proposition:
Let’s make these functions an “opt-in” functionality. Let them be disabled by default and let’s make it possible to enable them if this is really needed for a specific website. This would make a huge number of WordPress sites that little bit more secure.

I’ve decided I won’t site back and I’ve already started working on a security plugin that will disable all of these features and create an “opt-in” menu under “Settings” in the WordPress backend. More on that soon!


8 great resources for stock photos

When producing content for your site or blog, you’d usually want to add a great picture to your page or article. However, most stock photos are quite expensive. But thankfully, there are several sites that provide high quality stock photos that are free, even for commercial use. Here’s a list of 8 sites I use the most:

Have fun creating/publishing!

Block xmlrpc attacks via .htaccess

XMLRPC is a protocol that is enabled by default in WordPress. However, since version 3.5 the option to disable this function was removed from the WordPress backend. Since this protocol is prone to attacks, which can be used to try several hundreds of username and password combinations in one single request, it’s paramount to disable this.

You could do this through a plugin, but a more efficient way would be to add following RewriteRule to your .htaccess:

RewriteRule ^xmlrpc.php$ "" [R=301,L]

Hiding your htaccess file

A great way to improve your security is hiding your htaccess file, since this file usually contains quite some information that can be indicative of the structure of your website or the content management system that was used to create the site. This can be done by taking two distinctive steps:

1. htaccess file permissions

First you’ll need to set the file permissions of your .htaccess to 644.

2. Add this to your .htaccess file

# secure htaccess file
<Files .htaccess>
order allow,deny
deny from all

WordPress security improvement: adding 2-factor authentication

Another great way to improve the overall security of your WordPress website, is by adding two-factor authentication to your WordPress security measures. It improves your security since it requires 2 seperate elements to be entered before a user will be granted access and is, by default, a better solution than just using a username and password combination to log in. Two-factor authentication usually requires you to enter both a pincode/token of some sort and validate another element before access is granted.

How this improves your WordPress security

Using 2-factor authentication helps to effectively protect your website against following attacks and vulnerabilities:

  • Brute-forcing attacks
  • Weak passwords set by the end-user
  • Passwords that have be intercepted via man-in-the-middle attacks

But that’s enough theoretical chitchat already. Let’s go over the best options available today:

Continue reading →

Installing Odoo on Debian 7


Recently I tried to figure out how one could install Odoo on a Debian 7 machine, since the documentation on the official website seemed to describe a set of instructions that didn’t work for me. Here’s how I was able to get it working with a variation on the official installation instructions.

Installing Odoo on Debian 7

Continue reading →

Prevent PHP execution in wp-content/uploads

Prevent PHP Execution in wp-uploads and improve WordPress Security

When hackers are able to ascertain your WordPress credentials, there’s a good chance they’ll try and upload a backdoor into your WordPress website via the backend. A backdoor is a script, usually PHP, that allows them to perform actions on your website/webspace (such as creating malicious files, resetting permission, …). So it is paramount to prevent PHP execution all together. This way you can limit the actions a hacker can perform if your credentials do get compromised.

How to prevent PHP execution:

To ensure no .php files can be executed, I’d suggest you create a .htaccess file in /wp-content/uploads containing following code:

Continue reading →

A WordPress guy goes to Drupalcon!

The past week I’ve attended Drupalcon in Amsterdam. As most of you know I’m quite active with WordPress, so going to Drupalcon was quite an experience. It seemed fitting to write a little review on my perception of Drupal 8 and it’s community.

First, a list of (most of) the sessions I attended:

  • The keynote by Dries Buytaert (also known as the Driesnote)
  • Turning Drupal into a machine for automated deployment
  • Deploying your sites with Drush
  • Getting content to a phone in less than 1000 ms
  • Understanding the building blocks of performance
  • A keynote by Cory Doctorow
  • Render caching in Drupal 7 and 8
  • New wave PHP
  • Building a multilingual, multidomain Drupal site
  • Drupal Lightning talks
  • An overview of the Drupal 8 plugin system
  • Building modern web apps with ember.js and headless Drupal
  • Closing session

So what’s different with most of the WordCamps:

I found Drupalcon to be an example of professionalism when it concerns the organisation and there’s a great diversity in the tracks (and a great number of simultaneous tracks). This is certainly something that can be improved by most WordCamps.
Sessions also tend to be longer, with an hour as the minimum duration and 1h15 in average. It gives the speaker the possibility to go in depth in his or her talk, something I would certainly appreciate in future WordCamps.

And what about Drupal 8?

I’ve used Drupal before I ever started using WordPress. I liked it back then and I like it now. But with Drupal 8, we can certainly state that Drupal has evolved. Bringing a fully responsive backend, improved api’s and much more, it’s a joy to work with. I’d urge all of you to try Drupal 8 beta 1 yourself.

Drupal 8’s community is great!

One thing I noticed quite immediately is that the Drupal 8 community consists of much more developers and contributers to the project than the average public on a WordCamp. These guys and girls are also super friendly and eager to help. Also, throughout the conference there were ongoing code sprints where you could learn to contribute to the Drupal project. These were mentored sessions, so any newbie could pitch in. I was even able to find an issue and open a issue in the tracker ( I look forward to diving deeper in the world of Drupal once again!