Newbie question how to deal with WYSIWYG editors

[Jakub Kuchar]

Good day, 

running on OWASP ModSecurity Core Rule Set ver.3.3.4

using froala WYSIWYG editor and POSTing its content resulting in block by 941160 rule in REQUEST-941-APPLICATION-ATTACK-XSS.conf

which i do totally understand why, since there is style= font-size: 20px;

Question here how others deal with WYSIWYG editors ?

• before asking here, i tried to go through https://github.com/coreruleset/coreruleset/blob/v3.3.4/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf#L273 which has CKEDITOR , but nothing come up when i was reading it
• yes, i can write SecRule with ctl:ruleRemoveTargetById=941160;ARGS:json.variables.input.content.body but that also means i am opening doors to attacks such as <iframe etc...
• in my scenario, i think after some work i can maybe also narrow it down what user can do and cannot do in froala editor, most complex thing is user copy pasting from other sources such as word and excel, which froala translates to html, so i was thinking maybe i could only open doors to style and some perhaps some more, but how ?

 [error] 9#9: *5 [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Rx' with parameter `(?i:(?:<\w[\s\S]*[\s\/]|['\"](?:[\s\S]*[\s\/])?)(?:on(?:d(?:e(?:vice(?:(?:orienta|mo)tion|proximity|found|light)|livery(?:success|error)|activate)|r(?:ag(?:e(?:n(?:ter|d)|xit)|(?:gestur|leav)e|start|d (3146 characters omitted)' against variable `ARGS:json.variables.input.content.body' (Value: `<p><span style="font-size: 20px;">test</span></p>' ) [file "/etc/nginx/conf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "181"] [id "941160"] [rev ""] [msg "NoScript XSS InjectionChecker: HTML Injection"] [data "Matched Data: <p><span style= found within ARGS:json.variables.input.content.body: <p><span style=\x22font-size: 20px;\x22>test</span></p>"] [severity "2"] [ver "OWASP_CRS/3.3.4"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/242"] [hostname "127.0.0.1"] [uri "/api/graphql"] [unique_id "167524006881.783794"] [ref "o0,15v34,49t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls"], client: 127.0.0.1, server: b2bcompany.lvh.me, request: "POST /api/graphql HTTP/1.1", host: "app.lvh.me", referrer: "http://app.lvh.me/"  

[Christian Folini]

Hey Jakub,

On Wed, Feb 01, 2023 at 01:13:36AM -0800, Jakub Kuchar wrote:
> running on OWASP ModSecurity Core Rule Set ver.3.3.4
> using froala WYSIWYG editor and POSTing its content resulting in block by
> 941160 rule in REQUEST-941-APPLICATION-ATTACK-XSS.conf
>

> which i do totally understand why, since there is *style= font-size: 20px;*

>
> Question here how others deal with WYSIWYG editors ?

I guess people just deal with the FPs one at a time.

> - yes, i can write SecRule

> with ctl:ruleRemoveTargetById=941160;ARGS:json.variables.input.content.body
> but that also means i am opening doors to attacks such as <iframe etc...

There is only an attack if the editor has a weakness. And actually, the full
set of WAF rules does not mean complete protection anyways. What CRS gives you
is a decent coverage, higher at higher paranoia levels. Taking out a single
rule for a single parameter adds a tiny attack window, but it's absolutely
not the only attack window you have. A WAF is never comprehensive.

So don't worry too much. Raising the paranoia level would be far more
effective than trying to work around this single false positive.

> - in my scenario, i think after some work i can maybe also narrow it

> down what user can do and cannot do in froala editor, most complex thing is
> user copy pasting from other sources such as word and excel, which froala

> translates to html, so i was thinking maybe i could only open doors to *style
> *and some perhaps some more, but how ?

You would have to inspect (-> Allowlist!) the
ARGS:json.variables.input.content.body and then depending on the result
of the inspection issue your rule exclusion ctl statement.

But as explained above, this is far too much work, probably not the only
FP in the long run and it gives you a false sense of security.

Better invest your resources into a higher paranoia level or other means
of defense.

Best,

Christian

