Anatomy of SQL injection attack

While there are a number of security risks in the world of electronic commerce, SQL injection is one of the most common Web site attack techniques used to steal customer data such as credit card numbers, hold customer data hostage by encrypting it or destroy data outright.

Where a Web server only understands and speaks the HTTP protocol, a database’s native tongue is Structured Query Language (SQL), which is essentially a set of command statements that instruct a database to execute specific actions. Every database server has a similar series of commands to query its tables, narrow down results to a few specific entries, and combine information from one table to another.

Here is an example SQL query:

SELECT * FROM users WHERE Email = '" + Email + "' AND Password = '" + Password + "';

The WHERE specifies a condition, that an e-mail address and password combination match data present in the “users” table. When this command is given to the database server, it returns true if a match is found and a false if there is no match.

When clients send data on the Web, they use URLs and forms to assemble the database query statements. The following URL represents an example login page for a Web application:

GET /shopping_cart/login.asp?Email=jdoe@example.com&Password=$ecret123 HTTP/1.1

This URL shows that the destination application is a Microsoft ASP page and it is accepting two parameters, one called “Email” and the other called “Password.” If the user credentials are correct then the result of this query will provide response data that represents a successful authentication and will be used to allow the client to proceed to the corresponding Web page.

Developers of traditional application code generally trust user input. They believe that database queries are coming from a trusted source, namely the database server itself, rather than from an untrusted user’s Web browser. SQL injection is an attack technique where an untrusted user inserts SQL query data into input fields sent to back-end databases in an attempt to trick the database into executing the commands. (See infographic.)

Real multistep SQL-injection attack

The Web application firewall in the example was configured in a “detection only” mode where it was logging alerts and events but not blocking any inbound attacks or outbound data leakages. Due to this configuration, the inbound SQL injection attack from the previous section was allowed to continue on to the vulnerable Web application when it would have been blocked.

The Web page returned indicates that the SQL injection reconnaissance probe was successful (see infographic), giving the hacker valuable information, including the exact version of the database and the database user. Armed with this information, the attacker can fine tune the attack and execute further reconnaissance probes to enumerate more information about the database itself, such as the table and column names. After a number of intermediary reconnaissance probes, the attacker has the information needed to send a complex SQL injection attack, attempting to extract customer record details. By targeting specific customer data such as credit card name, expiration data and security code, the attacker can extract a vast amount of sensitive customer data.

Real multistep SQL-injection attack

Criminals once had a tough time creating programs that could mass exploit Web applications because most sites were running custom coded applications. But in early 2007 the game changed with the emergence of mass SQL injection bots. These programs used a complex SQL script to generically inject data into any vulnerable sites without prior knowledge of the database structure. They accomplish this by using multiple SQL commands to create a script that utilizes database features to gather and then loop through table names and append malicious JavaScript that points to malware on a third-party site. The injected JavaScript is dynamically used within the HTML page that is presented to clients and attempts to exploit various Web browser vulnerabilities to install back-door or Trojan software.

The Open Web Application Security Project (OWASP) Top 10 list includes excellent guidance for mitigating injection type attacks including:

* Input validation: Use a standard input-validation mechanism to validate all input data for length, type, syntax and business rules before accepting the data to be displayed or stored; use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data.

* Database configuration: Use strongly typed parameterized query APIs with place-holder substitution markers, even when calling stored procedures; enforce least privilege when connecting to databases and other back-end systems; show care when using stored procedures since they are generally safe from SQL injection, but be careful as they can be injectable via the use of exec() or concatenating arguments within the stored procedure; do not use dynamic query interfaces such as mysql_query() or similar.

* Avoid detailed error messages that are useful to an attacker.

SQL injection is the most widely used attack vector for profession cyberthieves, but defense-in-depth security measures such as proper database configuration, secure coding within the Web application and deployment of a Web application firewall are extremely effective mitigation strategies.

Barnett is director of application security at Breach Security (www.breach.com).

Insider Shootout: Best security tools for small business
Join the discussion
Be the first to comment on this article. Our Commenting Policies