Another technical humor post . . .

A couple of weeks ago, I posted some pieces I found at the Worse Than Failure Information Technology blog.

I visited again and found myself entranced once more with a discussion of Security Practices Gone Wild. First in the original post but perhaps even more by the comments made as a result of the post. Amazing what computer programmers have to deal with . . . and the kinds of things, then, that they think about.

To get you started, let me quote from the original post:

It's common knowledge that a security system is only as effective as its weakest point. You can install a reinforced steel door with a two-phase palm-print/retinal-scan entry to protect your home, but if you leave a first-floor window open, you're more vulnerable than your neighbor with a simple deadbolt. One of Nate's clients learned this lesson first hand with its e-commerce Web site. The operation didn't involve terribly sensitive data: there were no bank accounts, no Social Security numbers, nor even any credit card numbers. Pre-approved customers would simply sign in and place their orders. Accounts payable and fulfillment would take it from there.

Yet the Web site painted a different picture, featuring two-factor authentication, encrypted databases and a giant padlock graphic advertising "secure."

Before Nate's team arrived, hacking the Web site proved to be about as difficult as entering a house through an open, ground-floor window. The original developers managed to implement virtually every type of vulnerability:

• Query String Replacement. Users could (and did) fiddle with the URL in the address bar (for example, changing "/viewOrder.asp?OrderNumber= 80023" to "/viewOrder.asp?OrderNumber= 80024") to view other customer's data.
• SQL Injection. By using single-quote characters, attackers were able to easily "inject" SQL code. For example, typing "' OR '' = '" in the Password textbox would result in a query that asked for users "WHERE Password='' OR '' = ''." Because an empty string ('') is always equal to itself, this would always return a user.
• Trusting the Browser. Instead of using server-side code to disable and hide unauthorized navigation links, CSS and JavaScript were used. A quick "View Source" or even a line or two of JavaScript type in the address bar could (and did) easily bypass the protection.

Every time the Web site was hacked, the original developers insisted it was an infrastructure problem. They had the company buy a secure certificate. Then they added a separate database server. Then they installed a firewall to put between the servers. Then an intrusion detection server. And so on. Still, hackers waltzed right in.

Eventually, the company decided that enough was enough and hired Nate and his team to remediate the problems. But his hands were tied as the client insisted on dictating security requirements. And dictate they did. . . .

Enjoy!

. . . Oh. I posted this partially to "explain" how I got to Spamusement.com (see my post directly beneath this one). --One of the respondents said the proposed security measures everyone was talking about reminded him of this "Security Issues" cartoon.