Your Guide to SQL Injection (And How to Protect Yourself)

In our always-on, ever-connected 21^st century world, IT teams have to defend themselves against an array of threats. As hackers and security professionals constantly develop new ways of outwitting each other, the effects have been likened to an arms race between the two sides.

However, this fast-paced environment means it's easy to overlook some of the older vulnerabilities that may have become firmly entrenched in our systems. Indeed, one of the most common ways for hackers to gain access to systems would be familiar to their late '90s counterparts: the SQL injection.

But what exactly do these attacks look like, and how can you go about protecting yourself from them? Here, we'll take a closer look at everything you'll need to know about this threat.

What is an SQL injection?

An SQL injection - or SQLi attack - is a web-based code injection attack in which hackers use malicious code to bypass security systems and gain access to SQL databases. Attackers can conduct a wide range of activity if website forms fail to be properly configured, including amending data and even accessing a server's operating system.

This type of attack has been used on web applications for more than 20 years, with the first known incidents occurring in around 1998. However, it’s still used today because many businesses still aren’t taking adequate steps to protect themselves and therefore continue to be vulnerable.

Indeed, according to the 2019 State of the Internet report from Akamai, SQL injection now represents 65.1% of all web application attacks. This was up considerably on the 44% recorded two years earlier.

This is perhaps unsurprising given that SQL is a standard programming language thanks to its ease of use and ubiquity. In StackOverflow's 2020 developer survey, SQL was the third most popular language among all developers worldwide. It was being used by 54.7% of respondents, with only JavaScript and HTML/CSS more common.

How do SQLi attacks work?

As a code injection attack, SQLi works by allowing hackers to enter instructions to the database from a publicly-accessible web form in the form of a valid SQL query. These queries are the building blocks of the language and tell the system what information to look up and retrieve.

For instance, on an ecommerce site, a user's input may be converted into an SQL query that tells the database to return details on a specific item. An SQLi takes advantage of this by changing the instructions sent to the database. For example, on an ecommerce site, a typical user input into a web application when looking for a product may look something like this:

'http://www.ecommercestore.com/items/items.asp?itemid=100'. This is then turned into an SQL query that returns the name and description of the item associated with ID number 100.

But if a user changes this input to read 'http://www.ecommercestore.com/items/items.asp?itemid=100 or 1=1', an unprotected database won’t only return the details of the item with ID 100, but for every entry where 1=1. Since 1=1 will be true for every entry, it will bring up details on every item in the database.

The same principle applies to any field and any input that can be recognized as a valid SQL query. So using the same technique, the user entry 'http://www.ecommercestore.com/items/items.asp?itemid=100; DROP TABLE Users' would instruct the database to delete the entire list of users.

The 3 types of SQL injections

There are three different types of SQL injection, all of which can be used by hackers. These are as follows:

1. In-band SQLi (Classic)

This is where an attacker will use the same channel of communication to both launch their attack and gather the results. It’s a particularly simple and efficient form of attack, which is why it’s the most common.

In-band SQLi attacks can be broken down further into:

• Error-based SQLi - in which an attacker will perform actions to generate an error message. The resulting data can be used to gather information about the database's structure. Sometimes, error-based SQLi can be enough to enumerate an entire database. This is why error messages should be disabled on live sites wherever possible.
• Union-based SQLi - in which attackers will take advantage of the UNION SQL operator. Multiple statements generated by the database can be fused together in order to generate one HTTP response. Within this response may be data that the attacker can use.

2. Inferential SQLi (Blind)

This sees attackers send data payloads to a server in order to use the resulting response to observe how the server may be structured. In this type of attack, the attacker can’t see information about it in-band because data is now transferred from the website database.

Although this sort of SQLi is usually slower, it can be just as devastating for web applications.

Blind SQLi attacks can be broken down further into:

• Boolean - where attackers send an SQL query that prompts an application to make a response that will vary depending on whether the result is true or false. This allows hackers to glean useful inferential data.
• Time-based - where attackers send SQL queries to a database that will make it wait before reacting. They can then use the time taken to work out whether the response was true or false.

3. Out-of-band SQLi

This type of attack can only be carried out when the perpetrator can’t use the same channel to launch the attack, or when it’s too slow or unstable. It must have certain features enabled on the web application's database server in order to be used.

What are hackers looking for?

It's easy to see how simple SQL queries can have a devastating effect on unsecured databases. Depending on the type of SQLi query used, hackers can use it for a wide variety of purposes, from stealing passwords or vandalizing a website to deleting entire databases.

Often, this can be used to directly extract fields from a server, including names, addresses, contact details and more. If it's stored on an SQL database in plaintext, it's potentially vulnerable to injection attacks, including sensitive details such as credit card numbers.

However, an SQLi may also be used as the initial stage of a wider cyber attack. For instance, one of the most common tactics will be to use SQLi to gain access to a list of passwords. Once hackers have these, they can try out the credentials across other systems by impersonating other users - even admin accounts - to burrow deeper into your network.

