SQLi Facts

#1 Web Application Risk: SQL Injection was the leading Web application risk of 2011. It ranks as one of the most common software vulnerabilities in survey after survey.
(source: Trustwave).

SQL Injection
SQL Injection, or SQLi for short, is a type of web application security vulnerability that exploits the database layer through rogue code injection techniques.

71 Attacks Every Hour: Web applications are attacked using SQL injection an average of 71 times every hour. (source: Imperva) Dominant Source of Attack: 97 percent of data breaches worldwide are due to SQL injection.
(source: National Fraud Authority UK)

SQL Injection attacks can occur when a web application utilizes user-supplied data without proper validation or encoding as part of a command or query. This leaves an opening for potential hacks or attacks as specially crafted user data can trick the application into executing unintended commands or changing data. These commands are then sent to the database server where they are executed. SQLi attacks are easily preventable, yet most companies dont take precautions, subjecting themselves to potentially damaging data breaches and their consequences.

83% Root Cause Rate: SQL injection has been responsible for 83% of all successful hacking-related data breaches, from 2005-2011.
(source: Privacyrights.org)

How Attackers Exploit SQLi Vulnerabilities

SQLi flaws in software code leave a web application open to hacks and attacks. As one of the most common security vulnerabilities found in software, SQLi flaws are often the common entry point for any number of malicious schemes. Heres how SQLi attacks generally work: - SQLi hacks take advantage of an unprotected applications acceptance of user supplied data without proper validation or encoding controls. - In one common scenario, a hacker hijacks the applications unprotected login fields to gain unauthorized access to its backend database. - An attacker may also exploit SQLi by submitting a bogus SQL command to the database, confusing the SQL interpreter with specially crafted input data. - The SQL interpreter is not able to distinguish between intended commands and code injected by the attacker, which is then executed, exposing the database. - The attacker can then trick the application into extracting all data records or hosting a malicious script, among other aims. In summary, SQL Injection allows an unauthorized third-party to create, read, update, alter or delete data accessed via the unprotected application.

An Infamous History: Major reported breaches caused by SQL injection: Card Systems Solutions (2005, 40M credit cards compromised), TJX (2006, 94M cards), Heartland Payment Systems (2008, 134M cards), RockYou (2009, 32M users), Sony (2011, 77M users). Automation Infects 100,000s: In 2008, SQLi attacks become automated via the use of botnets. Mass website infection incidents include 500,000 reported in 2008, 210,000 in 2009, 500,000 in 2010, and 380,000 in 2011.

How to Fix & Prevent SQL Injection Flaws

It is very simple to avoid SQL Injection vulnerabilities in your code. These five fixes either avoid the use of dynamic SQL queries entirely or prevent user-supplied input from affecting query logic. They can be used with practically any kind of programming language and any type of database.

Additional Resources:
Veracode resources on SQLi include: SQL Injection Tutorial (video) Anatomy of the Sony PlayStation Network breach (infographic) Data Mining a Mountain of Zero Day Vulnerabilities (webinar) Verizon Data Breach Investigative Report 2012 highlights (blog) Safe Coding and Software Security (infographic)

1. Use prepared statements (aka parameterized queries). Simpler to write and easier to understand than dynamic queries, parameterized queries pass in each parameter to the query layer only after all SQL code has been defined. The database can distinguish between code and data, regardless of user input. An attacker isnt able to change the intent of a query, even if SQL commands are inserted. 2. Perform Input Validation. Authenticate user input against a set of defined rules for length, type and syntax as well as against business rules as an additional query filter. 3. Escape all user supplied input, before putting it in a query. This is a cost-effective way to retrofit legacy code and avoid performance issues, but an inferior approach when writing new apps. Every DBMS supports one or more character escaping schemes specific to certain kinds of queries, so use them. The DBMS will not confuse user input with SQL code written by the developer, thus avoiding any possible SQLi. 4. Enforce least privilege. Minimize the privileges assigned to database accounts in your environment. Start with no access rights and then determine case-by-case what each requires. Some users will be fine with read-only access or limited views of the data. Restrict an accounts ability to execute stored procedures. Create specific accounts application by application. Rarely, if ever, grant the ability to create or delete access to database accounts. Minimize privileges granted to the application itself, to reduce the likelihood of unauthorized access. 5. Use stored procedures. This fix stores all SQL code in the database itself, then calls it from the application. SQL code is defined first, and then parameters are passed after. Avoid generating dynamic SQL inside stored procedures. If this cant be avoided, then validate or properly escape all user supplied input to the dynamic query before its constructed. Remove any and all stored procedures that are not in use.
For more details, consult the source: Open Web Application Security Project

Flawed Code Examples

Java example: unvalidated customerName parameter (source: OWASP)
String query = "SELECT account_balance FROM user_data WHERE user_name = " + request.getParameter("customerName"); try { Statement statement = connection.createStatement( ); ResultSet results = statement.executeQuery( query ); }

SQL example: entering 0=0 as inputs will return all database records (source: Veracode)
String SQLQuery ="SELECT Username, Password FROM users WHERE Username=" + Username +" AND Password=" + Password =""; Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(SQLQuery); while (rs.next()) { }
www.veracode.com 2012 Veracode, Inc. All rights reserved.

How Veracode Can Help

Veracodes Platform analyzes an applications control and data flow the way an attacker sees it. Veracodes testing approach accurately detects SQLi and other security flaws found in vendor supplied and internally developed code. Veracode also provides eLearning courses that train your developers to avoid this common vulnerability. Sign up for a Free Trial today!