WordPress Plugin Vulnerability Leaks Donor Data: Secure Your Site with a WAF
Last week, you may have read about the donor data breach that Pi-hole experienced with the GiveWP plugin they use for their donation page form. The breach caused panic among Pi-hole's donors, who were suddenly inundated with spam to email addresses they had created for specific donation use cases.
Pi-hole deserves credit for not requiring a valid name or email address for donations. GiveWP's developers also deserve praise for fixing the issue within a couple of hours of the GitHub open issue being reported.
Amidst the chaos of how it unfolded on July 28th, it was discussed and addressed by developers with a quick fix in version 4.6.1 of the plugin update.
I fail to understand why no one is talking about the bigger issue. Taking a fresh look, wouldn't you agree that the lack of a web application firewall (WAF) is the real issue?
That's why you have WAF, isn't it?
A Web Application Firewall (WAF) can be a self-hosted service or a hosted service like Cloudflare, which offers a free WAF account. One popular open-source WAF engine is OWASP's ModSecurity.
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve software security.
Seasoned system administrators would recommend serving any web application in containers like Docker with a WAF.
Issue with GiveWP plugin as reported on Github:
<script id="give-donation-options-js-extra">
var GiveDonationOptions = {"isAdmin":"", ... "donors": {}
</script>This is exactly the kind of thing that a WAF would catch and prevent from leaking. In layman's terms, a WAF reads every line of code being streamed to or from a server. It detects this kind of thing instantly and blocks it.
Let me show you how. Please See this:
coreruleset
This filter would catch and block it. So, even if developers push a new update with questionable or malicious code, the filter blocks it with a 403 error.
Instead of relying on a CMS's core team or plugin developers, you can rely on WAF to prevent such mishaps. If security matters to you, I suggest keeping your stack and server as secure as possible given the limited number of hours in a day you can dedicate to maintaining your server.
A WAF is not a joke. Please understand how powerful it is. Without a doubt, WAF is the only thing that can protect you from zero-day exploits, malicious updates, and supply chain attacks.
Let me put it this way: Just as fail2ban is for servers, WAF is for web applications.
Isn't WAF itself server software hosted on a system? Couldn't it be buggy, too?
Well, everything can have bugs. ModSecurity, the most widespread open-source WAF, is 22 years old and is trusted and used by most mature hosted WAF services, including Cloudflare, in some shape or form.
Rest assured, all the bugs have been ironed out by now. No, you cannot attack ModSecurity from outside. To do so, you would need backend access, which would allow you to bypass it. In simpler terms, you basically need SSH login access to the system.
ModSecurity rules are the gold standard. They're now called "coreruleset," or CRS. Rest assured that these experts are the best in security. They know what they're doing.
The Cloudflare OWASP Core Ruleset is Cloudflare's implementation of the OWASP ModSecurity Core Rule Set ↗ (CRS). Cloudflare routinely monitors for updates from OWASP...
Lastly, all WAF rules are standardized, regardless of the application they serve. All traffic goes through the WAF. Anything suspicious is logged, and anything malicious is blocked outright. The rules protect you in both directions, from client to server and from server to client. It is bidirectional security.