It could also allow hackers to change, delete or add new information to a database, something that may be particularly worrisome to finance or ecommerce firms. For example, in a financial application, an attacker could use this tactic to alter balances, void transactions or transfer money to their account.

Meanwhile, deleting data can be highly disruptive to a business, which is often the goal of 'hacktivists' motivated by ideological reasons rather than financial ones. Even if you have backups, deleting tables en-masse could shut down applications or websites for hours until the database is restored.

What it can mean for your business

SQL attacks are relatively simple to initiate, but they can cause serious damage to a business. If key servers and databases aren't effectively protected, hackers can gain access to highly confidential material and cause major reputational and financial damage.

Back in 2008, for example, Heartland Payment Systems lost the details of 138 million credit cards through an SQLi. At the time, this was said to be the largest data breach in history, and the company eventually ended up paying out $145 million in compensation for fraudulent payments.

The Heartland case happened over a decade ago, yet the lessons clearly haven't been learned by many businesses as this tactic remains one of the most common ways of accessing data. This was shown in 2015 when British telecoms provider TalkTalk was fined what was at the time a record £400,000 ($486,000) after an SQLi stole the data of 156,959 customers. The regulator was less than impressed with the failing:

However, what’s changed in the last few years is the public awareness and regulatory response to data breaches. People today are much more aware of how valuable their personal data is to hackers, while rules such as GDPR make the financial penalties for incidents much heavier. For example, it's estimated that TalkTalk's fine could have been up to 79 times higher under current rules, possibly costing the firm as much as £59 million ($79 million).

How to protect yourself from SQL injection attacks

Thankfully, there are steps that website owners can take to protect themselves against SQL injection. Although no one solution is foolproof, a combination could be enough to place obstacles in hackers' way to block attacks.

In fact, some are surprisingly simple, so there’s little excuse for failure to prevent at least some vulnerabilities in your code. The best approach is to carefully control and vet user input to watch out for common attack patterns.

Here are some of the solutions you could use to protect your website:

Update and patch

This might sound simple, but vulnerabilities in applications and databases are being discovered all the time, so staying on top of any subsequent patches and updates and applying them as soon as possible is vital.

Remove error messages

As discussed earlier, error messages can unwittingly provide information to hackers, so removing them as far as is practicable is a must. Instead, consider using a 'Remote Only' custom mode so would-be attackers only receive notice of an unhandled error.

Password hashing

It should go without saying, but storing unencrypted passwords is a major security flaw. Applications should only ever store user passwords as strong one-way hashes (preferably salted) to reduce the risk of hackers stealing their credentials.

Web application firewalls

A web application firewall (WAF) can be placed in front of your web server to monitor traffic going in and out and operate using defined customizable web security rules. By informing the WAF of weaknesses and traffic behavior, it can identify patterns that may constitute a threat.

WAFs have the advantage of being quick to add policies to and also protecting against other attacks, including distributed denial of service, session hijacking and cross-site scripting.

Input validation

This basically relies on the idea that all user-submitted data is untrustworthy and allows only input fields that are the correct length, format or style. In doing so, it prevents hackers inserting commands into the input string. For instance, if the expected field is a phone number, don't allow any entry that contains anything other than the figures 0 to 9.

Should a fixed set of values like a drop-down list be required, the returned value can be pre-determined to match one of the offered options. Importantly, input validation should apply to suppliers, sellers and any other parties connected to the website, as they could unwittingly send malformed data should they find themselves under attack.

Parameterized queries

This process ensures the inputs passed into SQL statements - aka the parameters - are treated in a safe way in order to be executed. The database will recognize the code and distinguish it from input data so the intent won’t be altered, helping to prevent SQLi attacks.

Stored procedures

In its most basic form, this is a type of code that can be stored and used again another time. To do so, the developer will group SQL statements into a logical unit for execution. Whenever the query needs to be re-used, the stored procedure can simply be called upon instead of having to be written multiple times. Since the user has no direct access to it, the database remains more secure.

Escaping

Traditional code may be vulnerable to hackers adding an escape character (\) in front of any single quotes. However, by always using character-escaping functions for any user-supplied input provided by each database management system (DBMS), the DBMS never confuses it with the SQL statement the developer provides. This prevents characters that could cause unintended SQL commands being applied by illegitimate users.

Avoiding administrative privileges

This goes back to only providing as much access and information as strictly necessary. If users only need access to certain parts of the website using select statements, create a mode that gives them that, rather than root access that hackers could take advantage of.

Restriction of administrative privileges is even more important if multiple applications and databases are using the database server, as it could prevent attacks on the entire system.

Utilizing as many of the measures above as you can could go some way in ensuring your website is safer.

As we’ve discussed, protecting against SQL attacks is a multi-step process with no simple cure-all solution. However, taking the time to set up comprehensive defenses is vital in ensuring you're safe from this common yet dangerous threat.