Firewall blocks clients with 403 because of Sourcebuster since 8.5.1

[herlbauer]

Prerequisites

• I have carried out troubleshooting steps and I believe I have found a bug.
• I have searched for similar bugs in both open and closed issues and cannot find a duplicate.

Describe the bug

On my servers (running with Plesk) the Web Application Firewall (ModSecurity) blocks all clients (403) for the whole server because of a detected SQLmap attack within a cookie caused by the freshly included Sourebuster asset. The cookie key causing the error is "sbjs_first".

I have checked that this is not the case with 8.4.0 installations, most likely because there is no Sourcebuster included yet.

(I have solved this for the moment by renaming the Sourcebuster folder so the script cannot be loaded anymore.)

This is an error leading to the block:

[client 213.240.76.23] ModSecurity: Warning. Pattern match "[\\[\\]\\x22',()\\.]{10}$|\\b(?:union\\sall\\sselect\\s(?:(?:null|\\d+),?)+|order\\sby\\s\\d{1,4}|(?:and|or)\\s\\d{4}=\\d{4}|waitfor\\sdelay\\s'\\d+:\\d+:\\d+'|(?:select|and|or)\\s(?:(?:pg_)?sleep\\(\\d+\\)|\\d+\\s?=\\s?(?:dbms_pipe\\.receive_message\\ ..." at REQUEST_COOKIES:sbjs_first. [file "/etc/apache2/modsecurity.d/rules/comodo_free/22_SQL_SQLi.conf"] [line "66"] [id "218500"] [rev "18"] [msg "COMODO WAF: SQLmap attack detected||www.schumann783.com|F|2"] [data "Matched Data: |||id=(none) found within REQUEST_COOKIES:sbjs_first: typ=typein|||src=(direct)|||mdm=(none)|||cmp=(none)|||cnt=(none)|||trm=(none)|||id=(none)"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "www.schumann783.com"] [uri "/wp-content/themes/uncode/library/js/woocommerce-uncode.js"] [unique_id "ZaWx3TqXZU_oGW9FwqcnkgAAAIM"], referer: https://www.schumann783.com/

Expected behavior

The client should not be blocked from accessing sites on the server.

Actual behavior

After the first request for the specific page with Woocommerce 8.5.1, the server blocks the user's session and shows a 403 error.

Steps to reproduce

1. Update to Woocommerce 8.5.1

Status report information

Generated at: 2024-01-15 22:57:05 +00:00

Isolating the problem

• I have deactivated other plugins and confirmed this bug occurs when only WooCommerce plugin is active.
• This bug happens with a default WordPress theme active, or Storefront.
• I can reproduce this bug consistently using the steps above.

[therealgilles]

+1 to this problem. My OpenLiteSpeed server started to send back 403s because the sourcebuster sbjs_first cookie triggered the same COMODO rule.

[dbarproductions]

+1 here, although I thought it was related to my sites being in a subdirectory install. Got lots of 403s, mainly for images, and sometimes the too many redirects message from the browser, and could not get into the admin dashboard at all (on two sites, one a single site install in a subdirectory, and another multi-site install using subdirectories for each site). Only solution was to delete the woocommerce folder via CPanel File Manager and then upload WC 8.4.0 and clear all cookies after that before it went back to normal.

[budzanowski]

Hi,

This problem is related to a new feature available since WooCommerce 8.5 called Order Attribution Tracking

There are two ways that one can go about the 403 errors:

1. In case you do not want to use this feature you can disable it. Info from FAQ Cookies are blocked by a Web Application Firewall (WAF)
2. In case you want to use it then a specific WAF rule triggering the issue needs to be updated or disabled to allow proper functioning of the sites and the feature. For example, the following Plesk article explains how to do it:
   Plesk WP website is not accessible with the 403 Forbidden error after a WooCommerce plugin update

I hope this information helps.

[herlbauer]

Thank you for the solution, seems to work.
But I have to ask: If this is a feature, not a bug, and it's causing such problems... Why is it enabled per default anyway? Not to talk about setting a cookie without asking for specific permission in the EU (DSGVO)...

[MarkTallentire]

Same as #43413 (comment) Linking here because this one seems to actually have a response.

Please turn this off by default.

[dbarproductions]

I agree that this should NOT be enabled by default and should have a big warning message that it may completely break your site if enabled. On our server, with on single site install, and one multisite install, I could not even access the admin dashboard, so there would be no way to disable this without figuring out the option meta key and disabling it by modifying the entry directly in the database. Our hosting company had no clue either and thought it had something to do with the Wordpress installs being subdirectory based (even though they have worked fine that way for many years). If your site has most plugins set to auto-update, then you might not even know it was WooCommerce that caused your site to break. I only figured it out by looking at the files on the server to figure out what was updated before things stopped working. Then I had to completely delete WC via the file manager and try out older versions until I found one that worked again (8.4.0). So, this is going to break a lot of sites, and a large number of those people whose sites breaks will not be able to figure this out. Rewriting the firewall rules is NOT a solution that most people would be able to figure out, especially if their hosting company has no clue why the site is not working.

