What is SQL Injection?
SQL injection is one of the most devastating vulnerabilities that impact a business, as it can lead to exposure of all the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details. It is the vulnerability that results when you give an attacker the ability to influence the Structured Query Language(SQL) queries that an application passes to a back-end database. By being able to influence what is passes to the database, the attacker can leverage the syntax and capabilities of SQL itself, as well as the power and flexibility of supporting database functionality and operating system functionality available to the database.
SQL injection is an attack in which the SQL code is inserted or appended into application/user input parameters that are later passed to a back-end SQL server for parsing and execution. The primary form of SQL injection consists of direct insertion of code into parameters that are concatenated with SQL commands and executed.
A less direct attack injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed. When an attacker is able to modify an SQL statement, the statement will execute with the same rights as the application user; when using the SQL server to execute commands that interact with the operating system, the process will run with the same permissions as the component that executed the command, which is often highly privileged.
SQL is the standard language for accessing Microsoft SQL Server, Oracle, MySQL, Sybase, Informix, and other database servers. Most Web applications need to interact with a database, and most Web application programming languages such as ASP, C#, .NET, Java, and PHP, provide programmatic ways of connecting to a database and interacting with it.
What is SQL Injection used for?
Historically, attackers would compromise a Web site or Web application to score points with other hacker groups, to spread their particular political viewpoints and messages, to show off their “mad skillz”, or simply to retaliate against a perceived slur or injustice. Today, however, an attacker is much more likely to exploit a Web application to gain financially and make a profit.
A wide range of potential groups of attackers are on the Internet today, all with differing motivations. They range from individuals looking simply to compromise systems driven by a passion for technology and a “hacker” mentality, focused criminal organizations seeking potential targets for financial proliferation, and political activists motivated by personal or group beliefs, to disgruntled employees and system administrators abusing their privileges and opportunities for a variety of goals. A SQL injection vulnerability in a Web site or Web application is often all an attacker needs to accomplish his goal.
What is vulnerable to SQL Injection?
SQL injection is not a vulnerability that exclusively affects Web applications; any code that accepts input from an untrusted source and then uses that input to form dynamic SQL statements could be vulnerable.
SQL injection was more typically leveraged against server side databases, however with the current HTML5 specification, an attacker could equally execute JavaScript or any other codes in order to interact with a client side database to steal data. Similarly with mobile applications, malicious applications and/or client-side script can be leveraged in similar ways.
There are many ways to exploit SQL injection vulnerabilities to achieve a myriad of goals; the success of the attack is usually highly dependent on the underlying database and interconnected systems that are under attack.
SQL injection vulnerabilities most commonly occur when the Web application developer does not ensure that values received from a Web form, cookie, input parameter, and so forth are validated before passing them to SQL queries that will be executed on a database server. If an attacker can control the input that is sent to an SQL query and manipulate that input so that the data is interpreted as a code instead of as data, the attacker may be able to execute the code on the back-end database.
It is difficult to correctly and accurately gather data on exactly how many organizations are vulnerable to or have been compromised via an SQL injection vulnerability, as companies in many countries, unlike their US counterparts, are not obliged by law to publicly disclose when they have experienced a serious breach of security. The smallest of breaches, that historically may have gone unnoticed by the wider public, are often heavily publicized today.
How can SQL Injection be prevented?
Don't use dynamic SQL. Even data sanitization routines can be flawed, so use prepared statements, parameterized queries or stored procedures instead whenever possible. But don't forget that while stored procedures prevent some types of SQL injection attacks, they fail to protect against many others, so don't rely exclusively on their use for your security.
Another way to help prevent SQL Injection is to update and patch. Vulnerabilities in applications and databases that hackers can exploit using SQL injection are regularly discovered, so it's vital to apply patches and updates as soon as practical. A patch management solution might be worth the investment.
Consider a web application firewall (WAF), either software or appliance-based, to help filter out malicious data. Good ones will have a comprehensive set of default rules, and make it easy to add new ones whenever necessary. A WAF can be particularly useful to provide some security protection against a new vulnerability before a patch is available. A popular example is the free, open source module ModSecurity, which is available for Apache, Microsoft IIS, and nginx web servers. ModSecurity provides a sophisticated and ever-evolving set of rules to filter potentially dangerous web requests. Its SQL injection defenses can catch most attempts to sneak SQL through web channels.
Also, reduce your attack surface. Get rid of any database functionality that you don't need to prevent a hacker taking advantage of it. For example, the xp_cmdshell extended stored procedure in MS SQL spawns a Windows command shell and passes in a string for execution, which could be very useful indeed for a hacker. The Windows process spawned by xp_cmdshell has the same security privileges as the SQL Server service account.