Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#35412 closed defect (bug) (fixed)

ModSecurity2 blocks Potential Obfuscated Javascript in outbound anomaly

Reported by: becki's profile becki Owned by: dd32's profile 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:


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
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 8 years ago.

Download all attachments as: .zip

Change History (11)

#1 @swissspidy
8 years ago

  • Component changed from General to Emoji

#2 @dd32
8 years 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
8 years 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
8 years 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
8 years 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.

8 years ago

#7 @dd32
8 years 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
8 years 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
8 years ago

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

Opening for 4.4.2

#10 @dd32
8 years 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.