[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