The Unexpected Way To Protect Yourself from SQL Injection Attacks

The Unexpected Way To Protect Yourself from SQL Injection Attacks

Your website is there to serve your customers and prospects. It is your virtual storefront to the world, and it is open 24/7/365. All of those web forms, database powered features and interactive capabilities carry a risk. Your website may be vulnerable to SQL attacks — a particularly powerful hacking technique. The first step is to clarify how these SQL attacks work.

What Are SQL Attacks Anyway?

In technical circles, this type of attack is called a SQL injection. SQL — sequential query language — is a popular programming format used to extract, change and use data in databases. In a SQL injection attack, a hacker finds a database powered application and attempts to gain unauthorized access. For example, a data entry field for customers to provide comments on their order might be used for a SQL injection attack. Hackers may target WordPress vulnerabilities and leverage that access to go deeper into your systems. Depending on the vulnerability, a SQL injection attack can be used to gain data, break into other systems or disrupt systems.

How Do SQL Attacks Compare To Other Hacking Risks?

According to the 2018 Trustwave Global Security Report, SQL Injection (SQLi) was involved in 1 of every 5 hacking events reported in 2017. The objective of these attacks vary, but payment card data remains one of the most popular information assets to target.

How bad is the damage resulting from SQL injection attacks? Let’s take a look at a few of the significant incidents organizations have suffered in recent years.

  • Over 100 million credit card files exposed. In 2008, Heartland Payment Systems, a payment processing company, suffered a loss of credit card data from a SQL injection attack. While there was a criminal conviction in the case, the company paid out over $100 million in compensation due to hacking-related fraud. Spending a small fraction of that amount on prevention probably would have reduced the breach’s impact dramatically.
  • 150,000 people impacted by the TalkTalk breach. Despite the Heartland Payment Systems problem, SQL injection hacks were not eliminated. In 2015, UK telecom company TalkTalk disclosed that payment card (debit and credit) information for more than 150,000 customers was lost to a hack. In the short term, the hack hurt the company’s share price. Who knows how many customers left the company for good?
  • U.S. government websites suffer SQL attacks. Despite the vast security resources at their disposal, the FBI suffered a SQL injection attack in 2013. The attackers obtained confidential information on government employees, including banking details. According to DarkReading.com: “the group of attackers gained access to government systems via SQL injection attacks, as well as by exploiting vulnerabilities in outdated versions of the website development platform Adobe ColdFusion.”

 

While public reports of successful SQL injection attacks are declining, we suspect it remains a significant vulnerability for many companies. After all, databases power much of the modern web, including e-commerce, financial databases, payment systems and more. How do you know if this vulnerability should keep you up at night?

Signs That You Are Vulnerable to SQL Attacks

While a full scope review is beyond the scope of this article, there are a few red flags to consider in assessing your SQL hacking vulnerability.

  • Patch Management Discipline. If your organization is slow in identifying new patches and installing them, you are missing one of the best ways to become hacker resistant. To improve this discipline, identify your most sensitive systems and set a schedule (weekly or monthly) to seek out updates and start the process of putting them into action.
  • No SQL Injection Testing. Like patch management, SQL injection testing is not a new idea. However, if you do not practice this discipline, you will be vulnerable. Fortunately, there are public resources that show how to do testing. Check Exploiting SQL Injection: a Hands-on Example for illustration of how SQL injections can be tested.
  • No Industry Monitoring. Assuming your company is unique when it comes to security is misleading. You probably use the same database software, web applications, and cloud services as many others in your industry. If you do not have a process to monitor industry news, such as learning from 2017 Equifax breach, you are more likely to suffer a SQL attack.

 

What if you have already fully implemented the above strategies to implement hacker resistant SQL? Does that mean your job is done? Not quite. You need to look at the broader environment where SQL attacks may occur.

To assess your developers and their ability to prevent SQL injection attacks, review the following points:

  • Industry awareness. What examples do your developers know about in the news? Without that baseline awareness, they are unlikely to take action.
  • Development practices. Do your developers have the tools and training to build secure SQL from day one?
  • Tools and training. Are your developers equipped with testing and tools needed to identify vulnerabilities?

 

How Do Containers Reduce SQL Injection Vulnerability

Here’s the harsh reality: you may not be able to detect and prevent every hacking attack on your enterprise. Why? The sheer volume of vulnerabilities is difficult to manage. According to Wordfence, SQL injections are the second most common WordPress vulnerability after cross-site scripting. What happens if an enterprising hacker breaks into your organization through a WordPress vulnerability?

You need a way to slow their advance and limit the damage so your security team has time to respond. If the hacker can jump from system to system quickly, they may walk away with payment card data in minutes. You can use containers to reduce the risk. For example, streamline the operating system you deploy so that it has only the minimum required features to get the job done. Also, fully implementing the security guidance from Docker is a good step as well.

There’s just one major problem with adding layer after layer of security monitoring and testing. You start to lose the productivity benefits of containers. How else can you improve container security? Hint: you do not have to overhaul all of your databases. You also don’t have to send your whole team to SQL security training either.

The answer: step up your identity management game. By installing Avatier’s Identity Anywhere, you can bring identity management oversight to your containers. You do not have to worry about gaps in your identity management anymore.

Written by Nelson Cicchitto