Over the past few years, a number of companies have made the news over leaks of sensitive information varying from customer data to credit card numbers. It seems that regardless of size or profitability, whether they’re online-based such as LinkedIn and LivingSocial or have a physical presence like Sony or Target, nobody is invulnerable to these attacks. So how does this happen?

The answer is, to put it simply, “It’s always the little things.” In this case, the proverbial stone that brings down the corporate Goliath is known as an SQL Injection attack.

SQL, or Server Query Language, is the language that databases speak to process, store, and display information. If you have an account on a website or shop at an online retailer such as Amazon or eBay, SQL is operating behind the scenes to produce everything that you see. Howe
ver, since the database on your favorite site needs your input to log you in, show your favorite items, and store items in your shopping cart, that leaves an opening for abuse. In the case of SQL Injection attacks, user input is used to exploit that opening to speak directly to the database and, in a way, “twisting the words” of the SQL to provide access and information it normally would not provide. Depending on the security (or lack thereof) of the database in question, the result can lead to unintended access of anything from customer passwords to high-level access and financial data in the worst cases. And these kinds of attacks happen more often than you may think; according to a study by the Ponemon Institute, nearly two-thirds of respondents surveyed had suffered a successful SQL injection attack last year. http://www.dbnetworks.com/news/news_04162014.htm

What makes it worse is that in most cases, the proverbial Goliath could simply wear a helmet to prevent these attacks from hitting their mark. The best defense against these attacks is to regulate the data that comes through the openings in security such as user input, a process known as “sanitizing” data. In case that level of security still manages to be broken, it’s prudent to have secondary defenses such as encoding the actual data in your database, so it’s not easily readable without the necessary decoding keys. Fortunately, in many cases of online data breaches, this level of security is employed. However, there are cases like Sony, whose data breach in 2011 revealed thousands of passwords and data stored in easily-readable plain text. When Sony was hacked again in 2014 revealing a plethora of private emails and sensitive internal data, it was clear that they had not learned their lesson. https://www.techdirt.com/articles/20141204/12032329332/shocking-sony-learned-no-password-lessons-after-2011-psn-hack.shtml

The breaches of these large companies should provide important lessons in security, not just to developers of smaller sites, but to everyone with an online presence. You may be a smaller target than a large corporate site, but that doesn’t mean there isn’t someone out there aiming at you.