Multipart parsing error (init): Multipart: Invalid boundary in C-T (malformed) - being received on a compliant header

[nneul]

(Refiling here instead of owasp-modsecurity/ModSecurity#1389 )

Example header in the requests:

Content-Type: multipart/form-data; boundary="x-hx6COixr31cBVcPHyPgwef.gY5tAoL4RbHUpXrTPSUgO9K6IqTafzKBcmTJ.opw9lYit"

Content-Type: multipart/form-data; boundary="Sgt-3Wo5day44dJGZ/0KW/q0FRjE4hVqSxCGvkhnCwKAeuprMel1s0kZvXhe7/s5hrh/Pg"

According to the RFC2616 19.2.2 quotes are valid but optional.

RFC2046 doesn't include it, but if you look over RFC2046 they show multiple examples with and without quotes in the doc itself:

 boundary := 0*69<bchars> bcharsnospace
 bchars := bcharsnospace / " "
 bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                  "+" / "_" / "," / "-" / "." /
                  "/" / ":" / "=" / "?"

I'm going to file an issue with MS/Azure as well since I'm seeing this on their WAF, but the underlying ruleset is coming from this project.

[csanders-git]

What browser is generating this content?
Also although you don't list it i'm fairly confident that the rule in question is provided by modsecurity (not CRS), in fact i'm thinking it's specifically https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended#L71 .

While I can't speak for all the dev's on the ModSecurity side, it'd like to note that this is the recommended conf, it is meant to be modified prior to usage given specific situations, and it's possible to make an exception for this quoted multipart request. I think the assumption is that no major browser does this which is why it's recommended. Not sure how much freedom MS gives you in removing or modifying rules here... but you could make a rule that fires only if MULTIPART_BOUNDARY_QUOTED is true for instance and skip rule 200003 in that case.

I'm gonna close this here but if you wanna drop more info on the ticket feel free to do so.

[nneul]

It's actually coming from an iOS mobile app running an app using react native. An upstream bug HAS been corrected there where it was adding the quotes due to another bug (inappropriately using slashes in the boundary). The question I have is - why is it it treated as a failure/warning/alert when the spec allows for the quotes in the boundary?

Unfortunately, MS only allows adjusting the 9xx rules, and it seems like it's being triggered before then. I'm working the case with them to try and resolve in addition to getting our app updated, but since this has impacted others, thought it should be raised here too.

[nneul]

Some related items:

facebook/react-native#7564

facebook/react-native#11342

https://github.com/vkholodkov/nginx-upload-module/issues/50

[nneul]

Sounds like the view is that it's more like a 'spamminess' setting given that it's uncommon, rather than a 'validity' check. I can accept that.

[csanders-git]

yeah this is exactly it, that is why it's put in the recc config. We have it listed as part of the 'strict' multipart processing, in all cases I know of browsers (desktop) won't generate such queries and therefore it is relatively safe to assume it as a default because it (is supposed to be) can be changed. Odd that MS doesn't give you control over the engine config settings :-X