WordPress.org

Make WordPress Core

#35412 closed defect (bug) (fixed)

ModSecurity2 blocks Potential Obfuscated Javascript in outbound anomaly

Reported by: becki Owned by: dd32
Milestone: 4.4.2 Priority: normal
Severity: normal Version: 4.4.1
Component: Emoji Keywords: has-patch needs-testing fixed-major
Focuses: javascript Cc:

Description

hello there ;)

since the 4.4.1 update mod_security reports a potential obfuscated javascript in outbound and blocks wordpress

i'm using OWASP_CRS/2.2.9 and mod_security rule triggering this is ID 981004 and it reports the following:

Rule Message: Potential Obfuscated Javascript in Output - Excessive fromCharCode
Event: Pattern match "(?i)(String\\.fromCharCode\\(.*?){4,}" at RESPONSE_BODY
Data: Matched Data: String.fromCharCode(55356,56806,55356,56826),0,0),d.toDataURL().length>3e3):\x22diversity\x22===a?(e.fillText(String.fromCharCode(55356,57221),0,0),c=e.getImageData(16,16,1,1).data.toString(),e.fillText(String.fromCharCode(55356,57221,55356,5
Tag: OWASP_CRS/MALICIOUS_CODEbugtraq,13544
Rule Message: Outbound Anomaly Score Exceeded (score 4): The application is not available
Event: Operator GE matched 4 at TX:outbound_anomaly_score 

mod_security regex is matched in the _wpemojiSettings / function and finally resulting in mod_security blocking wordpress ;(

Attachments (1)

35412.diff (3.8 KB) - added by dd32 23 months ago.

Download all attachments as: .zip

Change History (11)

#1 @swissspidy
23 months ago

  • Component changed from General to Emoji

#2 @dd32
23 months ago

This is caused by [36161] / #33592.

I'm not sure we should do anything to avoid this, that mod_security rule is really restrictive..

What's causing this, is that the file wp-emoji-loader.js contains 5 occurrences of String.fromCharCode( and mod_security only allows 3 instances.
In 4.4.0 we only had 3 instances of that function call.

One reason I say that mod_security rule is crazy, is because we can avoid it simply by doing z=String.fromCharCode; and calling z() instead, completely bypassing it.. and any JS can do the same (I'm actually surprised our minification process didn't do that automatically)

#3 @Clorith
23 months ago

I don't think we need to touch this, the vendor has already acknowledged the false positive and stated they will fix it.

Of course it's up to hosts to apply the fixed rules, but it's still a silly rule.

#5 @kraftbj
23 months ago

If there's something we can do on our end to pass the existing rule that is relatively cheap, we should do that. In my experience, hosts are often *very* slow at updating rules, or do so only after being prodded from an user experiencing the issue and then, often, only as a one-off exception.

#6 @Clorith
23 months ago

I've not got the shared host experience here, so I'll bow to @kraftbj and his wisdom :)

The approach mentioned by @dd32 would probably be a viable solution for 4.4.2 to mitigate the issue, especially now that it turns out there's two vendors offering this same rule, indicating we might see more vendors pick it up as well.

@dd32
23 months ago

#7 @dd32
23 months ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Awaiting Review to 4.4.2

I think this patch works.. it doesn't throw a JS error at least :)

#8 @dd32
22 months ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 36359:

Emoji: Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served.

Fixes #35412 for trunk.

#9 @dd32
22 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Opening for 4.4.2

#10 @dd32
22 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 36410:

Emoji: Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served.

Merges [36359] to the 4.4 branch.
Fixes #35412.

Note: See TracTickets for help on using tickets.