XMLRPC is great for remote publishing to WordPress, but there has been many security issues attributed to it. How do it make it more secure? More specifically, only user from the intranet will be publishing through XMLRPC. WP is currently running on Lighttpd and php5.3.
1
-
Which issue do you know about? And which one do you want to fix?– fuxia ♦Feb 1, 2012 at 8:30
Add a comment
|
4 Answers
XMLRPC is as secure as the rest of WordPress. All of the requests need to be authenticated with username and password credentials that exist on your site already. That means, if someone has a login for your site, they can use the XMLRPC interface (if it's turned on). But anonymous users can't get in.
The only potential security vulnerability you might face with XMLRPC is that of a man in the middle attack. But you face this same risk with the regular WordPress admin, so it's not unique to XMLRPC.
The best way to prevent this kind of an issue is to enable SSL security on your site. You'll need an SSL certificate, and then you need to access you XMLRPC endpoint via https:// rather than http://. This will encrypt your requests and prevent anyone from intercepting them and stealing your credentials.
You should also enable SSL security on login for your regular site because it, too, faces the same risks.
-
3Also I would like to add that another security measure you can take is putting in code to stop brute forcing of your passwords. This is the same from XMLRPC and the normal logins. Many plugins out there can put in anti brute force measures in place. Login Lock and Login LockDown are just a couple.– ScottFeb 1, 2012 at 17:04
-
You can have Jetpack installed with "protect" on and have login brute force plugins and still get an xmlrpc.php DoS attack. Just because someone has done a lot of security work on their WordPress blog, they should also specifically protect their xmlrpc.php– sdexpOct 16, 2016 at 19:28
-
"The only potential security vulnerability you might face with XMLRPC is that of a man in the middle attack." That is not true if I read some more about this online. nitesculucian.github.io/2019/07/01/…– PieterJul 28, 2020 at 7:35
I suggest the following code to append to the .htaccess file
<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
# IP address Whitelist
Allow from xxx.xxx.xxx.xxx
Deny from all
</FilesMatch>
To limit access to xmlrpc.php to only the IP range that needs it (e.g. Jetpack) you can do something like this.
<files xmlrpc.php="">
Order Deny,Allow
Deny from all
Allow from 192.0.64.0/18
Satisfy All
ErrorDocument 403 http://127.0.0.1/
</files>
Securing xmlrpc.php seems generally under-discussed on the web but an attack can mean a DoS attack. Definitely worth discussing to make sure more people can prevent an attack, in my opinion.
-
this answer already exists.... but really blocking IPs at server level is just stupid. When you do it now on your VPS everything is great and in a month when you move to cloudflare everything breaks without notice. Oct 16, 2016 at 19:30
-
1You can have lots of security plugins installed (iThemes, WordFence, Jetpack) but unless you are specifically protecting your xmlrpc.php you can get a DoS attack. You're saying all WordPress blogs should have SSL enabled?– sdexpOct 16, 2016 at 19:40
-
my comment is related to filtering by IP on the server level. 1. rarely sites are breached by brute force so this is the least important thing to do 2.which makes the ease of admin of the solution more important and server site configuration is not easy to make or change and hard to discover in terms of UX.As for DOS.... if this what makes your site crash then you need hardware upgrade in any case as obviously the script kiddies do not intend to bring down the site. And no, I am the last person on earth that will say that SSL is a must. Oct 17, 2016 at 3:50
The plugin Secure XML-RPC seems to address the issue of sending sensitive info over the wire.
Plugin description:
Rather than sending usernames and passwords in plain text with every request, we're going to use a set of public/secret keys to hash data and authenticate instead.
