[BUG] Banned URLs are Case Sensitive

This has to be a joke? MTN

Hi,

The only reason I can think of why you would want to setup this rule is because due to the hosting environment your site is hosted on you have the phpMyAdmin database management tool installed in your hosting account’s file system. If that is the case then I recommend you use server side blocking rules to protect that directory from unauthorized access.

Thank you.

You didn’t understand my point. It’s not about phpmyadmin URL.

I was talking about the case-sensitive feature of Banned URL functionality. Suppose if I add /admin/ to the banned URL and someone tries to access /Admin/ or /ADMIN/, he’ll not be banned because Wordfence will only ban IP addresses accessing /admin/ URL.

I hope now you’ll get my point.

Hi,

Thank you for the clarification. I can take this back to the team for you as a feature request.

Hi,

Since I haven’t heard back from you and your feedback has been taken back to the team as a feature request I am marking this topic as resolved.

All feature requests are discussed by the team and given careful consideration so you may see this in a future version of Wordfence.

Thank you.

Any idea when this is likely to be fixed as I’m seeing brute force login attacks at the moment with “unusual” capitalisation in the usernames being submitted and I couldn’t see anything here so started another question

The attacks are being caught by 2nd security plug-in so I’m not panicking but assuming it has not been fixed (I’ve seen nothing in the release notes) it does seem a loophole that attackers are aware of.

Sigh, yet another reason I canceled my Premium Wordfence. I suspected attackers would eventually figure this out, and start adding random caps to their attack URLs. This would be so easy for Wordfence to fix…

But since Wordfence has better things to do than repair their software flaws, we as website managers must look at our options. It’s possible through the Apache server configuration settings to convert all URLs to lower case. It can be done in .htaccess, as well as in httpd.conf. Good tutorial here:

https://www.askapache.com/htaccess/rewrite-uppercase-lowercase/

I’d prefer to do this at server level with httpd.conf, that way it would cover all the sites on my server, but I wonder if doing it that way has a downside?

NOTE: To be sure this was still an issue I tested just before writing this post. Adding an upper case character to a blocked URL resulted in a bypass of the Wordfence
“Immediately block IPs that access these URLs” feature. Terrible. Unconscionable. Please Wordfence, could you fix this !?

That’s what I’m doing currently. Using httpd.conf code to convert uppercase letters into lowercase.

In my opinion, the blocked URL feature should be case-insensitive.

Why is this marked as “Resolved?” It’s clearly an ongoing flaw. MTN

Hi @psamathe,
The feature that blocks URLs is not part of brute force protection. The feature discussed in this thread is one that blocks users when they try to visit specific URLs on your website. A username would not be considered a URL. To achieve blocking of logins with strange usernames you can enable the option in Wordfence to block all invalid usernames.

@yet-another-wp-user, @mountainguy2,
Some people may be using the case sensitivity in banned URLs to block certain things and not others. If we implement this it would likely be a separate option where you can choose if it’s case sensitive or not. The thread is marked as resolved because we don’t have anymore information we can give you at this time. Your feature request has been noted and we may implement this at some point.

Thanks for the feedback. Hope you have a great week!

Consider following example:

Following URL is accessed several times by hackers on a blog:

/wp-content/upgrade/

Now the administrator adds following to immediately banned URLS list:

/wp-content/upgrade/*

But the hacker can access the URL using any other pattern such as:

/WP-content/upgrade/
/WP-Content/upgrade/*
/Wp-Content/upgrade/*
/wp-content/Upgrade/*
and so on

So how many patterns should we block? 1000 or more?

/wp-content/upgrade/ is the only one that wouldn’t result in a 404 and to protect that one you should have directory indexing disabled on the server. A hacker can’t “access” /WP-content/upgrade/ because it doesn’t exist. The “banned URLs” feature can effectively be used as a honeypot for URLs that bad scanners are likely to request but I wouldn’t recommend you try to block all URLs that would result in a 404.

Constant problem with communication here, come on WF support folks, clearly the word “access” is being used in place of the more technical term “request.” Have mercy on us.

A toggle for case sensitivity would seem to be a basic option for Wordfence, thanks for considering it.

MTN

P.S., to solve this problem with Wordfence I was all excited to change my Apache server so it converted all incoming URI requests to lower case. Turns out that’s not at all acceptable, as Apache Linux is case-sensitive when it comes to URI requests, and thus I’d end up breaking access to any existing mixed case URIs, for example photos such as /IMG_5678.jpg/ would result in a 404 error if requested as /img_5678/ Frustrating.

Conclusion: as suggested by WF Support in message above, there needs to be an option within Wordfence to make the “Block URL” feature case insensitive.

WFASA

I appreciate your theory that “Some people may be using the case sensitivity in banned URLs to block certain things and not others.” But since the Wordfence “Block URL” feature only blocks URLs that do _NOT_ exist, I doubt what you suggest is very common. Just thought I’d get that out there, as it’s easy to forget that the “Block URL” feature has no effect on existing files.