Part 2 in a series on WordPress XML-RPC
A significant amount of hue and cry in the WordPress world surrounds security, and not without some cause; a poorly implemented install is susceptible to attack, especially in earlier versions.
Such protests are amplified when it comes to XML-RPC, the SOAP service used by WordPress to allow outside access for content management.
This is largely nonsense. The fact that 9 out of 10 WordPress installs have a well-known admin url (/wp-admin), and probably two-thirds of such installs have a administrator login with the user name “admin”, is a far greater vulnerability than the presence of an XML-RPC server at a known URL.
Because hey, at least XML-RPC limits what can be done to a WordPress install, and structures how you interact with it. It’s the difference between letting your crazy uncle live in the basement, versus giving him the keys to the house: He might burn the place down, either way, but at least you know he won’t steal the silver or make a mess of the living room.
In short, making XML-RPC secure involves the same steps as making WordPress secure, and if you properly secure your WordPress site, you need not fear what XML-RPC might do.
This one is a bit esoteric, but it had been befuddling me for months:
When using a WordPress blog hosted on DreamHost, unless your blog is using an email address set up on DreamHost, some emails sent by WordPress will be rejected outright by Gmail (and other email services) — namely, any message that has an attachment won’t be accepted.
The fix: You need to either create a real email address, on DreamHost, that uses your blog’s domain; or you need to use a third-party email service; or use a plugin to force WordPress to use SMTP for sending emails, and then configure your SMTP server to properly handle messages.
In three previous posts, I discussed creating a single-use form nonce, a multiple-use form nonce and a time-limited form nonce.
In this post, I’ll describe creating a single-use, time-limited form nonce — that is, a token, unique to each form iteration, which can only be used one time. That will ensure not only that the form was created on our server, but also that it cannot be used a second time, and that the form was submitted in a timely fashion.
I’ll build upon my previous single-use nonce methodology, by adding an additional column to my MySQL table — which stores the time at which the nonce was created — and process the form by comparing that time to the time of the form’s submission.
Why might I want to do this? A clear case would be in ordering a commodity which is scarce, such as a concert ticket. I don’t want to allow the end user to hold a lock on that ticket forever — if he doesn’t order it quickly, I want to make it available to someone else who wants it. And I also don’t want to double-charge him if, for some reason, the form is submitted twice — such as with a refresh of the ordering page.
Previously I blogged on creating a single-use form nonce token and creating a multi-use nonce in PHP.
Advancing the subject, let’s now look at limiting the timeframe in which a form can be processed through the use of a nonce, or a one-time, unique key that ensures we generated the form on our server.
There are several reasons why you might want to limit the time available to fill out a form; for example, you have limited supplies of something you are selling and don’t want a single customer tying up that stock while he dithers on a purchase (witness TicketMaster); or you may have a results set that changes all the time, so you want the visitor to act quickly, before the records he requests get updated behind the scenes.
To accomplish our time limit, we’ll build on the multi-use form nonce example I previously provided, only this time we’ll change up our pattern a little. We’ll prepend and append some random characters to a Unix timestamp, then retrieve that timestamp and see if the form’s submission time falls within the time limit we’ve set.
In a future post, I’ll describe storing this timestamp in a database, in order to work with our previous, single-use token example.
Previously I wrote about creating a single-use nonce — that is, a unique token that ensures a form was created on your Web server, and hasn’t been previously used — by leveraging MySQL.
That’s useful when you not only need to be sure your server created a form, but also when you need to ensure the form cannot be resubmitted; for example, if you’re taking a order and don’t want to double-process it.
Sometimes, all you need to do is ensure that you created the form. There’s no harm in submitting it twice, or at least the damage would be minimal; for example, you’re asking a user to select some set of criteria, and on that basis, you’ll fetch some database records and show the results.
In those cases, all you really need to do is create a random string of characters and numbers, in a pattern known only to you, and encrypt that string so that all but the most determined cracker cannot easily replicate the pattern.
To that end, we’ll use mcrypt and a couple of functions to both encrypt and decrypt a string, and pass that back and forth in a hidden text field.