Forum

We've migrated several WordPress sites to Hiawatha, after being attracted to it partially by its available SQLi, CSRF and XSS protections. We like a *lot* about Hiawatha. We don't much like WordPress, but it's a not-insignificant revenue stream that we're not likely to turn down.

Recently we've had to turn off SQLi protection on a few of our WordPress sites, though, and I anticipate we'll eventually remove that setting from our OpenVZ template. The reason for this is that Hiawatha interprets some normal WordPress actions (not plugin-driven) as SQLi and returns a 444 to that IP. Typically this is when an admin user is editing a page and WordPress wants to save a draft. As a rule, we have a

deny <customer IP>

in BanlistMask, but that doesn't keep Hiawatha from continuing to block the action itself. We have a few customers who have dynamic IPs, though, so for them that much isn't even a possibility -- we have to turn off SQLi protection, period.

To be clear, I think this says more about WordPress than it does about Hiawatha. WordPress is exploiting itself via SQLi, and Hiawatha rightly interprets this is a Bad Thing. It is what it is. I don't know that being able to whitelist IPs like

SQLiMask = deny <customer IP>

is even desirable, but it would address the specific issue we're having without requiring us to turn off SQLi protection altogether. Since SQLi is one of the primary ways WordPress and its plugins are exploited, we'd love to leave that extra layer of protection in place.

Hugo, if you have any suggestions or thoughts other than agreeing with us that WordPress is the problem, please chime in. Otherwise, it's my hope that you and anyone coming to Hiawatha for use under WordPress would read this as informational rather than a feature request or a complaint. We're very happy with Hiawatha's performance and protection features, and with how easy it is to configure, and I don't see us moving away from it any time soon.

The RequestLimitMask disables the check for SQL injections via the assigned IP addresses.

Would it be adversely affected by a WAF reverse-proxying to Hiawatha? I was using that directive (deny for customer IP range and for WAF) for one of the sites we had this issue with, but they were seeing 444 codes, and the logs indicated that was because of SQLi.

SQL injection is invoked by having one or more single quotes in the HTTP request. If your application is designed well, it can handle those characters without a problem. If not, it will execute the injected SQL commands or fail at the original SQL query because the quotes where not inserted as an injection (probably because some uploaded file (image?) contains the quote character).

This is the problem you have to deal with. The PreventSQLi command was originally intended to protect websites which ARE vulnerable for SQL injection. But many people also enable it for websites which MIGHT be vulnerable for it. If you then upload, for example, an image that has the quote character in its binary data, Hiawatha will see it as a potential SQL injection and block the request. This uploading would go well if the website has no SQL injection vulnerability.

So, my advice is as always: only use this option when your website IS vulnerable for SQL injection or you have a SERIOUS SUSPICION that it is.

Well, we *know* WordPress sites are vulnerable to SQL injection. It happens all the time. So we'd like to use it.

The broader question here, then, is: Why were IPs getting 444 response codes while RequestLimitMask had their IP excepted?

First, why do you want to keep using Wordpress when you *know* it is not secure and *will* cause your trouble?

444 errors should not appear for those IP's. Are you using the latest Hiawatha version? What RequestLimitMask configuration did you use?