BPS blocks POST requests that have been whitelisted already

[Living Miracles]

Hi,

On my two SiteGround sites that use a custom membership setup (using the Restrict Content Pro plugin), I’ve started seeing an issue I thought was fixed. When a subscriber to the sites tries to update their membership, BPS Pro blocks the POST request that is necessary for this to function. The membership update page contains a Restrict Content Pro form that allows a subscriber to update their info and change their membership. Upon submission of this form, BPS Pro’s 403 Forbidden Error page pops up and an entry gets added to the Security Log. Here’s the entry:

[403 POST Request: February 9, 2020 - 2:59 pm]
BPS Pro: 14.3
WP: 5.3.2
Event Code: BFHS - Blocked/Forbidden Hacker or Spammer
Solution: N/A - Hacker/Spammer Blocked/Forbidden
REMOTE_ADDR: 96.127.128.117
Host Name: usm1942.sgded.com
SERVER_PROTOCOL: HTTP/1.0
HTTP_CLIENT_IP: 
HTTP_FORWARDED: 
HTTP_X_FORWARDED_FOR: 216.250.39.154
HTTP_X_CLUSTER_CLIENT_IP: 
REQUEST_METHOD: POST
HTTP_REFERER: https://mysite.com/subscription-update/
REQUEST_URI: /subscription-update/
QUERY_STRING: 
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
REQUEST BODY: rcp_level=4&rcp_gateway=paypal&rcp_agree_to_privacy_policy=1&rcp_auto_renew=on&registration_type=&membership_id=0&rcp_registration_payment_id=225&g-recaptcha-response=03AOLTBLTvFfzjjPfvzQC0bud51tZ211CQ1FmbIjkfC9uZNZfWq6_0c7r5Bj2n_DWPG_u0vM728Uxhbj9TOjzBBtFV2FTMBSE5ae_iIyeE3JvaFNeyuywgyrlhqDV9EVl0T_N73FsYkm7gDWOSw_QNBrQsRqL4N6njktt8UiJvBSvkChO6ncUOiPGUX78mnOU3rXoQZOYK5TCFpTSoPO8yZyLj5KL9FUJCf5F0yxJiYfUOYdFKOg18F6kLu26Pb0tt8BRsOhrF3qA8JQJeon4BUsAnL6FMjZH0qV9_kyzV2eoeIAGzQFmyZcANXIlYqrxTzTF1F7qCnfU

I’ve got the following code in Box 8 of the root .htaccess Custom Code area that was preventing this error from happening before, but at some point, I don’t know when, it must have stopped working:

