fix: Handle "filename*" field in MP header #3239
Conversation
| p++; | ||
| } | ||
| if (*p != '\'') { | ||
| return -17; // Single quote for end-of-language not found |
There was a problem hiding this comment.
Shouldn't you use something like this here, as below?
msr->mpd->flag_invalid_quoting = 1;
There was a problem hiding this comment.
It's a good idea - thanks.
@fzipi, @marcstern - what do you think about this guys?
I already added this in 2b22261, but I can remove that.
If we keep this feature, we should add that to v3 too.
|
https://www.rfc-editor.org/rfc/rfc5987#section-3.2
We're restricting for years the languages to these two and never found a false positive. |
| return -16; // Must be at least one legit char before ' for start of language | ||
| } | ||
| p++; | ||
| while ((*p != '\0') && (*p != '\'')) { |
There was a problem hiding this comment.
Languages can only contain alphanum & '-'
while (isalnum(*p) || *p == '-') p++;
There was a problem hiding this comment.
You're right, and here - as you suggested - we can control this.
The question is: is it allowed to send the request without charset? I mean:
Content-Disposition: form-data; name="post"; filename*=resume.pdf
I can't find any relevant information about that.
There was a problem hiding this comment.
https://www.rfc-editor.org/rfc/rfc7578#section-4.2 also says:
Some commonly deployed systems use multipart/form-data with file
names directly encoded including octets outside the US-ASCII range.
The encoding used for the file names is typically UTF-8, although
HTML forms will use the charset associated with the form.
Which sounds to me that any charset is valid, regardless of what the other RFC says.
charset is required, AFAICT, only language is optional.
There was a problem hiding this comment.
So, do you think we do not need to check the charset and we should allow anything? Or restrict the charset content only to alnum chars (+ -)?
There was a problem hiding this comment.
IMO, the charset should be restricted to the ABNF from the RFC.
|
Well, you are right, but as it stands in RFC: "Extension character sets (mime-charset) are reserved for future use." - if someone introduce a new feature in the future we should align the code again. Introducing a new settings would be confused (in this case). And I think first we should investigate is it possible to check those languages with rules. |
what
Add handling of Multipart Header's "filename*" (asterisk at the end!) field.
why
mod_security2 (v2) does not handle MULTIPART header's "filename*" field, eg:
where the filename is UTF8 encoded string with value "résumé.pdf".
references
RFC 7578
additional notes
v3 handles as well this header, I almost copied that part of code.
Thanks @fzipi for bringing it to our attention.