False Positive with Rule 942100 when matching text "大阪大"

[kkondo]

Hello,

I encountered a false positive with CRS rule 942100. The rule flagged the text "大阪大" as an SQL Injection attempt.

After investigating, it seems the issue might be related to the order of transformations applied in this rule. Currently, rule 942100 uses the following transformations:
t:none,t:utf8Unicode,t:urlDecodeUni,t:removeNulls

When I enabled detailed logging, I noticed:

• After t:utf8Unicode, libinjection does not detect an attack.

• However, after t:urlDecodeUni, the input is transformed into something like '*' and then libinjection detects it as an attack.

Based on this, I believe the false positive could be avoided by changing the transformation order to:
t:none,t:removeNulls,t:urlDecodeUni,t:utf8Unicode

Has anyone experienced similar issues? Would adjusting the transformation order be an acceptable solution, or is there a better approach?

Thank you for your guidance.

[Jozef Sudolsky]

Hi,

You're right, the topic of decoding and Unicode handling is quite
complex. We haven’t fully settled on the correct or final order of
transformations yet, so the behavior may vary depending on context.

For now, I’d recommend writing an exclusion rule to handle your
specific case. I can help you with that if you’d like.

Jozef



Citát kkondo <kko...@valtes-innovations.co.jp>:

> Hello,
>
> I encountered a false positive with CRS rule 942100. The rule flagged the
> text "大阪大" as an SQL Injection attempt.
>
> After investigating, it seems the issue might be related to the order of
> transformations applied in this rule. Currently, rule 942100 uses the
> following transformations:
> t:none,t:utf8Unicode,t:urlDecodeUni,t:removeNulls
>
> When I enabled detailed logging, I noticed:
>

> -

>
> After t:utf8Unicode, libinjection does not detect an attack.

> -

>
> However, after t:urlDecodeUni, the input is transformed into something
> like '*' and then libinjection detects it as an attack.
>
> Based on this, I believe the false positive could be avoided by changing
> the transformation order to:
> t:none,t:removeNulls,t:urlDecodeUni,t:utf8Unicode
>
> Has anyone experienced similar issues? Would adjusting the transformation
> order be an acceptable solution, or is there a better approach?
>
> Thank you for your guidance.
>

> --
> You received this message because you are subscribed to the Google
> Groups "OWASP CRS 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 visit
> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/4c26f06e-7ef4-4a37-9689-7006350dd10an%40owasp.org.

[kkondo]

Hi Jozef,

Thank you for your response and for confirming the complexity around decoding and Unicode handling.

I’ve decided to handle this case with an exclusion rule on my end.

That said, I’m still curious—do you think adjusting the transformation order globally for rule 942100 could be a viable solution, 

or might it introduce unintended side effects in other contexts?

K.Kondo

2025年10月26日日曜日 3:11:36 UTC+9 Jozef Sudolsky:

[Jozef Sudolsky]

I cannot tell for sure so, it MAY create holes in the firewall. I
recommend to create an exclusion rule.

Jozef





Citát kkondo <kko...@valtes-innovations.co.jp>:

> https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/e6231b81-95ba-4f81-94a1-6a5a5aed4736n%40owasp.org.