14-11-2012, 01:57 PM
Analysis of SQL injection prevention using a filtering proxy server
David Rowe - Literature Survey.pdf (Size: 95.77 KB / Downloads: 24)
Abstract
SQL injection is a method by which users take advantage of dynamic SQL through
which parameters of a web-based application are chained together to create the query
to the backend database. There are many measures that can be taken to prevent SQL
injection including making sure that the users have the minimum database privileges
possible, using input validation programming techniques, suppressing error messages
returned to the client, checking error logs and filtering malicious SQL statements. In
research and commercial products, there is evidence proving that SQL injection can
be prevented using means not so closely related to the database and web application.
These methods of approach have been developed to produce a more generic solution
to a problem that requires a lot of tweaking and attention to detail at the root of the
problem - the application code and database deployment. Auditing all of the source
code and protecting dynamic input is not trivial, neither is reducing the permissions of
all applications users in the database itself. After reviewing a variety of literature
sources, developing a filter seems to be the best solution to preventing SQL injection.
INTRODUCTION
Structured Query Language (SQL) is a textual relational database language. Its
command set has a basic vocabulary of less than 100 words. There are many varieties
of SQL; however, the differences among the various dialects are minor. SQL
functions fit into two categories:
· Data definition language (DDL): used to create tables and define access rights
and
· Data manipulation language (DML): SQL commands that allow one to insert,
update, delete, and retrieve data within database tables (Anley C, 2002) (Rob
and Coronel, 2002).
The typical unit of execution of SQL is the query, which is a collection of statements
that typically return a single result set (Anley C, 2002).
SQL injection is a way to attack a database through a firewall by taking advantage of
non-validated SQL vulnerabilities. It is a method by which the parameters of a Webbased
application are modified in order to change the SQL statements that are passed
to a backend database. An attacker is able to insert a series of SQL statements into a
query by manipulating the data input, for example, by adding a single quote (‘) to the
parameters. It is possible to cause a second query to be executed with the first.
Programmers often chain together SQL commands with user-provided parameters,
and can therefore embed SQL commands inside these parameters. This is known as
dynamic SQL. It must be noted that dynamic SQL must be used in the application or
SQL injection is not possible. SQL injection has been described as a “code hole” that
is as serious as any IIS hole (Anley C, 2002) (Finnigan, 2002a) (Imperva Inc., 2004b)
(Overstreet, 2004).
1.1 Why this research is important
Although the date of its discovery is uncertain, SQL injection is not a new problem. In
the last few years, SQL injection attacks have been on the rise (Maor and Shulman,
2003). There is data showing that injection flaws have been sixth in the top ten
INTRODUCTION
vulnerabilities for the past two years. Previous research shows that 62% of web
applications are vulnerable to SQL injection attacks (OWASP, 2004) (WebCohort
Inc., 2004). At least 92% of web applications are vulnerable to some form of hacker
attacks (WebCohort Inc., 2004).
The following are some languages, APIs and tools that can access databases and be
part of a Web-based application.
· JSP
· ASP
· XML, XSL and XSQL
· JavaScript
· VB, MFC, and other ODBC-based tools and APIs
· 3- and 4GL-based languages such as C, OCI, Pro*C, and COBOL
· Perl and CGI scripts (Anley C, 2002) (Finnigan, 2002a) (Imperva Inc., 2004b)
(Litchfield D, 2001) (Overstreet, 2004).
An attack against a database using SQL Injection could be motivated by three primary
objectives:
1. To steal data from a database from which the data should not normally be
available,
2. To obtain system configuration data that would allow an attack profile to be
built. One example of this would be obtaining all of the database password
hashes so that passwords can be brute-forced.
3. To gain access to an organisation’s host computers via the machine hosting the
database. This can be done using package procedures and 3GL language
extensions that allow O/S access (Finnigan, 2002a).
Current situation
According to Huang, Huang, Lin, and Tsai (2003), many Web applications go through
rapid development phases with extremely short turnaround time, making it difficult to
eliminate security vulnerabilities such as SQL injection and cross-site scripting.
Kc, Keromytis, and Prevelakis (2003) provide evidence that there has been a lot of
development and research in the area of how to detect and test sites for SQL injection.
A few good papers will form the foundation of analysis of the problem domain.
Microsoft (2003a) offers the following tips for preventing SQL injection:
1. Validate all user input before transmitting it to the server.
2. Permit only minimally privileged accounts to send user input to the server.
3. Run SQL Server itself with the least necessary privileges.
The presentation by Hotchkies (2004) at a Black Hat USA 2004 convention outlines
automated blind SQL injection techniques. He mentions that string comparison is
suitable for error based SQL injection but not blind SQL injection.
Microsoft (2003b) provides a good background into the problem of SQL injection. It
puts the whole problem into context. The site provides explanations of the
components of SQL injection strings and the syntax choices. The examples include
SQL injection attacks, creating a secure data access component using Java’s regular
expressions.
Beyond Security Ltd. (2002) provides concise examples of SQL injection and
database error messages as well as methods on how to prevent SQL injection.