# BPS POST REQUEST ATTACK PROTECTION
RewriteCond %{REQUEST_METHOD} POST [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
# Whitelist the WordPress Theme Customizer
RewriteCond %{HTTP_REFERER} !^.*/wp-admin/customize.php [NC]
# Whitelist XML-RPC Pingbacks, JetPack and Remote Posting POST Requests
# RewriteCond %{REQUEST_URI} !^.*/xmlrpc.php [NC]
# Whitelist Network|Multisite Signup POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-signup.php [NC]
# Whitelist Network|Multisite Activate POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-activate.php [NC]
# Whitelist Trackback POST Requests
# RewriteCond %{REQUEST_URI} !^.*/wp-trackback.php [NC]
# Whitelist Comments POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-comments-post.php [NC]
# Whitelist RCP Login Form
RewriteCond %{REQUEST_URI} !^.*/sign-in/ [NC]
# Whitelist Custom DB Login
RewriteCond %{REQUEST_URI} !^.*/database/ [NC]
# Whitelist RCP Subscription Update Page
RewriteCond %{QUERY_STRING} !^.*/subscription-update/ [NC]
# Whitelist RCP Account Update Page
RewriteCond %{REQUEST_URI} !^.*/account-update/ [NC]
# Whitelist RCP Account Membership Page
RewriteCond %{REQUEST_URI} !^.*/membership/ [NC]
# Whitelist RCP "Special" Page
RewriteCond %{REQUEST_URI} !^.*/special/ [NC]
# Whitelist ManageWP POST Request to wp-load.php by Query String
RewriteCond %{QUERY_STRING} !^mwprid=(.*) [NC]
# Whitelist WP JSON POST-related Requests by Query String to prevent Gutenberg from breaking
RewriteCond %{QUERY_STRING} !^_locale=(.*) [NC]
# Whitelist Monarch Plugin POST Requests by Query String
RewriteCond %{QUERY_STRING} !^et_pb_preview(.*) [NC]
RewriteRule ^(.*)$ - [F]

Can you see why it stopped working? As you can see, there are several lines whitelisting various Restrict Content Pro-related (RCP) pages, such as /sign-in/, /subscription-update/, /account-update/, and /membership/.

Thanks for your help!

[AITpro Admin]

Your POST attack protection code whitelist rules look good to me. I don’t see anything obvious in the POST Query String that would be blocked except for maybe Google ReCaptcha.  When did you add Google ReCaptcha for your RCP forms for this website? Also double check that the POST attack protection code in your root htaccess file matches the POST attack protection code that is saved in BPS Custom Code.  I may need to login to this site since this looks like the type of problem that is not going to be easy to figure out just based on the Security Log entry.

Or of course you get rid of the POST attack protection code. In the last version of BPS Pro we decided to get rid of the Bonus Custom Code Notice since the POST attack protection code was included in the Notice and frankly it’s too technically complicated to mess with for the average person. Too many variables, too many things that could change (in plugins, themes, etc.) on an ongoing basis.

At one point we were going to make the POST attack protection bonus custom code a “full” feature in BPS Pro and automate everything like we did with the BPS Pro Plugin Firewall feature. We decided to just phase out the POST attack protection bonus custom code altogether instead.  In reality the POST attack bonus custom code is not something that we consider critical or essential. So basically is just not worth the potential headaches since it is too complex to fiddle with due to not being a “fully” automated BPS Pro feature.

I’d be happy to login to this site and figure out the problem. So let me know if you want to keep the POST attack protection bonus custom code or not. 😉

[Living Miracles]

Hi,

Thank you for sharing more of the context around the POST Request attack protection custom code and for your offer to sign into our site to take a closer look at this for us. We want to actually take your advice and go ahead with removing the POST Request attack protection custom code from all our WordPress sites but we’ve been noticing that we’ve been getting a lot of the following “403 POST Request” entries in our Security Logs lately (especially our sites with higher traffic):

[403 POST Request: February 10, 2020 - 12:41 pm]
BPS Pro: 14.3
WP: 5.3.2
Event Code: BFHS - Blocked/Forbidden Hacker or Spammer
Solution: N/A - Hacker/Spammer Blocked/Forbidden
REMOTE_ADDR: 142.93.2.157
Host Name: 142.93.2.157
SERVER_PROTOCOL: HTTP/1.0
HTTP_CLIENT_IP: 
HTTP_FORWARDED: 
HTTP_X_FORWARDED_FOR: 
HTTP_X_CLUSTER_CLIENT_IP: 
REQUEST_METHOD: POST
HTTP_REFERER: https://mysite.tld/
REQUEST_URI: /xmlrpc.php
QUERY_STRING: 
HTTP_USER_AGENT: PHP/7.2.44
REQUEST BODY: <?xml version="1.0" encoding="utf-16" standalone="yes"?>
<methodCall>
	<methodName>pingback.ping</methodName>
	<params>
		<param>
			<value><string>https://www.theguardianonline.com/5g-male-review/</string></value>
		</param>
		<param>
			<value><string>https://mysite.tld/the-mystical-teachings-of-jesus/</string></value>
		</param>
	</params>
</methodCall>

Can you confirm that we’re still covered security wise by BPS Pro’s other features?

Thank you!
Living Miracles

[AITpro Admin]

All of the BPS Pro security features combined cover all of a website’s security bases.  The POST Attack Protection Bonus Custom Code was and still is just an optional level of protection that is basically not really ready for prime time or essential. Just to reiterate, we originally intended to eventually make the POST Attack Protection code an additional “fully” automated feature in BPS Pro, but bailed out on that idea because it is not critical or essential. Frankly, in our opinion, BPS Pro has too many security features. We went a bit overboard in our opinion. 😉

[Living Miracles]

Hi,

Thank you again for your response and for confirming that for us! In this case, we’ll move forward with just removing that custom code from our WordPress sites then.

Living Miracles

[Author]

Posts