feat: Allow multipart/mixed request with special "OData batch" structure

[HeikoTheissen]

I came to this repository from coreruleset/coreruleset#3858 (comment). With that pull request, the OASIS OData Technical Committee had asked for content type multipart/mixed to be included in the list of allowed request content types in OWASP CRS, because this content type is used by payloads in the OData V4.02 multipart batch format.

The pull request was rejected, because the ModSecurity WAF engine cannot currently handle this content type. It does handle multipart/form-data, though, and I wonder whether it could also learn to handle the subset of multipart/mixed that is needed for multipart batch, and whether OWASP CRS could be extended to allow multipart/mixed payloads only if they belong to that subset.

Payloads from that "multipart batch" subset meet the following additional requirements:

They are made up of parts that have themselves restricted content types:

• Type A: Parts of this type have Content-Type: application/http and the HTTP request that it represents is either a GET request or has Content-Type: application/json or Content-Type: application/atom+xml.
• Type B: Parts of this type have Content-Type: application/http and the HTTP request that it represents is a POST request with Content-Type: multipart/mixed whose parts are of type A.

Moreover, the URL of the outer multipart batch payload has the form https://server/path/$batch, and the URLs of the requests contained in the parts must also start with https://server/path/.

[airween]

Hi @HeikoTheissen,

thanks for reaching us.

I'm afraid that parsing a multipart/mixed content type is not as trivial as it seems at first sight.

Unfortunately there is no any "standard" multipart parser library (even thought there are few of them, like iafonov's (last commit was 9 y ago), francoiscolas's (9 y ago) and abiiranathan's (5 m ago with 8 commits)), and as I see none of them support multipart. Probably this is why both engines (mod_security2/libmodsecurity3) have an own multipart parser.

The solution would be to extend these parsers, which is a lot of work, especially since we're talking about a WAF, and I think it would be weird if the WAF had a non-full content type parser. (I mean if anyone starts to extend the parsers (for both engines) it's not enough to add cases above, but it must create a full featured multipart/mixed parser.)

May be you should start in the direction of some external processor, eg. implement a minimal Lua parser which fits your expectations, and pass the request to that.

[marcstern]

Even if it cannot be parsed, nothing forbids you to add this Content-Type to the allowed ones for your environment

[airween]

Even if it cannot be parsed, nothing forbids you to add this Content-Type to the allowed ones for your environment

That can lead to a bypass - see this blog post (under the head "Bypass details").