Proposed changes

Hello,

It can happen - rarely - and usually on custom-built applications, that this rule is triggered because of an unlikely boundary.

For example, this one:

curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:4" "http://sandbox.coreruleset.org/" -H 'Content-type:multipart/form-data; boundary=3cmYTdyNT2jZxYyV7T_pL4irNeChj-CSS'
921422 PL2 Content-Type header: Dangerous content type outside the mime type declaration

RFC 2046, section 5.1.1 https://www.rfc-editor.org/rfc/rfc2046.html, appears to define the allowed content for the boundary value, but I disagree with opening things up that much, since I have never observed anything outside the scope [\w\-]+. I therefore propose to stick with the [\w\-]+ scope for the chained rule handling these rare false positives, rather than adopting what RFC 2046 allows: ^[\w\-'()+_,./:=?]{1,69}$.

This will probably make the rule sensitive to multiple Content-Type declarations on unlikely frontends that do not comply with RFC 7230 section 3.2.2, but rule 920620 is supposed to address this need.

What do you think?

PR Checklist

• I have read the CONTRIBUTING doc
• I have added positive tests proving my fix/feature works as intended.
• I have added negative tests that prove my fix/feature considers common cases that might end in false positives
• In case you changed a regular expression, you are not adding a ReDOS for pcre. You can check this using regexploit
• My test use the comment field to write the expected behavior
• I have added documentation for the rule or change (when appropriate)

Further comments

For the reviewer

• Positive and negative tests were added
• Tests cover the intended fix/feature properly
• No usage of dangerous constructs like ctl:requestBodyAccess=Off were used in the rule
• In case a regular expression was changed, there is no ReDOS
• Documentation is clear for the rule/change