[wp-trac] [WordPress Trac] #24646: fetch_feed() returns WP_Error with "A valid URL was not provided"

[WordPress Trac]

#24646: fetch_feed() returns WP_Error with "A valid URL was not provided"
--------------------------+--------------------
 Reporter:  husdaman      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5.3
Component:  Feeds         |     Version:  3.5.2
 Severity:  major         |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by nacin):

 Replying to [comment:26 joehoyle]:
 > I recently ran into this (well, @matthue did!) with local development.
 When local site "A" wants to send a request to local site "B", it will be
 rejected, as that resolves to 127.0.0.1 via the hosts file. I think this
 is the pattern a lot of developers use with vhosts etc, so might be worth
 consideration if this goes into the next release from trunk.

 The specific change from 3.5.2 to 3.6 has to do with [24482].
 Specifically, the HTTP API will by default reject all URLs it thinks is
 unsafe, for all requests, not just the ones that explicitly pass an
 argument as in [24480]. We're not sold on [24482] for 3.6, and rather
 wanted to "test flight" it to see what kind of bug reports we would get.
 So thank you for helping!

 I think we can safely allow traffic to 127.0.0.1 as long as the existing
 site's domain also resolves to 127.0.0.1, and the port is standard (80,
 443, or 8080, or if the port matches the site's port (which would work for
 :8888 to :8888). We could also directly whitelist 8888 which is MAMP's
 default).

 Unfortunately WP_DEBUG is not a great indicator of "production" versus
 "development", so we couldn't just allow unsafe URLs for WP_DEBUG only.

 > Another setup I run on a prod box is 2 sites on the same machine, where
 they have "127.0.0.1 example.com" in the hosts file, which I believe again
 would mean wp_http_validate_url would brake communication between the two
 sites.

 Yes — this definitely has the potential to break that setup as well, which
 has been reported here. I am still not sure how to address this.

 Without going into an incredible amount of detail, we're trying to prevent
 server-side request forgery attacks. (Imagine me tricking your local
 server trying to attack your router.) So locally-resolved requests are, in
 general, untrusted. So we need to figure out how to make some of them
 "work" without opening ourselves up to a vulnerability.

 Even if we change the default (as in, reverting [24482], which is very
 likely at this time), we'll still need to allow locally-resolved requests
 to work in certain cases. It appears there are two cases: When a server
 directly resolves to itself or a nearby server in production via
 /etc/hosts; and a similar development setup where domains are set to
 127.0.0.1.

 I'm happy to discuss in deeper detail in private — nacin or security -at-
 wordpress.org — especially if anyone has some interesting ideas.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24646#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software