What Is SQL Injection?

SQL injection is a web application vulnerability that occurs when untrusted user input is incorporated into a database query in an unsafe way. It can allow an attacker to manipulate database queries and potentially access, modify or delete data they should not be able to access.

SQL injection has been a long-standing web application security risk and remains important because many applications still rely on databases to store sensitive information.

How Does SQL Injection Work?

Web applications commonly use databases to store information such as:

• Customer accounts
• Usernames and passwords
• Orders and invoices
• Personal information
• Business records
• Application configuration

When a user interacts with an application, their input may be used to construct a database query.

For example, a login form might submit a username and password which the application uses to look up a matching account.

The security problem occurs when the application treats user input as part of the SQL command itself rather than safely handling it as data.

An attacker may then be able to manipulate the query's intended behaviour.

A Simple Example

Imagine an application receiving a product identifier from a user:

/product?id=123

The application might use the supplied value to retrieve a product from its database.

If the application builds its SQL query unsafely, an attacker may be able to manipulate the id parameter and alter the resulting database query.

The exact techniques vary depending on the database, application framework and type of SQL injection, but the underlying problem is the same:

Untrusted input is being interpreted as part of a database command.

A secure application should ensure that user-supplied data cannot change the intended structure of the query.

What Can an Attacker Do With SQL Injection?

The impact depends heavily on the application's design, database permissions and the vulnerability itself.

Potential consequences can include:

• Reading sensitive database information
• Accessing other users' records
• Bypassing application functionality
• Modifying stored information
• Deleting database records
• Extracting credentials or other sensitive data
• Compromising application functionality
• Potentially gaining further access to the underlying system in certain circumstances

A particularly serious SQL injection vulnerability could therefore result in a significant data breach.

Where Can SQL Injection Occur?

SQL injection is not limited to login forms.

Potential injection points can include:

• Search fields
• Login forms
• URL parameters
• API requests
• HTTP headers
• Cookies
• Filtering and sorting functions
• Form submissions
• Reporting functionality

Essentially, any application functionality that passes user-controlled input to a database query should be designed and tested carefully.

Different Types of SQL Injection

SQL injection can occur in several different ways.

In-Band SQL Injection

This is where the attacker can manipulate a query and receive the resulting information directly through the application's response.

It can sometimes be relatively straightforward to identify because the application's response provides useful feedback.

Blind SQL Injection

With blind SQL injection, the application does not directly display the database results.

Instead, an attacker may infer information from differences in the application's responses, behaviour or timing.

This can make testing more complex.

Error-Based SQL Injection

In some cases, database errors generated by manipulated input can reveal useful information about the underlying query or database.

Detailed database errors can therefore increase the information available to an attacker.

Second-Order SQL Injection

This occurs when malicious input is initially stored by the application and only later incorporated into a database query in an unsafe manner.

This can be more difficult to identify because the vulnerable behaviour may occur some time after the original input was submitted.

How Can Organisations Prevent SQL Injection?

The most important defence against SQL injection is to ensure that user input cannot alter the structure of database queries.

Developers should generally use parameterised queries or prepared statements rather than constructing SQL statements by concatenating user input.

Other useful security measures include:

• Use parameterised queries
• Use well-designed ORM/database abstraction features correctly
• Validate input where appropriate
• Apply least-privilege permissions to database accounts
• Avoid exposing detailed database errors to users
• Keep application frameworks and database software patched
• Monitor application and database activity
• Perform regular security testing

Input validation is useful, but it should not be treated as the primary defence against SQL injection.

A value that appears harmless may still behave unexpectedly in a different context. The application should therefore separate data from executable SQL commands.

What About ORMs?

Many modern applications use an Object-Relational Mapper (ORM) such as Entity Framework, Hibernate or Doctrine.

Using an ORM can reduce the risk of SQL injection when it is used correctly because it can handle database queries through safer abstractions.

However, an ORM does not automatically make an application immune to SQL injection.

Developers can still introduce vulnerabilities by constructing raw SQL queries or using unsafe query functionality.

The security of the application ultimately depends on how the database interaction is implemented.

Can Automated Vulnerability Scanners Find SQL Injection?

Automated vulnerability scanners can be very useful for identifying potential SQL injection vulnerabilities.

They can test large numbers of parameters and endpoints far more quickly than a human tester could manually.

However, automated testing has limitations.

Modern applications can contain complex authentication requirements, business logic, APIs and custom functionality that may make certain injection points difficult to identify or accurately assess automatically.

A scanner may also identify a potential issue that requires manual validation to determine whether it is genuinely exploitable and what its real impact could be.

SQL Injection and Web Application Penetration Testing

A web application penetration test can combine automated testing with manual techniques to assess SQL injection more comprehensively.

A penetration tester can investigate how an application's inputs are processed, identify unusual behaviour and determine whether database queries can be influenced by user-controlled data.

Testing can also consider authenticated functionality and areas of the application that automated scanners may not fully understand.

This is particularly valuable for applications that process sensitive information or provide access to important business systems.

Why SQL Injection Still Matters

SQL injection is a well-known vulnerability, which means developers and security teams might assume that modern applications have eliminated the problem.

However, vulnerabilities can still be introduced through:

• Legacy code
• Custom database queries
• Poorly implemented APIs
• Development shortcuts
• Unsafe use of framework functionality
• Third-party components
• Changes to existing applications

Security testing therefore remains important even where an application uses modern frameworks and development practices.

Conclusion

SQL injection occurs when an application allows untrusted input to influence the structure of a database query.

Depending on the circumstances, this can allow attackers to access, modify or delete sensitive information and potentially compromise other parts of the application.

Using parameterised queries, appropriate database permissions and secure development practices can significantly reduce the risk.

Regular web application penetration testing can provide an additional layer of assurance by testing whether those protections have actually been implemented correctly and whether unexpected paths to the database remain accessible.