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.

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.

(source: Trustwave).

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)

83% Root Cause Rate: SQL injection

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

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.

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.

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 usersupplied 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.

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!