dxbjavid commented on PR #3572:
URL: https://github.com/apache/cxf/pull/3572#issuecomment-6143647759
good points, all taken. i've reworked it the way you suggested rather than
touching the parser.
the parser change is reverted, so toString(), getParameter() and the
outbound/client paths behave exactly as before. instead there's a new sibling
helper FileUtils.safeFileName that builds on stripPath and then rejects the
values that stripping alone leaves dangerous: "." and "..", an empty result (so
a trailing separator like "reports/" no longer resolves back to the upload
dir), a NUL, and a ':' for the C:evil.exe drive-relative case. it returns null
for those, which the callers already treat as "no usable filename".
that helper is now applied where inbound attachments are actually consumed:
AttachmentUtil.createAttachment (which reuses the existing helper rather than
the duplicated private copy) and the two jax-rs spots that read
cd.getFilename(), EntityPartProvider.fromAttachment and EntityPartUtils. the
filename* and &#NNNN; cases are covered there too since both decode before
getFilename() is read. one thing to flag honestly: keeping the parser untouched
means getParameter("filename*")/getParameters() still return the decoded value,
so an integrator re-parsing the raw header themselves is on their own, but the
normal consumers no longer are.
tests added for "..", a trailing separator, the filename* key, NUL and the
../x form, plus unit tests on safeFileName itself.
--
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]
