IPS defense: Cross-site scripting over HTTP

[Daniel_Kavan]

Hi mates,

Our internal team is 'concerned' about  CP's Cross-site scripting over http ips defense.  Is there anyway we can calm his nerves that it won't block GOOD input?  Can we provide any more detail on the rule?   The details are like KFC secret recipe correct?  Or does this IPS rule correlated with http methods in inspection at all, which provides a nice ale cart menu of defenses.   See attached. 

I his words:

Comment

I would say it's not so much that we need users to be able to input this kind of stuff, but that the rule is not very robust and doesn't give us confidence that it will only stop bad user input.

It started off with a vulnerability scan that inserted (escaped) html into some fields. The error made us think the scan had somehow succeeded in compromising something, so that took some time to debug.

But as noted, the rule is blocking invalid or escaped html it doesn't need to block, doesn't block all valid html, and doesn't block all kinds of requests with bad html. E.g. we were able to insert those values in the first place as normal form submissions - x-www-form-urlencoded. But when POSTing the same data as multipart/form-data it triggered the rule. It also seems to just be a regex or something that casts a pretty wide net - for example "onerror=asdgasd asdgasafh alert(" will fail. So it looks like there's at least one ".+" involved somewhere that makes me nervous.

Personally I would think it'd be best to rely on stuff like CSRF tokens, SameSite, etc. and just enforce that we have that.

IMO it'd be helpful if we could see exactly what the rules are to allay our concerns. I've had to piece it together by trial and error. I just find the idea that a user could type unspecified wonky (but harmless) strings into a text input and end up with a generic network error a bit worrying. Or that you can submit such strings via some methods but certain other requests might then fail. Part of it is I'm not sure how to catch and log such errors on the client since they don't seem distinctive enough from normal connection errors, so we might not know it's happening without a user report.

[Daniel_Kavan]

This was our response.   The accepted protections for apps is to use parameterized queries for database functions and to escape anything that comes out of the database when building responses. If this is a Django app using the standard patterns, that should be built-in automatically. Then the app should also have valid field rules for acceptable responses, but that gets tricky for text fields and there is only so much you can do before you start blocking legitimate entries.

their reply

We're using Spring Boot and already do all of that or have it done for us. These IPS rules though are not blocking html - they're blocking sanitized "HTML-like" values based on (to me) unknown patterns. Which leaves me with questions like - if I'm a user and I type "<missing>" in a comment field is that going to get interpreted as an HTML tag? As it turns out, no, but that's sort of the level the rule seems to operate on.

[the_rock]

I agree with Val here, for sure...hard to say for certain unless tests are run.

Andy

[Daniel_Kavan]

And in general you guys agree, the only option I have it active, inactive, detect, right?

[_Val_ · Accepted solution]

The best approach would be to run specific tests and see the results and then tune IPS with exceptions, if required. It is virtually impossible to make a general statement for the cause.