I think this is fine. However, I want to point out that t:urlDecodeUni will probably decode %FFuu in addition to the regular URL decoding. At least IIS might be vulnerable through such a payload.

Hm, you are right. Too bad modsec is not providing a separate transformation for %FFuu. We should discuss this in more detail.

The discussion around the custom encoding for IIS has come up repeatedly. I wonder whether we could just drop support for it entirely and create a plugin instead that takes care of it. Probably not that easy, because we have to duplicate a ton of rules in the plugin...

That would be annoying, but I see the IIS problem. It's double problematic since we have zero insight into the number of IIS installations out there. It is super exotic, but we know it exists.

Can we create a separate issue for this problem and continue with this PR and the fixing of R9V-240531, apparently letting IIS users in the rain for a period of time.

Sounds good to me.

I think this one's still not fully resolved, @azurit?

@theseion No, it's not, thanks.

Can we create a separate issue for this problem and continue with this PR and the fixing of R9V-240531, apparently letting IIS users in the rain for a period of time.

@dune73 Can you be more specific? Should i create an issue describing that rules 921151, 932190, 942441, 942442 and 942460 are not doing* IIS specific decing of ARGS* data?

• after this PR is merged

@azurit Yes, I think we ought to create an issue that describes the remaining IIS problem after this PR is merged. Based on that issue we can then discuss a solution, a plugin approach, or drop support when decoding is involved or entirely because we lack insight into the user base and exposure and knowledge and IIS testing installations and what not.