[wp-trac] [WordPress Trac] #60934: Internal Subnets are being blocked by wp_parse_url and why?
WordPress Trac
noreply at wordpress.org
Fri Apr 5 05:06:26 UTC 2024
#60934: Internal Subnets are being blocked by wp_parse_url and why?
-------------------------------------+------------------------------
Reporter: erenfro | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: HTTP API | Version: trunk
Severity: normal | Resolution:
Keywords: close reporter-feedback | Focuses:
-------------------------------------+------------------------------
Changes (by dd32):
* keywords: => close reporter-feedback
* severity: blocker => normal
Comment:
Hi @erenfro,
This functionality is part of `wp_safe_remote_request()` - to only fetch
"safe" remote destinations.
This is intended to [https://owasp.org/www-
community/attacks/Server_Side_Request_Forgery protect against SSRF
attacks], in which an application is 'tricked' to request non-public
resources and expose them publicly through the accessible endpoint. We
additionally protect against redirection attacks used to start a SSRF
attack.
Unlike suggested, this doesn't affect `wp_parse_url()` but rather
`wp_http_validate_url()` - which is only intended on being used to
validate that a URL can be requested "safely" by the HTTP API. A number of
plugins do use this function improperly though.
It's also common for plugins to run into this by feeling that the
resources they are requesting are "safe" but WordPress disagreeing, this
happens due to the inability of WordPress to know what is safe about a
non-public resource, plugins should use the non-safe request method for
that.
In short:
- To request potentially unsafe resources, `wp_remote_request()` /
`wp_remote_get()` can be used. Local non-public resources are allowed to
be requested.
- To request only-safe resources, `wp_safe_remote_request()` /
`wp_safe_remote_get()` can be used. Local non-public resources will be
blocked.
If you could expand on your use-case and the issue encountered, there
might be more to it, but from the description provided and the above
explanation, I believe this ticket can be closed as `invalid`.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/60934#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list