alhudz opened a new pull request, #479:
URL: https://github.com/apache/commons-fileupload/pull/479
When `ParameterParser.parse` decodes an RFC 2231 / RFC 5987 extended value
(such as `filename*`) and the decode throws `IllegalArgumentException`, it set
the value to `null` and then unconditionally stored it. Because `filename` and
`filename*` both strip to the key `filename`, a malformed `filename*` clobbers
a valid `filename` for the same part. Repro: `parse("form-data; name=\"file\";
filename=\"safe.txt\"; filename*=UTF-8'bad%2", new char[]{',',';'})`. Expected:
`filename` stays `safe.txt`. Actual: `filename` is `null`, so `getFileName`
returns an empty name. A client controlling the multipart `Content-Disposition`
header can therefore blank the filename of an uploaded file and slip past
filename-based checks in callers.
The existing comment already states the intent (`Treat invalid values as if
they were not provided`), but setting `paramValue = null` and putting it does
the opposite for a parameter that also has a valid sibling value. The fix flags
the invalid decode and skips storing that parameter, so an invalid extended
value is genuinely ignored and cannot overwrite a valid one, regardless of
ordering. Keeping this in `parse` means every caller (`getFileName`,
`getFieldName`, `getBoundary`, charset lookup) gets the corrected behaviour
without its own guard. Covered by a new `ParameterParserTest` case; the core
suite passes (73 tests).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
