Understanding and Preventing SQL Injection (SQLi), One of the Most Common Attack Vectors

Daniel Deter is the Manager of Information Security at Green House Data. Follow him on LinkedIn.

Your data is your business. Your databases, and the data-driven applications that leverage them, should be regularly audited for vulnerabilities. One of the top risks facing your data today is SQL injection (SQLi). According to the 2018 Verizon Data Breach Incident Report (DBIR), SQLi was the second most common hacking variety within information breaches, exceeded only by stolen credentials.

This attack vector involves the exploit of programmatic weaknesses in applications to run unintended code to manipulate your backend SQL databases, and thus access information or even gain administrative access and credentials. 

Any application that uses SQL could be subject to this type of attack, from simple websites to SaaS apps like your CRM and ERP — even VoIP systems. This attack is also not limited to applications exposed to the internet. Internal applications are prime targets for attackers who have breached your external boundary (e.g., through phishing — according to the PhishLabs 2018 Phishing Trends & Intelligence report, phishing continues to be the top threat vector for cyberattacks.)
 

What leads to SQL Injection attacks?

SQL databases may contain a wide variety of sensitive data, such as personally identifiable information (PII), confidential company data, and customer details. Many databases also include sensitive personal information (SPI).  A successful SQL injection attack could be used for destruction of data, theft of sensitive or valuable data, or even to gain administrative access to other systems. The result of a compromise of sensitive data can include brand damage, regulatory fines, and loss of client confidence.

SQL is a language used to build and edit databases. Queries are submitted to the SQL database for any desired command, like pulling a specific record  list, changing records, or the deletion of records. If a malicious person wishes to attempt an SQL injection, they submit a specifically crafted SQL query into an application input box to try and take advantage of unvalidated input vulnerabilities. Often this involves appending a simple piece of logic or a typical command to the end of a valid SQL query, with the desired result of returning more information than the query would normally return, or of adding an additional command to delete a table.

SQL injection vulnerabilities stem from failures to include security in the development process and persist due to a lack of basic security practices like vulnerability scanning, and even penetration testing. As mentioned above, the injection tries to exploit non-validated inputs. Validation and sanitization involve writing application code in a way that ensures refusal of illegitimate or otherwise unexpected queries.

Preventing SQL Attacks

The easiest way to prevent SQL attacks is to avoid the use of dynamic queries in your app or disallowing user supplied input containing malicious SQL (validation).

Validation is great to stop commonly used attack queries, but it probably won’t stop all of them. Even if you did have a lengthy list of queries to refuse, it’s possible that some of them could be legitimately used by your users or applications, hampering business functionality.

During the application development process, and then routinely during production service, organizations should perform dynamic application security testing (DAST), and static application security testing (SAST) against the web application. DAST tests the application, while SAST tests code.

Web application firewalls can refuse injection attempts by comparing them to a long, verified list of malicious inputs. They can also cross-reference queries against IP addresses and blacklist known malicious actors.

Follow the Open Web Application Security Project’s best practices for SQL Injection prevention. Simply adhering to them, while regularly patching and applying updates and using a firewall/vulnerability tool, can go far enough to deter attackers from your database and turn them towards easier prey.

SQL injection attacks remain one of the most common attack vectors, which is surprising mostly because spending some extra time and a little money on security tools is enough to stop the majority of them. If you use a third-party developer for any web-facing application or website, be sure to audit before going into production. If you develop and deploy internally, use OWASP best practices. Don’t suffer the PR and legal consequences of a data breach due to such a common and easily preventable hack.