WordPress To Disable Remote Access
June 24th, 2008The WordPress developers have decided that, starting with WordPress 2.6, access to the XMLRPC and AtomPub-based remote publishing interfaces will be disabled by default. Users who wish to use a remote client such as MarsEdit will have to go out of their way to enable the required functionality in their blog’s settings.
There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.
But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.
First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.
Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.
WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.
Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!
A Real Solution
If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.
In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.
If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.
Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.
If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.
If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.
June 24th, 2008 at 3:04 pm
Thanks for letting us know about this. Looks like I’ll either not be upgrading to 2.6, or will simply jump ship to Habari.
June 24th, 2008 at 3:07 pm
Ben: It’s worth noting that the disabling is only a default setting. I don’t imagine that anybody savvy will have trouble re-enabling the functionality. But I do still think it will be an annoying roadblock for many users.
June 24th, 2008 at 3:20 pm
I would point out that vastly more bank robberies take place via the teller window than the drive-up windows so the tellers typically need more security (which is why there are usually guards on the inside but not at the drive up windows.)
Your solution makes way more sense than simply shutting the service down by default. Are those that turn it back on not deserving of a secure interface?
June 24th, 2008 at 3:23 pm
If the ever dreamed of disabling the API (which I don’t think is very likely), I’d switch to Mephisto or any other Ruby or Python powered framework, leaving the nigtmares of PHP development behind.
Cheers,
Davide
June 24th, 2008 at 3:43 pm
It’s also worth noting that Flickr requires you to explicitly authorize every external app using its API.
June 24th, 2008 at 3:45 pm
I think if they did something like flickr and set up authorized systems with a feedback look or certificates, it would provide real security.
June 24th, 2008 at 3:46 pm
I’m moving closer and closer to abandoning the WP platform. There’s a pattern manifesting that points to very big issues in understanding security and authentication. (On the authentication side, let’s just mention that OpenID is *still* unsupported)
Of course, the issue of PHP doesn’t help increase my confidence level either – I do think that WP is slowly leaving the valid size range of PHP apps.
Ah well. Off we go, investigating blogging solutions.
June 24th, 2008 at 3:47 pm
Hm. Question Daniel,
Do you know of other blog platforms that may be any closer to realizing this single API approach? Obviously, none are perfect – but the closer and more open to the idea, the better I think!
June 24th, 2008 at 3:59 pm
Isn’t good security procedure in general for any software to disable any kind of network service unless explcitly requested by the user?
This actually improves security for users who don’t need the functionality, since any future exploit won’t effect them. That doesn’t mean WP is giving up trying to secure remote services. It’s trying to hedge against future exploits, of which there will always be possibility, no matter what.
June 24th, 2008 at 4:20 pm
I have to say I agree with the WP devs on this one. Disabling an interface by default only makes sense from a security standpoint. Every major OS now ships with ports disabled by default, not because having open ports is inherently insecure (it isn’t), but because it only makes sense to limit the avenues of attack. And by defaulting to “off”, it means that even those who turn it on due to necessity are safer overall, because that avenue of attack is less attractive due to the smaller number of hosts vulnerable.
Which is not to say there shouldn’t be some other security system set up, like an SSH keypair, or authenticated authorization for a specific client to be allowed editing access or something like that. If an overhaul of the editing system needs to be done so that there is a single point of security between web/offline/etc, that’s great too. But don’t let the perfect be the enemy of the good. Just because the devs haven’t had time to reengineer the entire blogging engine doesn’t mean they should avoid a simple preference change that will increase security in the meantime.
I hate to say, but this entire post reeks of shortsighted FUD. This is the same kind of logic that prevented seat belts from being installed in cars for decades — the manufacturers didn’t want people to think cars were dangerous, so they left the seatbelts out even though they knew they would save lives. Turning off an interface doesn’t mean that interface is insecure, it means ALL interfaces are insecure, and you should only enable the ones that are necessary — the only computer safe from attack is the one that’s unplugged and locked in an underground vault.
Anybody with enough technical skill and know how to even operate an offline editor is perfectly capable of enabling the XML RPC connection in their blogging engine preferences.
June 24th, 2008 at 4:34 pm
I really disagree with the idea that this is just a shortsighted argument.
The fact of the matter is that for APIs to be used, at all, they need to be secure. Keeping them secure should be one of the top priorities, even above usability in my opinion. If WP is unable to do that, the API should be removed entirely – not just disabled by default.
What I pull out of Daniel’s post isn’t so much that WP is making a mistake by being more security aware about the API and possibly adding a bit of a hassle for end-users… it’s more the part about using a single doorway to gain access. The bits about Flickr APIs and using a better system instead of dealing with the current methodology, that’s what I found intriguing.
Overall, I think that the internet now – blogging specifically – is moving towards the idea of just making it easier. More people are getting involved, they just want to get their ideas out there. Making them worry about this setting or that to get their preferred client to work (Considering that clients are meant to enhance the experience, and probably make it simpler for them in some ways.) just puts another obstacle in their way. I just hope that all the 1-click installers out there for simple hosting companies think ahead and change this particular setting away from the ‘default’.
@yakko: Your point about security guards is valid, but I’d point out that personally, I wish I never had to go to the bank. If I were able to do everything I needed to at an ATM, or over the phone, or online – via some secure means – I’d rather do that.
@Nathaniel: If the devs are seriously concerned enough to rewrite the entire editing system to address the issue of API security – I’d beg the question, Why has it waited so long? Turning off a feature and allowing it to be turned on doesn’t remove a security vulnerability. It may simplify security in many cases, but it doesn’t remove the problem.
June 24th, 2008 at 4:40 pm
I have to agree with the WP developers and those that support the move as well. There’s absolutely no reason to have this enabled by default even if it is secure. If there IS a security flaw found then a lot less people will have their blog destroyed if this is turned off.
June 24th, 2008 at 4:52 pm
@Mr. Nosuch and others: Don’t conflate ports with services. It’s not “fewer ports open” that makes things more secure. It’s actually “fewer services running”. If you have WP running — and that’s a given in this scenario — it doesn’t matter if it offers its services only to port 80 or to any port in the range 10000-11000.
The benefit you get from closing down a network service is from removing all points of access, not closing one and leaving an equivalent open. If you normally have 2 doors to your house protected by identical locks, and you decide to brick up 1 of the doors, your house is not measurably more secure. It’s just less flexible.
What Daniel’s saying is that it’d be a better practice for WP to make both doors open onto the same foyer, and go through a single access control mechanism within.
June 24th, 2008 at 4:53 pm
Well, crap.
I’ll always love Mars Edit, and I’m willing to “go out of [my] way to enable the required functionality in [my] blog”™s settings.
Actually, now that I think about it, WP is missing the boat on something here. There are a million places I can put my content. Whoever makes it easiest and plays nicest with the tools I favor gets my attention, not the other way around. If WordPress makes it easy for me to post content by allowing me to use the tools I already own, then great. Otherwise, I know that other blog services make it dead simple to import WP content into a new blog site.
June 24th, 2008 at 4:59 pm
If 90% of WP blogs don’t have remote-publishing enabled… then it way less productive for hackers to focus assaults on that vector. It increases security.
If you are arguing for better remote-publishing features or security then make THAT argument.
June 24th, 2008 at 5:12 pm
“If 90% of WP blogs don”™t have remote-publishing enabled… then it way less productive for hackers to focus assaults on that vector. It increases security.”
You could make the equivalent argument that disabling the remote API will free up all the crackers that might have targeted it to target the HTML editing interface.
See Drew’s letter above. AFAICS This does not increase security, it just reduces the number of multiple instances of the same security opening.
June 24th, 2008 at 5:14 pm
@Drew Thaler
It’s a bit weird for you to say:
@Mr. Nosuch and others: Don”™t conflate ports with services. It”™s not “fewer ports open” that makes things more secure. It”™s actually “fewer services running”.
when what Mr. Nosuch actually said was:
“Isn”™t good security procedure in general for any software to disable any kind of network service unless explcitly requested by the user?”
Quotes are for quoting. Not for making up stuff you wished someone had said.
June 24th, 2008 at 5:21 pm
This is the same principle as with a firewall. Shutter the doors and windows that you aren’t using. I agree that it’s not a fundamental security improvement for XML-RPC/APP, it’s just an easy way to cut in half the exposure of the many blogs whose authors don’t use these protocols. If anyone characterizes this as “improving XML-RPC/APP security” they’d be wrong, and we’re not going to treat XML-RPC/APP security any differently just because many people will have it disabled.
June 24th, 2008 at 5:53 pm
I agree with you. But I guess that “disabling” the remote access is the first step on the way to drop it completely.
I hope that WP 3.0 will have a much better API, but I’m pessimistic on that.
Anyway, not having XML-RPC will be a huge downside and WP will lose not just a few users over the time.
June 24th, 2008 at 5:57 pm
@Taybin: The quotes were for emphasis, not intended as a literal quotation. I humbly beg for forgiveness from the internet. :-)
June 24th, 2008 at 6:27 pm
This makes me sad.
I gave MarsEdit a try about six months ago, mainly I think because of Gruber’s endorsement. But I wasn’t really all that interested in MarsEdit; my expectations were pretty low. Why would I need a remote client when WordPress had a full-featured web interface?
Luckily, configuration was a breeze and I was publishing with MarsEdit within minutes. I’ve since realized that MarsEdit saves *huge* amounts of time when it comes to my blogging and podcasting, and makes the whole process infinitely more pleasant. It’s not like turning on a remote clients checkbox in WordPress would be that big of a hurdle, but it may take a newb 20 more minutes to figure it out, or to stumble upon this requirement in the documentation. I’d hate to think that there are people out there who may give up, before they realize how life-changing a good remote client can be to a serious blogger.
June 24th, 2008 at 7:05 pm
We’re not going to drop it. We’re just making it an opt-in feature.
There’s a patch in the works that will deliver an informative message to anyone who tries to access a blog where remote access is disabled, telling them how they can enable it.
June 24th, 2008 at 7:13 pm
@Mark:
I think that if you can pull off that patch, it would be great.
That stays some of my initial problems with the changed default. However, I still like the single API access idea that Daniel talked about – I do realize how much work that is though.
June 24th, 2008 at 7:18 pm
@Mark You say that NOW… let’s the how it will be in 2.7, 2.8 or 3.x …
And when you say you make it an opt-in feature…. do you continue active development for xml-rpc?
June 24th, 2008 at 8:00 pm
WordPress has IMHO a pretty awful security record. (Of course it doesn’t help that it’s written in PHP, a shoddily-designed language with a buggy implementation.)
While I can see a point in turning off services by default, this sounds to me like a veiled admission that they can’t make their XML-RPC code secure, no matter how many times they fix holes once they’re found.
Are they also turning off other much-exploited features like user registration and remote theme editing? I’ve had my own blog hacked through both of those in the past, until I ripped the PHP files out.)
June 24th, 2008 at 8:01 pm
Daniel, what do you think about something like OAuth as a system for either authenticating MarsEdit client access, or at least for flipping the switch on such a security feature? Obviously, we’ve got a suboptimal compromise in that regard with MT, where the APIs are enabled but the password to use them requires explicit user action, and I’d love to figure out a common procedure based on what’s best for users and client developers.
June 24th, 2008 at 8:14 pm
Hehe, your pipe dream sounds a bit like dreaming that all Mac apps supported AppleScript.
Perhaps it’s just the vanity of web tool developers who do not want people to use ‘other’ clients ;)
June 24th, 2008 at 8:16 pm
@Anil – I don’t think the choice of API is the significant thing here. The primary issue is simply whether WordPress can make their code secure.
If they can secure their code, XML-RPC will be secure enough to leave on. But If they can’t, then adding another authentication API like OAth will do nothing but create a bunch of new and untested code that is also likely to have vulnerabilities. That’s not going to help at all.
June 24th, 2008 at 8:18 pm
@ssp:
Can I ask how a pipe dream of API structuring has anything to do with Daniel’s client? This effects all XMLRPC clients equally, not just his.
So this is no way relates to whether or not Daniel doesn’t want people to use ‘other’ clients.
June 24th, 2008 at 8:22 pm
“Anybody with enough technical skill and know how to even operate an offline editor is perfectly capable of enabling the XML RPC connection in their blogging engine preferences.”
As the designer of a blog client I can tell you that is not the case. At all.
June 24th, 2008 at 9:19 pm
Let’s pretend we are not talking about WP at all. Let’s just imagine an abstract network service.
Is it possible to make this abstract service 100% secure?
No. You can never make any network service 100% secure. It’s just not possible. So security, at best is a matter of degree.
Let’s say the security for our imaginary service is very, very good. Even still, that means there is always the chance of an exploit.
If this service is always on, if there ever is an exploit to it (and we can never guarantee 100% security) then the entire installed base is now at risk of that exploit.
If this service is generally not used by the installed base, that means lots of people are exposed to an unnecessary risk. It simply prudent not to expose services that are not needed.
The idea that making everything work as one “abstracted” service will somehow make everything more secure sounds good in theory, and it can improve security to a great degree, but every exposed “functional point” in any interface is a vector for an exploit, even if they all end up going through one common code base at some point.
So what the WP devs are doing is just good sense. The devil is in the details of how they do it so that user experience isn’t too adversely effected. And I’m pretty confident they will do this well.
This all sounds like a lot of needless handwringing. In principle, what they are doing is just sound security policy. That doesn’t mean they don’t have other work to do to improve security as well. It’s not a case of doing one thing or the other. They need to do both.
June 24th, 2008 at 10:16 pm
I’m curious if the change is just for Metaweblog or XMLRPC as a whole, since other services could run there. I’m also curious about what specifically caused this shift in attitude.
Cause and effect aside, this talk that it doesn’t improve security is utter malarkey. Reduce your points of failure, increase your security. Period. If XMLRPC/Metaweblog/Atom is completely disabled, then that’s less code that makes itself executable for intrusion.
It’s not simply a matter of funneling all XMLRPC calls through the same authentication API. XMLRPC offers a completely different route to that single authentication API even if it does exist.
Since the RPC methods authenticate on every call instead of just once to create a session, it’s offers not a single point of failure, but one point of failure for each method. Follow the chain of execution – the check of authentication only happens after the XML is processed (by what means? we can only expect a PHP-based parser – more PHP code), is routed via the XMLRPC library (more PHP code) to the correctly registered function (even more PHP code), which might also run code before it (presumably?) checks authentication.
You can’t easily run all of these methods through authentication before they’re processed this way, making the idea of two doors onto the same secure foyer impossible, or at least extremely impractical. Having a reasonable default setting of “off” for so many exposed points of entry seems the best course of action.
Mind you, most of this is the fault of a lousy RPC spec. The Metaweblog spec doesn’t offer an option for a session-based persistent login. As a result, you must authenticate on each call. This isn’t WP’s fault.
This doesn’t excuse any lack of a thorough security audit on these components, it just says that most users won’t use desktop clients (it’s the truth, no?), and choosing a secure option by default for the most users is better than leaving everything wide open for so a proportionate few can blog from their desktop apps.
June 24th, 2008 at 10:43 pm
Jesse Read: I don’t know of any other systems that are strongly embracing this idea of an API that is used by the web interface. To be honest, this dream is one of the things that sometimes motivates me to think about implementing my own blog server software :) I am trying my best to resist that urge.
If anybody knows of such an effort, I’d love to know about it.
June 24th, 2008 at 10:44 pm
This kind of attitude, while incredibly common and something I wielded like a war-hammer four or five years ago, is responsible for more real world security breaches than most anything else that comes to mind. It creates a situation where a single slip up means you’re compromised. Good thing programmers never make mistakes, eh?
WordPress is Legacy Code. WordPress has a huge install Base. A good portion of WordPress installs are on shared hosting environments where server security is an afterthought. Weblog engines are probably the second most attacked thing on The Internet after Windows boxes.
All things considered, I think they made the right call.
June 24th, 2008 at 10:46 pm
Nathaniel: I can cop to being a little dramatic here in this post, but I think it’s just as easy to use the accusation of FUD against the people who are promoting this change as being useful for security.
I think anybody who has traveled recently by airline knows that real security doesn’t come from merely calling out purported risks and acting on them. Have you enjoyed taking your shoes off at the security checkin?
There’s a place for restricting compromise. I think it’s when the positive results of such a compromise are clear and can be communicated convincingly by the authority imposing the restriction.
June 24th, 2008 at 10:50 pm
Devon: Regarding your comment:
My response is intentionally absurd, but to make a point: the same would be true if you disabled the web interface to blogs by default. The real problem here is WordPress is choosing to call out the remote access interfaces as insecure, and to shut them down, without any evidence that they are security risks. In fact, the bulk of security compromises seem to be coming from outside the remote interfaces.
So perhaps WordPress would be more secure if the web interface was shut down and everybody was required to access their blogs through the remote interfaces.
(Absurd on purpose).
June 24th, 2008 at 10:56 pm
Anil: I am open to the idea of a user-engaged authentication scheme. It might take some changes in clients, and the idea of throwing the user out from a desktop client to the web is a little off-putting, but at least it would be a standardized way of hand-holding the user to full functionality.
June 24th, 2008 at 11:01 pm
One last comment, addressing the valid points many of you have made about this being a “step in the right direction.” The problem is that blindly restricting access in the name of security is a dangerous direction to move in.
Even if you feel that the restriction will be a net gain to WordPress (I’m doubtful), it’s important for proponents of WordPress (I’m one of them!) to consider how this decision will affect the perception of WordPress’s security and of how tactfully and skillfully they deal with the balance between security and functionality.
To all of those who are convinced that this is a good move for security, I would ask you to at least consider the fact that this will be viewed by many as a needlessly restrictive move, and will drive some people to abandon WordPress after being loyal to it for years. I’m not saying that’s completely logical, but the feedback I’ve seen here, and on Twitter, and on blogs around the web that are linking back to this, supports this view of the situation.
I’m not looking forward to WordPress being “easy to configure – with a caveat”. When and if 2.6 ships with this functionality, I’ll probably feel compelled to recommend other systems as easier to configure for newbie remote editor users.
June 24th, 2008 at 11:09 pm
I’m also a remote client programmer, and I think this is a bad idea as well.
It doesn’t save the WordPress team anything. So long as they offer the interface they had better assume that every user has it on. Otherwise they’re not really thinking about security in a meaningful way. It saves them no work.
It is — to twist the knife a bit here — the Windows Vista approach to security. Annoying users and restricting access to services doesn’t fix underlying security problems. Thing like testing inputs does.
At best this removes one possible vector for attacks for some. The tradeoff in terms of user annoyance is not worth the marginal benefit.
June 24th, 2008 at 11:25 pm
@Alan: “It creates a situation where a single slip up means you”™re compromised.”
I have no idea what you mean here. What makes the XML-RPC interface different than any other? *Any* slip-up in *any* networked interface can mean a compromise. That’s the nature of writing networked code. The same goes for the admin interface, comment posting, user registration…
Some people seem to think there’s something special about XML-RPC that makes it inherently less secure. Not so – It’s just an HTTP POST, just like any other change made via the web UI.
June 24th, 2008 at 11:29 pm
@Owen – “Since the RPC methods authenticate on every call instead of just once to create a session, it”™s offers not a single point of failure, but one point of failure for each method.”
Authenticating on every call makes it *more* secure, since the user’s credentials have to be checked explicitly every time. This eliminates the possibility of common Web exploits like session hijacking, cookie poisoning, and various flavors of cross-domain attacks.
This is also the same approach used in the authentication mechanism built into HTTP. The only reason cookie-based authentication was developed was to make HTML-based user interfaces more flexible, so logins could be done via a web form instead of a modal password dialog box. It’s not because it’s a more secure mechanism.
June 24th, 2008 at 11:37 pm
Jens: I really like this quote:
It’s really an important point to remember. The web interface is FILLED with access points. The XMLRPC interface has just one. Theoretically and realistically it should be a million times easier to secure the XMLRPC interface, because you can easily apply a single authentication test to every incoming request.
Thanks for bringing this important point into the light.
June 24th, 2008 at 11:39 pm
I can see the benefit of giving users the choice, whether or not they want remote applications access into their blog. For users who know they’ll only edit via the web interface (ugh) then by all means, disable a feature you’ll never use. But the approach as I understand it (off by default, user intervention needed to activate) is far from user friendly. It’s the non-technical user who will be most effected by this, and not in a good way.
If WP goes this general route, it should be an install-time option. “Do you want to edit with a remote editor Y/N?” Upgrades should preserve existing functionality (do no evil).
I really like Daniel’s suggestion for a single API approach. I also like the idea of requiring one-time authentication (as others have described Flickr).
The WP 2.6 approach, as described, degrades user freedom with the excuse of security. I’m not happy when a government does that, so I’m not happy here either.
June 25th, 2008 at 12:13 am
The WP architecture, IMHO, suffers badly from a lack of foresight regarding input filtering, and the XML-RPC interface has been a source of lots of problems for them, so it’s not particularly surprising that they’re interested in turning it off by default — it will plug a hole for the majority of installs, I suspect, even though it’s kinda done in a surrender-ish way.
I would hope that the WP team would take this as an opportunity to not just deprecate MetaWebLog, which is sucky in a few different ways, but to put forth a new approach for blog-oriented web services that doesn’t suffer from the same problems. If MetaWebLog is broken enough that it should be disabled by default, a replacement is probably called for.
June 25th, 2008 at 12:28 am
Disclaimer: I’ve been a WP user since v1.2. I’ve been a MarsEdit user since 1.x (I can’t remember exactly, but Brent owned it at the time). Been particularly happy with both for as long as I’ve been using them.
The core problem generally boils down to the fact that most people don’t upgrade their self-hosted copies of WordPress. I can’t begin to list the amount of sites I’ve visited where I check the header, and it’s some ancient version, probably from when they installed and started writing.
The WordPress crew are excellent at fixing security holes, and after working with lots of different PHP software, I can attest to the simple and unique upgrade scheme that WP employs. I constantly swear at other web apps, because their install/upgrade process is unnecessarily convoluted.
That said, I’m fairly technical and know what I’m doing. Most people don’t. In that case, I tend to recommend that they host their blog on WordPress.com, or they find someone who’s willing to make sure their software/plugins are always up to date.
Over the years, WordPress hasn’t added tons and tons of new features. Why? Because most extra functionality can be implemented through the plugin API. Paring down “extra” services means you’re cutting out more and more features that people rely on – what’s next? Commenting forms? Gravatars? (another new feature that seems to be on by default) How about disabling the plugin API upon an install? If you want plugins, you can go turn that feature on. Right. This adds barriers that only technical people will know how to tackle.
At this point, we’re making WordPress 2.6 harder for a newbie to use than WordPress 1.2 ever was.
I think the approach of putting messages in the WP admin to upgrade, and building automatic plugin upgrades, are two steps in the right direction. Handle security problems as they happen, release new versions, and make it easy for people to upgrade.
If people are going to use an ancient version of WordPress, and they get hacked because of an old problem that was fixed before anyone even knew how to exploit it, then that’s their problem. The WP support forums won’t even help you before you upgrade, will they? There’s a good reason for that.
This move won’t make me move away from WordPress, but I’ll certainly be following development much more closely – so I have an idea when decisions like this become more prevalent.
June 25th, 2008 at 12:51 am
@Jens – “Authenticating on every call makes it *more* secure, since the user”™s credentials have to be checked explicitly every time. This eliminates the possibility of common Web exploits like session hijacking, cookie poisoning, and various flavors of cross-domain attacks.”
Whether this makes the system more secure depends on where you’re looking for security in your system.
By authenticating every time you send your username and password in cleartext to the RPC endpoint in every method request. It seems fundamentally flawed to call this repeated transmission of cleartext credentials “more secure”. Doing so also requires the exposure of the maze of code I mentioned earlier.
It’s true that HTTP AUTH sends credentials every time, but that doesn’t mean it’s better in terms of security. Just like with XMLRPC, basic HTTP AUTH also sends passwords in cleartext. WSSE-like challenge-response logins are something that Metaweblog does not offer.
Sure, session-based logins aren’t inherently more secure, but they can be made more resistant to attack than sending credentials directly in each request.
Consider a session in which you make five requests to the RPC endpoint. In each of those requests, you transmit cleartext credentials that work to log into both the RPC resource and the web-based editor, which are collected just by watching the posted data flow by. With the improved login code added to WordPress in recent builds, the XMLRPC mechanism is actually more susceptible to this style of attack than the cookie-managed web-based login, which is perhaps a reason why they’re disabling it by default.
If instead, the system provided an subnet/time-limited token based on an initial WSSE or digest auth request, it would be measurably more secure than sending passwords in cleartext for all five requests. If the token is time-limited, even if you guessed it correctly, it only works for a short period, unlike passwords that are infrequently changed. If the token is subnet-limited, you’ll have significant difficulty even using it from another IP in the first place.
Even if the login mechanism is improved beyond anything imagined here, having XMLRPC open for use allows that vector of attack. By turning it off that vector is denied, making the software more secure. Funneling the login through the same authentication API gains too little to invalidate the disabled state as a default, since so much sits between an RPC method and any login API’s execution. Inherent security on the web-based login is now so much better, the only real way to protect the majority of users as well in the RPC vector would be to turn it off by default.
What would be a happy outcome of all of this is if toolmakers of WP, MT, MarsEdit, and the like would stop futzing around with lousy protocols that don’t work great in practice and start putting weight behind constructing protocols that make sense. It’s certainly possible to create a more secure mechanism to log in and a better overall user experience.
June 25th, 2008 at 1:24 am
@Mitch – re. “I can see the benefit of giving users the choice, whether or not they want remote applications access into their blog.”
*Everyone* allows remote applications access to their blog. The only way to avoid it would be to disable the entire admin interface and SSH into the server to edit the MySQL database.
@Ed – “If MetaWebLog is broken enough that it should be disabled by default, a replacement is probably called for.”
The Atom Publishing Protocol is a much superior REST-based replacement. (One detail is that it uses regular HTTP auth, which would make it more secure.) But the WordPress people haven’t shown any interest in adopting it, last I checked.
@Owen – You have a point about cleartext passwords in XML-RPC. I’d forgotten that little detail; indeed, that’s a stupid design. It would be easier and more secure to just use HTTP digest auth for the POST that sends an XML-RPC command.
But on the other hand, I don’t believe that people’s WP blogs get pwned because someone sniffed their cleartext password. Instead it happens because of security holes in WP (or PHP libraries or the PHP runtime) where some coder forgot to check the user’s credentials, or didn’t understand how to detect integer overflows, or thought it would be really clever to call ‘exec’ on text received over the network. (Yes, those are all true examples.)
June 25th, 2008 at 1:46 am
@Jens – “But on the other hand, I don”™t believe that people”™s WP blogs get pwned because someone sniffed their cleartext password. Instead it happens because of security holes in WP”
Absolutely true, and that’s my main point really. There are a lot of points of failure in XMLRPC having nothing to do with authentication in specific. Consolidating it all behind a single auth API may improve things, but that’s not as secure an alternative to disabling RPC services by default for the majority of users who will never use them.
Digest auth would be great if PHP could provide it, but Apache (at least older versions that tend to be ubiquitous, I’m not sure about newer versions) doesn’t allow CGI applications to do it. Remember that basic auth with Atom is really no better than sending your password on every XMLRPC request. WSSE requires plaintext passwords on the server, which is silly. We’re between a rock and a hard place and another really hard thing.
We could do better, perhaps, if the Metaweblog protocol itself would allow digest-like authentication. I think that’s where we get stuck — nobody wants to revise these specs to make sense.
I would love to see the good desktop editors and some blog tools take on this challenge, instead of leaving it exclusively to the standardistas. Atom looked promising, but I think it needs some extending to work well with blogs in the wild, like allowing different content statuses and types.
June 25th, 2008 at 4:46 am
“The Atom Publishing Protocol is a much superior REST-based replacement. (One detail is that it uses regular HTTP auth, which would make it more secure.) But the WordPress people haven”™t shown any interest in adopting it, last I checked.”
You should check again, WordPress has the most complete implementation of RFC 5023 that I’m aware of. It still hardly gets any usage because there aren’t any real clients for it, but starting in April that started to clip up.
This decision had nothing to do with authentication, or the merits of XML-RPC or APP, it’s about taking functionality that used by a small percentage of users and having it be secure (off) by default. Someone earlier suggested we do the same thing for user registration — we do and have for 3 years. It’s off by default with a checkbox to turn on.
June 25th, 2008 at 7:16 am
I still don’t get *why* would you need this enabled by default. It’s similar to DCOM on Windows which was accessible from the Internet for a long time. Most people don’t need DCOM and don’t even know what it is. When a huge security flaw was found, everyone got infected by a virus. If this was turned off(Windows firewall blocking it or DCOM service disabled) then the attack base is much smaller. Even if the method seems secure it doesn’t make any sense to me why this should be turned on by default when a very small percentage of people use it or even know it’s there. I don’t think it should be left on just to make it easier for people.
June 25th, 2008 at 10:54 am
If the majority of WP users are not using the API at all, then wouldn’t the “disabled by default” security pattern make sense no matter how good the underlying security is? Even if WP replaced their current API with some imaginary infinitely secure system (and of course don’t bodge it up and introduce new security flaws along the way), if most users don’t need it, it shouldn’t be turned on by default.
I see this as a good healthy, interim solution – and not some indication that the WP folks don’t have a clue what they’re doing (which may or may not be true).
Obviously disabled by default will make it just that little bit harder for new WP users to get it working with MarsEdit. And I can see why you’re opposed to that from a business perspective. This WP feature will either increase your support costs (Help! ME doesn’t work with my new WP install!) and/or restrict your adoption amongst new WP users (Can’t get WP to work with ME, screw this POS).
That will suck for you (and other API users) for sure, but raising this much FUD about it seems very disingenuous.
June 25th, 2008 at 11:58 am
@Matt – Great to hear that WP supports Atom Publishing nowadays! I’ve been out of the loop on the APP for a while, so I hadn’t heard the news yet.
June 25th, 2008 at 2:22 pm
As an Ecto user, the proposed change in 2.6 is a small aggravation but not a show stopper. As long as WordPress is clear about what people using third-party publishing tools need to do, that would be enough for me.
Mark
June 25th, 2008 at 3:09 pm
“WordPress”™s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.”
Umm no… you are misleading people into thinking this has to be done repeatedly.
It is much more like, when you open a savings account, checking either the box that says you want an ATM Debit card and/or the box saying you want to access the account through the online site. Eliminating either of those options would make your money more secure.
I agree that there is an issue with people upgrading and finding that MarsEdit doesn’t work. That is easily solved by keeping the XML interface off by default on new blogs, but not changing the behaviour for upgrades.
That should be considered,
June 26th, 2008 at 2:29 am
@I said: “It creates a situation where a single slip up means you”™re compromised.”
@Jens Alfke Says: I have no idea what you mean here.
I was just pointing out that if you rely solely on perfect software engineering to secure something that you’re asking for trouble. The “slip up” refers to a bug getting into the codebase that causes a vulnerability that might be compromised
June 26th, 2008 at 7:17 am
Thanks for the head’s up on version 2.6. It’s a shame they’re doing it that way around – your solution seems spot on!
…let’s hope WordPress is listening!
June 26th, 2008 at 12:21 pm
Why not just ASK the user in the upgrade process if they’d like to disable these options? Turning them off by default will kill many integrations inadvertently. It’s a terrible choice.
June 26th, 2008 at 2:57 pm
Daniel,
After I read your post, I was pretty peeved (for the same reasons you mentioned). Semantical arguments about the security benefits of default disabling aside (I don’t care), having to go through an extra step just so I can post in my blog — while a minor inconvenience — makes me worried about the long-term API support. And of course, is just one more thing I have to keep in my arsenal when doing unpaid tech support for friends/family who use WordPress and a blogging client.
That said, if 2.6beta1 is any indication, for new installs anyway (upgrades didn’t get a notice but I also didn’t check to see if it disabled the feature by default) DO ask if you want to enable/disable remote blogging. The check box is unchecked, but it is there during the standard WordPress install screen. That, I can live with. If the same sort of screen could appear to upgrade users too — informing them of the change and letting them say yes or no (it could be on the upgrade.php page), this won’t be a huge deal for existing users.
As for users who are installing WP for the first time, yes, it’ll require more work to get MarsEdit and others to work out of the box, but at least the setting is easy to find.
Check it out: http://img.skitch.com/20080626-tumdstx1jh8ma8x4hdyjc12ych.png
June 26th, 2008 at 3:06 pm
Christina: the bad news is that the WP team has since decided to yank that option from the startup process. They’re afraid it will cause too many users to inadvertently turn it on (sigh).
But the good news is that they are talking now about putting an error message in for blog clients that attempt to connect, so that at least the user will have a chance of understanding why the client is not working as they expect.
June 26th, 2008 at 4:31 pm
Daniel,
Dude, that sucks. *sigh* indeed. I would rant about it, but I’m sure you’ve been there/done that. I do hope they include a HELPFUL error message so that users who upgrade and don’t spend their life following WordPress development can easily enable remote blogging.
June 27th, 2008 at 7:07 am
Wonderful. Of course it’s much easier to axe some setting instead of implementing something useful (like HTTP digest authentication around the RPC backend).
June 27th, 2008 at 9:05 am
Christina: Revision 8202 takes care of the messages. XML-RPC now tosses:
$this->error = new IXR_Error( 405, sprintf( __( ‘XML-RPC services are disabled on this blog. An admin user can enable them at %s’), admin_url(‘options-writing.php’) ) );
while APP tosses:
$this->not_allowed( ‘AtomPub services are disabled on this blog. An admin user can enable them at ‘ . admin_url(‘options-writing.php’) );
Brief, yes, but instructive, I think. Hopefully it’s enough.
June 30th, 2008 at 6:34 pm
@drew
all is forgiven. please come home. :)
August 5th, 2008 at 10:09 am
As for the security the idea of WP developers is not really good. As for the convenience of using the service it is not good too, especially for the users. I still do not understand the point of this innovation.
September 24th, 2008 at 9:03 pm
Wow. It requires checking exactly one radio button. Why all the fuss, Russ?
September 25th, 2008 at 7:10 pm
How to enable wordpress remote access? I have just installed a wordpress new version, and have the trouble to setup XML-RPC services.
September 27th, 2008 at 3:45 pm
Isn’t it just possible to find a module for wordpress which allows API approach?