Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 7 years ago

#21509 closed enhancement (fixed)

Enable XML-RPC by default and remove the option

Reported by: nacin's profile nacin Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: major Version:
Component: XML-RPC Keywords:
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 12 years ago.
Removing the option enable_xmlrpc

Download all attachments as: .zip

Change History (25)

#1 @nacin
12 years ago

  • Description modified (diff)

#2 @redsweater
12 years 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 12 years ago by redsweater (previous) (diff)

#3 @Mamaduka
12 years ago

  • Cc georgemamadashvili@… added

@markoheijnen
12 years ago

Removing the option enable_xmlrpc

#4 @markoheijnen
12 years 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.

#5 follow-up: @blobaugh
12 years 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.

#6 @ryan
12 years ago

Introduced in #7157

#7 in reply to: ↑ 5 @markoheijnen
12 years 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.

#8 @nacin
12 years 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.

#9 @nacin
12 years 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.

#10 @nacin
12 years 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.

#11 @nacin
12 years ago

In [21819]:

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

#12 @nacin
12 years ago

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

#13 @samuelaguilera
11 years 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?? ;)

#14 @dd32
11 years 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.

#15 follow-up: @digip
11 years 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 11 years ago by digip (previous) (diff)

#16 in reply to: ↑ 15 @F J Kaiser
11 years 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();

;)

#17 @iandunn
11 years ago

  • Cc ian_dunn@… added

#18 follow-up: @andrebron
9 years ago

  • Keywords 2nd-opinion added; has-patch removed
  • Severity changed from normal to major
  • Type changed from enhancement to feature request
  • Version set to 4.0

Hi all. More recently there have been concerns about how xml-rpc.php is widely being abused for DDOS (also for brute force attacks, but really gonna focus on the DDOS). A perfectly secured wordpress site with xml-rpc.php enabled can be easily abused to participate in DDOS attacks.

http://www.computerweekly.com/news/2240215998/More-the-162000-WordPress-sites-used-in-DDoS-attack

Enabling xml-rpc by default has drastically affected the volume of DDOS abuses through the wp xml-rpc . I understand it is relatively widely used, however, most wp sites (I believe) do not use pingbacks or wp mobile app for the most part. I believe it should be reverted back to disabled by default and have plugins and remote services that rely on this to enable it either automagically upon install or in their installation instructions.

I personally found 1 site I manage that has been abused through xml-rpc.php. Not sure how many are being abused but I can imagine this increasing since xmp-rpc was enabled by default.

http://labs.sucuri.net/?is-my-wordpress-ddosing

While removing this file or blocking it at the server level (or disabling it in php code) works, so many users (likely most) install wp core and do not specifically use xml-rpc.php pingback or features for wp mobile or other. Besides 4.0 is mobile responsive ;)

I suggest again disabling xml-rpc.php by default. While it is not as severe as open DNS resolvers being abused for DDOS amplification attacks, it is still quite a problem that seems has not been given enough attention lately since xml-rpc was set to enabled by default.

Last edited 9 years ago by andrebron (previous) (diff)

#19 in reply to: ↑ 18 ; follow-up: @maxcutler
9 years ago

Replying to andrebron:

Hi all. More recently there have been concerns about how xml-rpc.php is widely abused for DDOS (also for brute force attacks, but really gonna focus of the DDOS). A perfectly secured wordpress site with xml-rpc.php enabled can be easily abused to participate in DDOS attacks.

Pingbacks, despite living in the XML-RPC API, have never respected the enabled/disabled option for XML-RPC in the admin.

That option only applies to XML-RPC methods that check user credentials, but pingbacks/trackbacks are anonymous and thus do not fall under that check.

There are opportunities for the community to write plugins or better documentation on how to block ping/trackback requests either at the PHP level (e.g., by hooking the xmlrpc_call action and dieing for these methods) or the web server/proxy level (e.g., nginx or Varnish). But just disabling XML-RPC by default will not help with the DDOS issues.

Last edited 9 years ago by maxcutler (previous) (diff)

#20 in reply to: ↑ 19 ; follow-up: @andrebron
9 years ago

Thank you for clarifying. The concern isn't specifically DDOS directed to WordPress sites, but to any site through the WordPress XML-RPC pingback abuse via spoofing the domain of the target of the DDOS. (reflective DDOS). This type of attack effectively targets the spoofed domain, and then in the process can DOS the wordpress sites participating in the DDOS.

Perhaps I would start working on a patch to make checks in WordPress Core on whether pingbacks and XML-rpc is being used by plugins, themes or remote applications. Perhaps rather making a better way to filter legitimate connections to XML-rpc vs. abusive connections using WordPress sites to DDOS others.

Last edited 9 years ago by andrebron (previous) (diff)

#21 in reply to: ↑ 20 @redsweater
9 years ago

Replying to andrebron:

There are opportunities for the community to write plugins or better documentation on how to block ping/trackback requests either at the PHP level (e.g., by hooking the xmlrpc_call action and dieing for these methods) or the web server/proxy level (e.g., nginx or Varnish). But just disabling XML-RPC by default will not help with the DDOS issues.

Another thought it entirely removing xml-rpc.php from core and only have it installed when required. Not sure how to implement that but it's worth considering since wp DDOS exploitability and reputation is somewhat on the line.

Do you have any recent information to cite with respect to XML-RPC posing a significant security risk? The article you cited is from March, and since then the WordPress team has responded by hardening WordPress's XML processing.

Because many people, among them the WordPress team's own iOS and Android app teams, depend upon the XML-RPC API being enabled by default, you're asking a lot to revive interest in disabling it. It will help a lot if you bring a compelling, up-to-date argument for how it's posing a significant risk to WordPress sites.

#23 @DrewAPicture
8 years ago

In 37025:

Docs: Clarify documentation for the xmlrpc_enabled filter to better explain that its scope only extends to methods requiring authentication.

When the xmlrpc_enabled filter was initially introduced in [21509], it was effectively intended to replace the `enable_xmlrpc' UI option, which only controlled whether authenticated XML-RPC methods were enabled, such as for publishing actions. This change clarifies the expected behavior and adds information about ways to more granularly control XML-RPC method and request behavior with related hooks.

Part props mensmaximus.
See #21509. Fixes #36055.

#24 @SergeyBiryukov
7 years ago

  • Keywords 2nd-opinion removed
  • Type changed from feature request to enhancement
  • Version 4.0 deleted
Note: See TracTickets for help on using tickets.