Working with a business-to-business e-commerce company, I was hired to to improve functionality for their web-based order form. But it helps to have fresh perspective on a process. I immediately saw the opportunity to do what they were asking, but better than they intended. I would give them the opportunity to up-sell larger quantities of their product while reducing the number of clicks a customer would have to make to complete their order process. I was thinking “sure, it will take a little more elbow-grease, but the end result will be far more attractive”. I wanted to establish a positive relationship by delivering more than they bargained for. And I did.

While working at implementing my new functionality, I had to modify an existing call to their MySQL database. Now we all know working in someone else’s codebase is always a bit mucky, but while adding a field to their database query I couldn’t help but wonder “Is this really secure?”

So I took to google, reading up on best practices and security vulnerabilities. Everywhere I looked recommended using built-in libraries for creating these queries, but the way it was being done was fully prone to SQL Injection.

I could have ignored the issue, and maybe I should have. I could have informed them of it, while hackily adding the functionality they requested. But when it came down to modify that SQL query to get the data I requested… I just couldn’t do it. It broke my heart to know that I was using such flawed code. I was also worried that if there was a security breach, I might be blamed for stolen or deleted data. I resolved to fix it.

As you can imagine, when something isn’t done correctly the first time, it can take a bit of effort to refactor it. This was no exception. I was able to fix the flaw and deliver what they initially asked for, but I was billing hourly and already at my quoted capacity for the job.

Movies often glorify hackers. The protagonist can just call his bespectacled hacker friend who can access any system and get the information he needs. But we all know security isn’t sexy in the real world. So while I knew I was delivering more value than they asked for, I wanted to prove they were getting their money’s worth. So I went to do some extracurricular work, hacking into their database for fun.

This proved a lot harder than I thought it would be. It was not as easy as adding a few escape characters and executing a DROP TABLE ‘users’ command. There is far more subtlety to SQL injection than I knew. In the end, I spent about 5 hours proving someone could leach a few fields of data from any table in their database, and writing up a detailed explanation of how the attack worked and a couple of curl commands they could execute to do it.

In the end, I was met with a response that allotted to “Wow. Well thanks, I guess.” While I was hoping they’d ask that I secure the rest of their site, they didn’t seem super impressed or worried about an attack in the future. A word of warning: some folks just don’t see the value in securing their data.

The light at the end of the tunnel is that they’ve recently reached out to open another short contract. This time around, it should be a lot easier to fix any flawed SQL queries when I come across them. And since then I’ve learned about some new tools that could make me far more dangerous at proving SQL exploits ;)