MULTIPART_UNMATCHED_BOUNDARY - Rule 330792

[mrsant]

Hi. We recently started using the real time WAF rules-only subscription on our shared hosting platform. We have found an number of hits on this rule in 00_asl_zz_strict.conf from various bone-fide web applications being caught out with bone-fide (i.e. non-malicious) requests.

Our environment is cpanel throughout, and we have removed the default rule that also checks this factor from modsec2.conf

It appears that a double hyphen -- somewhere in the posted data causes this issue. I see a recent prestashop github update (which affects several of our clients) that reflects this
http://forge.prestashop.com/browse/PSCFV-10600
https://github.com/PrestaShop/PrestaSho ... c49f114929

I have also just dealt with a ticket where the customer's POST data included '&move_to=-- please select one --' and this, too, appears to be the only thing triggering the rule.

This seems a little prone to false positives, despite the ominous warning in the rule's log text [msg "Multipart parser detected a possible unmatched boundary. This may be an impedence mismatch attack, a broken application or a broken connection. This is not a false positive. Check your application or client for errors."]

Is this rule usable/sensible in a real-world shared hosting environment in its current form?

[mikeshinn]

Its actually internal to modsecurity, the rule just does this:

SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0"

So this rule only triggers when modsecurity internally says the message is multipart, and that it has an unmatched boundary. And we agree, the internal code in modsecurity is a bit simplistic for this check. So we have changed this rule to not block by default. You'll just get an alert, and you'll need to check to see if this is really an attack or just a false positive. modsecurity will take no blocking action by default.

If you are using ASL, you can just configure this rule to block if you do not experience false positives with this internal modsecurity check.

Happy Thanksgiving!

[faris]

I've just had a customer shunned by this rule after using webmail to send a "simple" message with no attachments or links or anything like that.

I hadn't expected to see an issue with this because Mike mentioned it had been changed not to shun by default. But is that in a fresh install only? Because it is still obviously shunning for me.