Let’s start with the visual image of one of those mechanical claw arcade machines – the one where you insert a few quarters and grab a toy with a mechanical claw. These can be addictive games for some of us.
Let’s take that same visual image. But instead of a claw dropping down onto a pile of beanie babies, let’s visualize a hacker reaching through your login screen and feeling around for your database. Picture the hacker running impenetrable scripts instead of using the arcade game joystick. To the hacker, the joy is in the profit from your data, not the hacking.
If I can push my analogy just a bit further, let’s look at the arcade game and your website from a purpose perspective. The arcade game’s sole objective is to make money by keeping you from snagging a toy, while still making you think it’s possible to do so. On the other hand, the majority of business websites are focused on serving the business, with almost no thought given to protecting the prize – the database information.
As a great example of a poorly conceived and vulnerable website that should get you thinking about your own world and who might be reaching for your data, let me tell you about a local company that avoided a major security breach by pure luck. The client company, a local law firm, contracted with a web development company to create a fair-sized website (around $100,000) as a company brochure site, with a back-end database and UI that would exchange client-lawyer private legal information as well as take in credit card information. This is pretty standard stuff in the web world.
On the security side, the web development company’s words of assurance included:
“We are armed with the latest technology and information to lock down your systems to prevent unauthorized access.”
Actually, this is much more than most web development and design companies will commit to. The Plausible Deniability approach to security (… to the best of my knowledge, the site was secure …) is the more likely conversation most web design and development companies will have with clients.
All went well until the legal firm decided to run a few checks on the new website. A security team ran a few ‘hacker 101’ checks on the website password recovery screen, which quickly gave up any pretense of being secure and provided the following error (if this is too geeky to read, just nod your head in a knowing way):
Microsoft OLE DB Provider for SQL Server error ‘80040e10’
Procedure or function ‘sp_Users_GetNewPassword’ expects parameter ‘@Password’, which was not supplied.
/submit_userpass.asp, line 35
The ‘real person’ translation of this is that the security team now knew how to reset anyone’s password (lawyer and lawyer’s client) to any desired value – they could own any account in the system. In addition, because of the ease of access, the team also knew they could do anything they wanted within the database level; including grabbing any data on the server and wandering throughout the client’s entire network. Yep, the entire network was toast.
The client is a large legal partnership with hundreds of lawyers and the possibility of millions of dollars in fines if private client data was stolen. When the client principals were presented with the security findings, a very pale president turned to the CIO and asked if the website could be taken down immediately. It was, with a placeholder site inserted until the original site could be secured.
The good news is that the client will make it through this learning experience with only a modest remediation fee and some very hard words with the original development company. But even though this client got lucky, there are literally hundreds of thousands of website time bombs like this sitting around, waiting for a hacker to reach in and grab the database. The focus is never on protecting the prize (database), just taking care of the business.
In this case the client company did everything right, but got caught anyway. At the start of the website development engagement, they asked all the correct security questions and the website development company said all of the right words. Unfortunately, the development company did not have a clue. The security flaw described above, SQL Injection, is so basic and easily avoided it should have never been missed, let alone missed the 100+ times it was found in the site.
The one take away from this story should be the fact that design and development of web sites is a totally different discipline from web security. Even the best design and development firms will find it difficult, if not impossible, to deliver a secure website; the worst firms, as in this case, do not stand a chance. This doesn’t mean you need to avoid your favorite design and development firm, just make sure you ask them about security – then check on them when your website is close to completion.
One more piece of insight, this one from a claw game master – the best time to play the claw game is immediately after it has been filled with new stuffed animals; the larger the pile, the more likely you are to grab a toy.