Skip to content Skip to navigation Skip to footer

What is Structured Query Language (SQL) Injection

Structured Query Language (SQL) is the standard language used to query a database. (Note that a query performed in a search engine like Google or Bing is different.) 

An SQL injection (SQLi) is a type of attack in which cyber criminals attempt to exploit vulnerabilities in an application's code by inserting an SQL query into regular input or form fields, such as a username or password. The SQL statement is then passed to the application's underlying SQL database. 

SQL injection attacks are successful when the web-based entry form allows user-generated SQL statements to query the database directly. These attacks have also proliferated with the use of shared codebases, such as WordPress plugins, that contain a vulnerability in the underlying code pattern. This vulnerability is carried over to the entire application and can affect hundreds of thousands of websites that all use that shared code.

The damage can be vast. An attacker with a good knowledge of SQL enters queries on a web-based application with no input validation parameters in place, then easily accesses a company's customer files or sensitive financial information.

What Are SQL Queries?

Queries are used to find specific data based on criteria provided by the user. SQL is one of several languages that run the databases for applications, which can be built for internal use by an organization or published on the internet and available to the public. Aside from finding data, SLQ queries can perform calculations, summarize data, and automate tasks.

Types of SQL Injections

In-band SQLi

In-band SQLi is a common type of attack and is known for its simplicity and efficiency. This method has two variations: error-based and union-based. 

Error-based SQLi

Attackers inject SQL queries hoping that the database will return error messages, which can give attackers information about the database and its structure. 

UNION-based SQLi

In this scenario, attackers use the UNION SQL operator for the database to return a single Hypertext Transfer Protocol (HTTP) response. Attackers can then evaluate the response for clues about the contents of a database. 

Inferential (Blind) SQLi

In inferential or blind SQLi attacks, fraudsters query the database and observe the server's behavior to gather information about the database's structure. These types of attacks are slower, but they can be equally harmful as other types of SQLi. There are two types: boolean and time-based. 

Boolean

The attacker queries the database, and by studying whether the HTTP response was modified or stayed the same, they can determine whether the result was true or false. 

Time-based

As its name implies, the attacker studies the response time, in seconds, of a query result. As with the boolean type, the attacker looks closely at the HTTP response to determine whether the query was true or false.

Out-of-band SQLi

This is a special SQLi case that can only work if certain features of the database server used by the application are turned on. Out-of-band SQLi is considered an alternative to in-band and inferential techniques. Out-of-band SQLi does not rely on the attacker querying the database to examine error messages or HTTP responses. Instead, it expects the server to generate Domain Name System (DNS) or HTTP requests so that the attacker can obtain data such as usernames and passwords. 

Examples of SQL Injection

An SQL injection manipulates a standard SQL query to exploit vulnerabilities in the application's underlying database. Let us have a look at a few code examples to see how this works. 

A typical SQL database query for an e-commerce application may look like the following:

SELECT ProductName, ProductDescription
FROM Products
WHERE ProductNumber = ProductNumber

If an attacker wants to access all of the product names and descriptions in the database—even those they are not allowed to access—the attacker will enter a Uniform Resource Locator (URL) similar to this in the on-screen web form: http://www.ecommercesite.com/products/products.asp?productid=999 or 1=1. The corresponding SQL query will be the following: 

SELECT ProductName, ProductDescription
FROM Products
WHERE ProductNumber = 999 OR 1=1

If an attacker wants to delete an entire database, they can take advantage of incorrectly filtered characters, inputting http://www.ecommercesite.com/products/products.asp?productid=999; DROP TABLE to generate the following SQL query:

SELECT ProductName, ProductDescription
FROM Products
WHERE ProductNumber = 999; DROP TABLE USERS

As a result, the entire user database can be dropped or deleted.

How to Prevent SQL Injection

Sanitization

If attackers can input an unexpected query that the application accepts, then it makes sense to limit the input functionality to protect data. Developers can employ input validation, or sanitization, so the application only accepts certain inputs into form fields and reject those that do not conform. Web users are familiar with this practice. An example is when they are prompted to create a password that must be a certain number of characters long and includes at least one special character.

However, this is not an ideal solution because it is difficult to plan for all permissible input combinations. A substantial number of errors will result from users, who can be employees or customers. This can affect business operations significantly. 

Filtering and Validation

To filter out SQLi and block potential threats, enterprises can install a web application firewall (WAF). A WAF matches the inputs to an application against a large list of known signatures to thwart malicious SQL queries. The list is updated and patched regularly so an organization can keep up with the evolving threat landscape.

Limiting the Scope of SQL Commands

Although filtering for SQLi is necessary, blocking 100% of SQL queries is not feasible. Employees, partners, or security industry experts may have to test the application and will need permission to do so. The WAF can cross-verify the input with Internet Protocol (IP) data before blocking the request. 

Avoid Unsecured URL Parameters

If a website does not use Hypertext Transfer Protocol Secure (HTTPS), which leverages secure sockets layer/transport layer security (SSL/TLS) for encryption, an attacker can manipulate the session cookie with SQLi to gain access to the database. Organizations must secure their website and web application URLs to prevent this.

How Fortinet Can Help in SQL Injection (SQLi) Prevention and Mitigation

FortiWeb is the Fortinet WAF solution, which protects organizations from known and zero-day threats to their web applications. As applications continue to be updated with new features and accessed by new users, including through web application programming interfaces (APIs), the attack surface increases. FortiWeb is built to keep up with an organization's applications as they change and evolve.

Machine-learning (ML) capabilities built into FortiWeb allow organizations to customize the protection for each application. Further, ML can identify and distinguish between benign and malicious anomalies to reduce business disruption resulting from false positives.

FAQs

What is SQL injection?

A Structured Query Language injection (SQLi) is a type of attack in which attackers attempt to exploit vulnerabilities in an application's code by inserting an SQL query into regular input or form fields, such as a username or password. The SQL statement is then passed to the application's underlying SQL database.

Why do hackers use SQL injection?

Hackers use SQL injection to gain unauthorized access to data—or information about that data—stored in a web application's database.

Is SQL injection illegal?

For the most part, SQL injection is illegal, although this depends on jurisdictional boundaries.

Does SQL injection still work?

Yes, SQL injection is still very much a cybersecurity threat, especially for older applications that have not been updated.

Can SQL injection be traced?

An organization can use IP data to detect where the query was originally input, but the identity of the attacker cannot be confirmed by simply examining the SQL injection query alone.