[wp-trac] [WordPress Trac] #30377: wp_check_filetype is broken when checking urls with parameters
WordPress Trac
noreply at wordpress.org
Wed Mar 9 07:52:07 UTC 2022
#30377: wp_check_filetype is broken when checking urls with parameters
-------------------------------------------------+-------------------------
Reporter: supercleanse | Owner: audrasjb
Type: enhancement | Status: reopened
Priority: normal | Milestone: 6.0
Component: Media | Version: 4.0
Severity: normal | Resolution:
Keywords: has-unit-tests needs-dev-note | Focuses:
needs-patch |
-------------------------------------------------+-------------------------
Comment (by dd32):
Replying to [comment:62 Ruxton]:
> With the knowledge of what dd32 just mentioned, it seems the viable
solution outside of moving strip_fragment_from_url out of canonical (which
is excessive) is to strip the fragment and beyond with strpos, etc. as the
query string was.
Using string functions to remove parts of a URL (both `?...` and `#...`)
is a potential security issue here (and why it would've been reverted
prevously), as it's possible to cause it to strip more than anticipated
and result in operating on the incorrect filename. You should really use
`wp_parse_url()` instead too (It's kind of like parsing HTML with Regex,
possible, but should be avoided).
Additionally, since the parameter can be a Filename, Path, or URL, you
need to restrict any URL handling to URLs only, not filenames.
If a filename on disk ''looks like'' a url (You can have a filename on
Linux that IS a url), you can't treat it as a URL either. If the filename
came from an untrusted location, you can't treat it as a URL unless it's
known to be intentionally a URL.
Pulling out two comments from above:
- [comment:19 Comment by me]: I'd personally prefer to add an explicit
`wp_check_url_filetype()` function instead, one which extracts the actual
filename from the URL and passes it along to `wp_check_filetype()` (if
appropriate, or duplicates parts of it)
- [comment:27 Comment by Helen]: Changing to enhancement, as
`wp_check_filetype()` was never meant for URLs and the solution in this
case is to introduce something else that does work for URLs.
Even if the existing function is being passed URLs, it's not intentionally
supposed to be used for URLs, and performing processing like this is
doomed for failure.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/30377#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list