Zero-Day WP Plugin Vulnerabilities

Zero-Day WP Plugin VulnerabilitiesNew zero-day WP plugin vulnerabilities  are announced with alarming frequency. I gotta keep all my plugins up to date so that any new vulnerability gets patched. I use my custom plugin to auto-update everything РWP, themes, and plugins.

But is this enough? When bad guys and gals discover and start exploiting a new plugin vulnerability, there can be a delay of unknown duration till the good guys and gals catch on, then another delay till a patch is developed and released, then another delay till my auto-update kicks in and patches my plugin. These delays are collective termed the ‘Zero-Day Vulnerability” period.

Even though I am responsible and diligent in keeping everything updated as timely as practical, my site is still wide-open to exploit during the Zero-Day period. And I use a lotta plugins – currently 21 on this site.

So, what can I do? For a very long time I thought ‘nothing’ – except cross my fingers and hope no vulnerabilities are found in the plugins I use. Or, if a vulnerability is found, hope my auto-update out-races the hackers and their demon bots.

Then, late last year (2018) CloudFlare made Firewall Rules available on the free tier. And I’ve been playing around and learning more about them for the past few weeks.

I can use a couple of CF Firewall Rules to – hopefully – safe guard against zero-day plugin vulnerabilities.

The first of these firewall rules will block access to any php file – legitimate or mischievously uploaded – in my plugins folder or elsewhere in /wp-content/. There is a possibility this will break stuff, but a properly designed theme or plugin should never require direct access to a php file in the /wp-content/ folder. For me, nothing seems to have broken – otherwise I would look for a different plugin to replace the broken one.

The second rule blocks all requests that do not come through my site from accessing the /plugins/ folder. Legitimate requests will have something along the lines of ‘mysite.com’ as the HTTP referer, and will be allowed. This rule has the side benefit of blocking naughty bots from crawling my /plugins/ folder, which I explicitly disallow in my robots.txt. I can’t think of any legitimate reason I would want a bot snooping around there.

Here’s the expression …
(http.request.uri.path contains "/wp-content"
and http.request.uri.path contains ".php")
or
(http.request.uri.path contains "/wp-content"
and http.request.uri.path contains "/plugins"
and not http.referer contains "mysite.com")

Kinda obvious but worth pointing out – replace bygosh.com/mysite.com with your site name.

For me, these rules are just two of a much longer set, all packaged into a single one of my precious five CF firewall rule sets available on the free tier. I only get five, so I gotta make each one count.

WPPOV supports freedom from Net Neutrality and the GDPR. The Internet of the people, by the people, for the people, shall not perish from the Earth.