WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 19 months ago

Last modified 15 months ago

#21509 closed enhancement (fixed)

Enable XML-RPC by default and remove the option

Reported by: nacin Owned by: nacin
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords: has-patch
Focuses: Cc:

Description (last modified by nacin)

Quite a bit has changed since we introduced off-by-default for XML-RPC. Their code has improved, and it is no longer considered a second-class citizen when it comes to API development, thanks to the work of a large team of awesome contributors. Security is no greater a concern than the rest of core.

There is no longer a compelling reason to disable this by default. It's time we should remove the option entirely.

Attachments (1)

21509.patch (4.5 KB) - added by markoheijnen 20 months ago.
Removing the option enable_xmlrpc

Download all attachments as: .zip

Change History (18)

comment:1 nacin21 months ago

  • Description modified (diff)

comment:2 redsweater20 months ago

*applause*

It might be worth considering removing the off-by-default choice for AtomPub too, assuming anybody can attest to its security.

Last edited 20 months ago by redsweater (previous) (diff)

comment:3 Mamaduka20 months ago

  • Cc georgemamadashvili@… added

markoheijnen20 months ago

Removing the option enable_xmlrpc

comment:4 markoheijnen20 months ago

  • Keywords has-patch added

Added a patch that removes the option enable_xmlrpc everywhere and removes the option from the database.

I'm not sure if removing the option is the best way. Maybe setting it to 1 on upgrade maybe fits better.

comment:5 follow-up: blobaugh20 months ago

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

comment:6 ryan20 months ago

Introduced in #7157

comment:7 in reply to: ↑ 5 markoheijnen20 months ago

Replying to blobaugh:

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

I can see what you mean but I disagree the reasoning. There aren't a lot of plugins adding XML-RPC stuff but the do for other things and plugins are a big cause of security issues. Also if you really want to disable it then just remove the xmlrpc.php file because plugins can add methods that are always accessible even when you put xml-rpc off in your settings.

comment:8 nacin20 months ago

Per an IRC discussion a few weeks ago, we won't be removing the ability to turn off XML-RPC via a filter. Just the UI and DB option.

comment:9 nacin19 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [21804]:

Turn XML-RPC on and remove the option on the Writing Settings page.
props markoheijnen for the initial patch.

Introduces a new filter, xmlrpc_enabled.

Respects any current callbacks registered to the pre_option_enable_xmlrpc
and option_enable_xmlrpc filters, for anyone forcing it off via code.

fixes #21509.

comment:10 nacin19 months ago

In [21818]:

Remove AtomPub from core.

DB version is bumped to generate the new wp-app rewrite rule and remove the old enable_app option.

props wonderboymusic.
fixes #21509.

comment:11 nacin19 months ago

In [21819]:

Remove accidental cruft in [21804] caused by renaming variables. see #21509.

comment:12 nacin19 months ago

[21818] and [21819] belonged on #21866.

comment:13 samuelaguilera19 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

In my honest opinion, it's very dissapointed to see XML-RPC forced on and no way for admin of the site to turn it off from settings (hey! let admins make some decisions in their sites ;)).

It's not only a matter of security to closing some doors that you don't need to use, it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

Anyway, having a filter to turn it off is fine for me. But the fact is that using the new xmlrpc_enabled only stops from making login, but the XML-RPC server is still running (and responding), and even if you made login previously in the site through XML-RPC and you're still logged in, you can access even if you hook to the filter to turn it off :(

Removing the xmlrpc.php file form installation maybe is a solution, but not a professional one. For example doing that can create a lot of 404 error messages and therefore make Apache access.log grow with no valid reason.

Please, don't leave it this way. What about put the new filter in some other place to make XML-RPC server totally off?? ;)

comment:14 dd3219 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

For what it's worth, Having XML-RPC enabled or disabled does not increase, nor decrease used system resources on a standard site. It's not a seperate "server", and the load it places on the web server be it enabled, or disabled does not vary. The only way that it can increase system resources if someone is actually using it (by that, I mean logging in with a correct user/password AND posting articles OR uploading media) - and in all cases, it should require less system resources than visiting your blog dashboard.

furthermore, XML-RPC was always "enabled" it simply disallowed logins when it was "disabled", It was still used for Pingbacks and trackbacks, as well as by many plugins for inter-server communication. The changes here are not a significant change in the way it works.

Please open a new ticket if you'd like to discuss removing the feature entirely from core, but know in advance, that's not happening. Your best bet would be to block XML-RPC access through .htaccess directly and watch random plugins break.

comment:15 follow-up: digip16 months ago

  • Cc digip added

Just wanted to let people know, if you want the function disabled, and not just from logging in, but fully disabled, you can filter the class itself. The reason being, someone has already come out with an exploit for this, that turns WordPress xmlrpc.php into a port scanner. My fix was to create a plug-in that uses a similar filter to the one above, but instead of:

add_filter( 'xmlrpc_enabled', '__return_false' );

I changed it to:

add_filter( 'wp_xmlrpc_server_class', '__return_false' );

You can download the plug-in from my site, or you can just add that line of code, to your current themes functions.php file. If the theme updates automatically though, and replaces the file, you will have to add it back every time. This is why I created a stand alone plug-in to address this issue, since it can not only be used to port scan the local server, it can also be used to send false pingback spam to other sites.

You can read more here: http://www.attack-scanner.com/security/wordpress-3-5-xml-rpc-enabled-by-default-vulnerabilities/

Last edited 16 months ago by digip (previous) (diff)

comment:16 in reply to: ↑ 15 F J Kaiser15 months ago

Replying to digip:

I changed it to:

add_filter( 'wp_xmlrpc_server_class', '__return_false' );

Just because I stumbled upon it and read what you're suggesting to later readers: This is not a good idea. When you look at ~/xmlrpc.php, then you'll see, what WP calls immediately after allowing to filter the class. Guess what happens when you call

false->serve_request();

;)

comment:17 iandunn15 months ago

  • Cc ian_dunn@… added
Note: See TracTickets for help on using tickets.