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.
One Web security task that slips through the cracks, even for experienced developers, is ensuring your forms originate on your server, through the use of a nonce, or a one-time, unique identifier for your form.
Why is this important?
- A favorite attack vector is to duplicate forms on a remote server, and attempt cross-site scripting (XSS) attacks that way. It’s far more convenient to me to write a curl routine that varies up the junk inputs I’m trying to run on my own server, than to run a bot that fills out the target form on its own host.
- Ensuring your form is submitted only once is most easily managed if you generate a unique identifier, created every time your form is created, and storing that identifier in some persistent data store; namely, a database, XML file or the like.
- A unique identifier for your form gives confidence your form contains what you expect. We can’t be absolutely sure that a properly formed nonce means your form is 100 percent pristine — we still need to check all inputs are present and contain what we expect — but we can usually begin our security checks by seeing if the nonce is present and well-formed, before doing things that constitute heavy lifting, such as sanitizing other inputs, doing calculations on them and rendering up a response or additional steps.
There are a lot of ways to create a nonce, and how best to proceed depends on what goal you have.
Sometimes, you just need to ensure the form originated on your site; it doesn’t need to be one-time use. Other times, you need to be absolutely certain the form is only submitted once. And occasionally, you need to time-limit when a form can be submitted.
I’ll start by addressing the middle requirement first: A one-time-use nonce, which isn’t time-limited (that is, the nonce can be used anytime, but once used, can’t be recycled). In upcoming blog posts, I’ll address the other two methods.