>
>
> [error] 9#9: *5 [client 127.0.0.1] ModSecurity: Access denied with code
> 403 (phase 2). Matched "Operator `Rx' with parameter
> `(?i:(?:<\w[\s\S]*[\s\/]|['\"](?:[\s\S]*[\s\/])?)(?:on(?:d(?:e(?:vice(?:(?:orienta|mo)tion|proximity|found|light)|livery(?:success|error)|activate)|r(?:ag(?:e(?:n(?:ter|d)|xit)|(?:gestur|leav)e|start|d
> (3146 characters omitted)' against variable
> `ARGS:json.variables.input.content.body' (Value: `<p><span
> style="font-size: 20px;">test</span></p>' ) [file
> "/etc/nginx/conf/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line
> "181"] [id "941160"] [rev ""] [msg "NoScript XSS InjectionChecker: HTML
> Injection"] [data "Matched Data: <p><span style= found within
> ARGS:json.variables.input.content.body: <p><span style=\x22font-size:
> 20px;\x22>test</span></p>"] [severity "2"] [ver "OWASP_CRS/3.3.4"]
> [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag
> "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag
> "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/242"] [hostname
> "127.0.0.1"] [uri "/api/graphql"] [unique_id "167524006881.783794"] [ref
> "o0,15v34,49t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls"],
> client: 127.0.0.1, server: b2bcompany.lvh.me, request: "POST /api/graphql
> HTTP/1.1", host: "app.lvh.me", referrer: "http://app.lvh.me/"
>

> --
> You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/b2f2222d-f326-473a-bc80-e237d1c8fb64n%40owasp.org.

[Jakub Kuchar]

Hello Christian, 

thank you very much for your response. I really appreciate that. Let me check if i get it right, please

You would suggest writing 

SecRule

with ctl:ruleRemoveTargetById=941160;ARGS:json.variables.input.content.body

and then yes, i am running on paranoia level 1, default, so increase to 2 and iterate (catch more FPs)

I am running in Self-contained mode (happy with that, just few FP catched over couple of months) and i am bit confused by documentation

# The Paranoia Level (PL) setting allows you to choose the desired level

# of rule checks that will add to your anomaly scores.

And in Self-contained mode i am not scoring (if i am getting it right). If I will increase paranoia level by 

SecAction \
  "id:900000,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.paranoia_level=2"

in Self-contained mode, then rules with paranoia_level=2 will be included regardless right ?

Thank you and have a nice day

[Christian Folini]

Hey Jakub,

On Thu, Feb 02, 2023 at 01:14:28AM -0800, Jakub Kuchar wrote:
> thank you very much for your response. I really appreciate that. Let me
> check if i get it right, please
>
> You would suggest writing
>
> SecRule
> with ctl:ruleRemoveTargetById=941160;ARGS:json.variables.input.content.body

Yes.

> and then yes, i am running on paranoia level 1, default, so increase to 2
> and iterate (catch more FPs)
>

If you want better security, that's the way to go yes. Higher than PL2 is
probably not advised unless you have really sensitive data - a specific
threat model that calls for it.

> I am running in Self-contained mode (happy with that, just few FP catched
> over couple of months) and i am bit confused by documentation

Few people run this mode these days, but good if you only catched
a few FPs over a longer period. Wish that was the standard. :)

Either way, self-contained and anomaly scoring with threshold 5 boils
down to more or less the same behavior.

> And in Self-contained mode i am not scoring (if i am getting it right). If
> I will increase paranoia level by
>
> SecAction \
> "id:900000,\
> phase:1,\
> nolog,\
> pass,\
> t:none,\
> setvar:tx.paranoia_level=2"
>
> in Self-contained mode, then rules with paranoia_level=2 will be included
> regardless right ?

Yes, that's correct.

Good luck and please report back how it went.

Best,

Christian


--
If Henry Ford had cared to listen to customer demand, think of
how fast horses would be today?

[Jakub Kuchar]

Hello Christian, 

increasing paranoia level to 2 brought more FP as assumed. It is not a big deal to hunt them down, but i was still not able to cook the "good soup", because i was kinda of hoping 
while excluding rule 941160 then some other rule from paranoia level 2 will block "unsafe html tags" such as iframe, object, etc..but that did not happen. And while going a bit deeper it turns out that 941160 is having match after any html tag with space right after - as i debug it here https://regex101.com/r/QuePjm/1 which is indeed not in love with any web based WYSIWYG editor.

Nevermind, modsecurity is a open minded  - so i take my chance and write my custom rule to match unsafe tag and deny. I think we should be good. 

Thank you very much for taking my hand 

Jakub

[Christian Folini]

Hey Jakub,

Thanks for the update.

Yes, any WYSIWYG editor transmitting HTML will run into a ton of problems.
It's probably easiest to assume they know what they are doing on the
"content" field and disable XSS checks and a few others for it.

Disabling individual rules will always remain spotty.

If there is more than one "content" parameter, then difficult ...

Best,

Christian

> --
> You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.

> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/8668812e-9e2c-4454-ad42-9ad639fe5efan%40owasp.org.