Better checking of the file type when determining which files are SVGs #28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the Change
We currently have a function that is hooked into the
wp_handle_upload_prefilter
filter. In there we check if the file type isimage/svg+xml
and if so, we sanitize the file. If that sanitization process fails, we don't allow the file to be uploaded to WordPress.There's a potential issue here though because the file type we rely on comes from the
Content-Type
of the originalform-data
request. Typically this will be automatically set to whatever the real file type is but in theory, someone could spoof this request and setContent-Type
to be anything, likeimage/png
. In this case, they could send an actual SVG in theform-data
but set theContent-Type
to beimage/png
, which would then bypass our sanitization process (but would still be uploaded to WordPress).This PR fixes this by utilizing the core WordPress function
wp_check_filetype_and_ext
to get the file type, instead of relying on the value that comes from the request. This should still work in all legitimate cases and if someone were to try sending a proper SVG but they change theContent-Type
in the request, it will also catch that.I tested the following scenarios:
Content-Type
set. Our sanitization kicks in ✅Content-Type
set (set toimage/png
). Our sanitization kicks in ✅Content-Type
set. No sanitization needed from us ✅Content-Type
set. File rejected ✅Content-Type
set. File rejected ✅Content-Type
set. File rejected ✅Content-Type
set. File rejected ✅Alternate Designs
None
Possible Drawbacks
Slight impact on performance but should be minimal
Verification Process
Ensure that you can still properly upload SVGs in WordPress.
If desired, can also manually make a
curl
request to send an SVG with a manipulatedContent-Type
field, to verify that captures things correctly. I can provide an examplecurl
command if needed.Checklist:
Changelog Entry