So background – I have been using cloudflare page rules to redirect /xmlrpc.php requests to http://0.0.0.0. I thought this was a good solution since none of that brute force traffic would hit my servers and would just hit them back with a request.
Fast forward to brute force attempts that were finding a way around all my security measures (cloudflare access for login page, xmlrpc forwarding, etc.). Discovered that they were actually getting around my page rule (forwarding *mysite.com/xmlrpc.php*) by adding extra slashes before xmlrpc (ie. mysite.com//xmlrpc.php). Simply updating the rule to be *mysite.com/*xmlrpc.php* seems to solve the issue.
Figured I would post this here in case anyone else is using a similar method to block xmlrpc. Hope it helps someone out there.
WAF bypass techniques are so interesting.
I realize this is for XSS, but have a read of the OWASP bypass techniques. This could give you an idea of how hard it is to potentially use pattern matching rules to block these types of things.
May be worth while to brush up on regex. Maybe if you add some wildcards it could prevent this but boy theres probably other really creative ways to bypass.
Maybe disable xmlrpc in your functions file?
This is my standard setup:
In my functions.php on my theme:
add_filter('xmlrpc_enabled', '__return_false');
In my .htaccess file:
<Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>
And this firewall rule on cloudflare (which denies // work arounds):
(http.request.uri.path contains "xmlrpc.php")
Overkill? Maybe. All bases covered, YES.
Why not just add this as a firewall rule?
CAPTCHA:
((http.request.uri.path contains "/xmlrpc.php") or (http.request.uri.path contains "/wp-login.php") or (http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and not http.request.uri.path contains " /wp-admin/theme-editor.php")) and ip.geoip.country ne "MY"