[XGhozt]

I'm also seeing this. Why are the posted solutions to "disable the security rule" or "disable the feature". Is this really how Woo handles issues like this? I would rather we have a proper solution instead of suggesting that we reduce the security of the entire server or website(s). If anything, a hot-fix needs to be released to disable your feature by default until it's coded in a way that doesn't expose the website/server to an SQLmap attack.

Related pattern matching:

Pattern match "[\\[\\]\\x22',()\\.]{10}$|\\b(?:union\\sall\\sselect\\s(?:(?:null|\\d+),?)+|order\\sby\\s\\d{1,4}|(?:and|or)\\s\\d{4}=\\d{4}|waitfor\\sdelay\\s'\\d+:\\d+:\\d+'|(?:select|and|or)\\s(?:(?:pg_)?sleep\\(\\d+\\)|\\d+\\s?=\\s?(?:dbms_pipe\\.receive_message\\ ..." at REQUEST_COOKIES:sbjs_first.

[thisissandip]

Also reported in: https://wordpress.org/support/topic/error-403-64/#post-17349849

[thisissandip]

7588956-zen

[thisissandip]

7588492-zen

[vinylsaviour]

Hi folks - we've been directed here by Woocommerce support to add to the debate. Echoing above - we have experienced the same 403 errors discussed. This closed our business for 6 hours yesterday while we dusted off our thinking caps to figure out a solution - after isolating the issue we wound back to version 8.4.0 and our now stable again.

Anything that knowingly causes outage should absolutely not be switched On by default. We felt like beta testers when we realised what had caused the problem.

We wasted ad spend and lost revenue as a function of this.

Many small businesses that don't have the time or the technical capacity to resolve these things easily are on the receiving end of this. Many of them are likely still not aware this is an issue having happily clicked update and walked away.

[AlanStainer]

I have had to fix multiple sites with this issue over the last couple of days. It would be wonderful if that setting was turned off by default.

[therealgilles]

In case you want to use it then a specific WAF rule triggering the issue needs to be updated or disabled to allow proper functioning of the sites and the feature. For example, the following Plesk article explains how to do it:
Plesk WP website is not accessible with the 403 Forbidden error after a WooCommerce plugin update

Disabling the rule entirely for a domain is not a serious solution. Please provide a viable solution.

[budzanowski]

@therealgilles

I am sorry that you are experiencing the issues. At this stage, we are exploring various solutions, including the possibility of a cookie-less implementation, though it's not yet clear if this can be fully realized.

We are committed to ensuring that everyone benefits from the Order Attribution feature. We recognize its significant value in providing merchants with a more informed and analytics-driven decision-making process. This feature is intended to become a fundamental part of your business strategy and operations.

If disabling the WAF rule for now is not an option please disable the feature as previously advised.

[tomandersen]

This is a big issue. Number 1 thing is to keep sites running. Me thinks a patch just disabling the problem code is in order until this is fixed. We have a lot of sites with woo that may fall over at any time now.

[Emperor42]

(I posted this issue as duplicate) Order Attribution would be highly beneficial however, it can't be used as it can crash a website. Furthermore some servers do not log as a 403 Error they will log as a 500. The 500 error scenario would be harder to debug as it is more generic. I can also confirm that there were no logs present showing additional information regarding the error (In the case of my client). Weakening our firewall is a non-started and thus we have been forced to revert to 8.4.

Bear in mind Order Attribution would be EXTREMELY helpful in the case of my client.

[Tofandel]

I also commented about this on #39701 (comment)

Until you can rewrite this correctly please publish a patch release disabling this feature by default, it should be opt in, not autoupgrade to a patch release that breaks your site and your GDPR policy

The cookieless version would simply require getting the output of the lib without setting cookies (but there is no option for it) and then run an XHR request to set those values in the session, or option 2, set all those in localStorage instead of cookies and send them when needed

It would also be nice to add a test to check for new cookies in PRs and only make those PRs available on major releases, this is quite important nowadays with GDPR policies

[layoutd]

Hi, thanks for reporting the issues and the feedback.

