Wandering Thoughts archives

Web site security theatre

'Security theatre' is the term I've seen Bruce Schneier use for pointless things that are done mostly to make it look like you're doing something about security. Websites are especially prone to this disease, because everyone knows that the Internet and the web are insecure and overrun by hackers, right?

Today's shining example is the US Air Force Cheyenne Mountain public website, which seems to be pretty much a PR site (complete with cheesy photos). Despite this un-sensitive usage, Cheyenne Mountain has decided to make it a https based website. Just in case the Air Force doesn't want a hacker in the middle knowing which bits of their PR you browsed, or something.

What elevates this into true security theatre levels is that their SSL certificate expired September 6th, after a three year run (instead of the usual one year).

(And while I'm here, I must throw some brickbats in Firefox's direction for their certificate display; in this day and age, showing dates with unlabeled two-digit years is asking for it. Quick, was this entry written before or after '06/05/07'?)

The danger of relying on Javascript for input validation

I've run into a few websites that do some of their input validation on forms and the like entirely in Javascript. If you are tempted to do this, please don't; not only is it dangerous to you, it's annoying to users.

It's annoying to users due to what can happen to innocent users who try to use your forms with JavaScript turned off; if your forms are still submittable, the user can wind up unintentionally creating bad data in your system. This is usually very hard for the user to correct afterwards, since (of course) all sorts of things in your system are likely to malfunction in the face of said bad data.

Users, including users not using JavaScript for various reasons, have a rational expectation that if they make mistakes your site will reject them, not damage or destroy their ability to use your site. You break this implicit promise at your peril.

(In this case, being unable to submit the form at all is actually the best outcome, because it clearly tells the user that something is wrong while stopping them from doing any damage.)

For example, I once tried to create an account on such a website. The account creation form asked for your login name and your password; I picked a login and left the password field blank, assuming that either the system would spit an error at me or it would create a random password. Instead, it created the account with a blank password, which it turned out wasn't supposed to be possible, and various bits of the site were not too usable as a result. Including the password change form.

Unsurprisingly, I haven't really been back since.

Something I really wish vendor product pages did

Dear vendors:

When I am visiting your fine web pages, I am often most trying to find which of your products have a particular feature that I need. Making me carefully check through all of your products, examining their model numbers (if I am lucky) or each of their detailed feature pages (if I am not) is not productive and does not make me very happy.

(It does make me thankful for Firefox's tabs.)

So what I would really like to see is a product feature search page of some sort, so that I could tell you that I am looking (for example) for a PCIe graphics card with dual DVI outputs that is based on the ATI X800 or X850 chipsets, and you can give me a nice list of just the things I want, thereby encouraging me to buy from you instead of from someone else who irritates me less.

You can even get yourself some Web 2.0 buzz by calling this 'tagging'.

(I want an X800/X850 based card because that is the most recent graphics chipset (that I can get in a PCIe card) that has open source 2D support. I would like open source 3D support, but my options for that seem to be either an ATI Radeon 9200, available only in AGP, or Intel graphics, available only as integrated graphics on motherboards.)

Stupid web spammer tricks

I'd call these stupid spider tricks, except that these were so visibly committed by web spammers. (In one case they left me their spam, clearly visible.)

• you cannot take a POST form's form elements, turn them into query parameters, and then try to GET the result.
• especially if you remove the existing query parameter on the URL of the form's target.
• you get modest bonus points if you POST your query parameter laden URL instead of GET'ing it. Not enough bonus points to make it work, though.

I have to admire the determined necessary to carefully program your software to do stuff like this. Or, alternately, the gleeful blindness required to ignore the fact that there are two ways of submitting form data, and just implementing the easier one and using it for everything. (In this view, the POST to GET person is at least being consistent; his software may not implement POST at all.)

The existence of these things depress me, because the fact that the web comment spammers do them suggests that they actually work against some blog software. And that's just sad, but then a lot of web software (starting with Apache) is very sloppy about this stuff.

(Accepting POST requests in GET form is especially bad because it opens you up to lovely cross-site attacks if I can so much as persuade you to click on a link. If you think this is obscure, consider how it could be combined with cross-site authentication like OpenID to let it be targeted. Add JavaScript, and I probably don't even need to get you to explicitly click something.)