Use of wp_http_validate_url may be misused incorrectly.

[erenfro]

I discovered this issue in regards to the use of the function check_url, because when trying to add a "friend" that was linked to my own Friendica and later Mastodon website, run on the very same cluster of servers running my Wordpress site, that no traffic ever left Wordpress or my webserver specifically while resolving the mastodon's domain name to a local internal subnet IP. When changing this to an external internet address IP, however, things magically worked.

https://github.com/akirk/friends/blob/b04e45659bff29e2f99756ee09a45d5e12ab5e41/includes/class-friends.php#L1218

This call here, is intended for very specific use-cases, and I fear this may be one of the specific use cases this may or may not be legitimately useful for, as it's expecting a very specific protocol and only such.

Per a case I opened about this at Wordpress I feel this may be a case where this is probably hindering more than it should be.

[akirk]

As a plugin developer, I am caught in the middle. The exact thing that you're pointing out to me has been reported as a security issue to me where someone argued that it should not be possible to access an internal ip address (I understand this might have been you after all?).

The solution that I personally use for developing is to use a snippet like this:

add_filter(
    'http_request_host_is_external',
    function( $in, $host ) {
        if ( $host == 'internal.domain' ) {
                return true;
        }
        return $in;
    },
    10,
    2
);

Or there are two filters in the function that can be used:

• friends_pre_check_url
• friends_host_is_valid

[erenfro]

As a plugin developer, I am caught in the middle. The exact thing that you're pointing out to me has been reported as a security issue to me where someone argued that it should not be possible to access an internal ip address (I understand this might have been you after all?).

Just requesting resources, I'm not sure would constitute a security concern, on it's own. The intention is specifically intended to block SSRF attacks, specifically. This speaks a specific protocol and expects a specific protocol, does it not?

The solution that I personally use for developing is to use a snippet like this:

add_filter(
  'http_request_host_is_external',
  function( $in, $host ) {
      if ( $host == 'internal.domain' ) {
              return true;
      }
      return $in;
  },
  10,
  2
);

This is pretty much essentially what I came up with as well, in the form of a very basic plugin, in order to get it to function, but then you literally have to match each and every internal.domain one by one or as a compared list since you can define a function for it and all. A lot of people have no idea about this, and end up either not getting it to work... Getting it to work by bouncing off edge routing looping back in (This method is actually technically worse), or doing very dangerous things like hacking their themes function.php (which actually did not work for me), or making a plugin like I ultimately found out.

IMHO, it seems counter-intuitive, or at the very least, could be done a little bit differently. Possibly even an option within the plugin to literally provide a built-in whitelist that handles this add_filter as appropriate, within itself. As a compromise.

[akirk]

I am very much open to improving the situation!

IMHO, it seems counter-intuitive, or at the very least, could be done a little bit differently. Possibly even an option within the plugin to literally provide a built-in whitelist that handles this add_filter as appropriate, within itself. As a compromise.

What could that built-in whitelist look like?