One of the main Web Application Firewall rulesets that was triggering a false positive on Sourcebuster cookies (Comodo WAF) released a fix this week. All web hosts that use that ruleset (Plesk, for example, from what we've seen) and are up to date should no longer run into this issue.

In parallel, we're looking at adding some configuration features to the Sourcebuster library itself to change how the source data is stored (single cookie, local storage, etc).
woocommerce/sourcebuster-js#3

We'll include this updated library in WooCommerce as soon as possible.

[evertefeuille]

Hi,
@layoutd the cookie trigger also a false positive in Azure Application Gateway WAF not just Comodo WAF.

[layoutd]

Thanks for the clarification, @evertefeuille. I looked to see if I could find what ruleset Azure Application Gateway uses, it appears to be OWASP which hadn't been identified as giving this false positive. Do you know if that is right, or if Azure uses a custom ruleset? If it's OWASP, do you know which ruleset it is? (3.2, 3.1, etc.) Do you by any chance have an example of the error/log/warning?

[evertefeuille]

OWASP 3.0
RuleId 941150
RuleGroup 941-APPLICATION-ATTACK-XSS

Pattern match "(?i)\b(?:s(?:tyle|rc)|href)\b[\s\S]*?=" at REQUEST_COOKIES:sbjs_current

Matched Data: src= found within REQUEST_COOKIES:sbjs_current: typ=referral|||src=bing.com|||mdm=referral|||cmp=(none)|||cnt=/|||trm=(none)|||id=(none)

[layoutd]

Thanks @evertefeuille, that's a big help 👏🏻 🙇🏻

[therealgilles]

Anyone has a copy of the updated COMODO rule?

[layoutd]

Anyone has a copy of the updated COMODO rule?

The only change, I believe, is !REQUEST_COOKIES:/^sbjs_.*/ instead of !REQUEST_COOKIES:sbjs_current:
1.241 for Apache

SecRule REQUEST_URI|ARGS_POST|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|XML:/*|!ARGS:/body/|!ARGS:/content/|!ARGS:/description/|!ARGS:/fl_builder_data\[node_preview\]\[text\]/|!ARGS:/message/|!ARGS:Post|!ARGS:desc|!ARGS:text|!ARGS:text_message|!ARGS:yoast_wpseo_keywordsynonyms|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|!ARGS:sql_query|!ARGS:site_coordenacao|!REQUEST_COOKIES:/^sbjs_.*/ "@rx [\[\]\x22',()\.]{10}$|\b(?:union\sall\sselect\s(?:(?:null|\d+),?)+|order\sby\s\d{1,4}|(?:and|or)\s\d{4}=\d{4}|waitfor\sdelay\s'\d+:\d+:\d+'|(?:select|and|or)\s(?:(?:pg_)?sleep\(\d+\)|\d+\s?=\s?(?:dbms_pipe\.receive_message\((?:chr\(\d+\)(?:\s?\|\|\s?)?)*,\d+\)|\(select\s\d+\sfrom\spg_sleep\(\d+\)\))))(?:\s?\b(?:and|or)\s\(?(?:(\d{4})=\1|'(\w{4})'='\2|'%'=')|--\s?\w*|#)$|\(select\s?\(case\swhen\s?\(\d+\s?=\s?\d+\)\sthen\s\d+\selse\s(?:0x[\0-9a-h]+|\d+)\send\)\)|(?:(?:\b(?:and|or)|&&|\|\|)\W+\(?'?(?:\w{1,4}|%)'?\)?(?:!?(?:=|<|>))\(?'?\w{0,4}'?\)?|\border\W+by\s\d+)(?:#|--\s?\w{0,4})?$|(\'\s?(?:or|and)\squarter\(null\)\s?is\snull;)" \
	"id:218500,msg:'COMODO WAF: SQLmap attack detected||%{tx.domain}|%{tx.mode}|2',phase:2,capture,block,setvar:'tx.sqli_points=+%{tx.points_limit4}',setvar:'tx.points=+%{tx.points_limit4}',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',ctl:auditLogParts=+E,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalizePath,t:compressWhiteSpace,t:lowercase,rev:18,severity:2,tag:'CWAF',tag:'SQLi'"

[layoutd]

Just adding that an OWASP user commented in the above issue that the following exclusion rule should work:

# src= found within REQUEST_COOKIES:sbjs_first: typ=typein|||src=(direct)|||mdm=(none)|||cmp=(none)|||cnt=(none)|||trm=(none)|||id=(none)

SecAction \
	"id:1003,phase:1,t:none,nolog,pass,\
		ctl:ruleRemoveTargetById=941150;REQUEST_COOKIES:sbjs_current,\
		ctl:ruleRemoveTargetById=941150;REQUEST_COOKIES:sbjs_current_add,\
		ctl:ruleRemoveTargetById=941150;REQUEST_COOKIES:sbjs_first,\
		ctl:ruleRemoveTargetById=941150;REQUEST_COOKIES:sbjs_first_add"

[loulemos]

https://wordpress.org/support/topic/error-403-64/#post-17349849

Hellish, can't imagine what other devs with many sites are going trough. This was a significant mistake by the Woo team.

[diablodale]

How can this feature be disabled programmatically or with WPCLI? Naturally, no admin wants to mouse it.
I see nothing at https://github.com/woocommerce/woocommerce/wiki/WC-CLI-Commands

[layoutd]

@diablodale, using values "yes" and "no" with wp option update ought to do it:

wp option update woocommerce_feature_order_attribution_enabled "no"

[layoutd]

For further and up-to-date information on this issue, please refer to the Woo.com Order Attribution Tracking documentation, specifically the section "Cookies are blocked by a Web Application Firewall (WAF)".

Briefly: some of the most common WAF rulesets have been updated to whitelist the cookies that were causing false positives. For less common configurations, the current suggested solutions are to contact the hosting provider to discuss WAF exceptions, or to disable order attribution (in WooCommerce > Settings > Advanced > Features, or programmatically as explained in the documentation.

We will be considering changes for future iterations of the feature to help reduce firewall issues.