SQL Injection and Oracle

SQL injection techniques are an increasingly dangerous threat to the
security of information stored upon Oracle Databases. These techniques
are being discussed with greater regularity on security mailing lists,
forums, and at conferences. There have been many good papers written
about SQL Injection and a few about the security of Oracle databases
and software but not many that focus on SQL injection and Oracle
software. This is the first article in a two-part series that will
examine SQL injection attacks against Oracle databases. The objective
of this series is to introduce Oracle users to some of the dangers of
SQL injection and to suggest some simple ways of protecting against
these types of attack.

Oracle is a huge product and SQL injection can be applied to many of
its modules, languages and APIs, so this paper is intended to be an
overview or introduction to the subject. This two-part series is not
intended as a detailed treatise of how to SQL inject an Oracle
database, nor is it intended as a detailed discussion on the finer
points of the technique in general. (Details of SQL injection
techniques have been covered admirably in the past for other languages
and databases, particularly by Rain Forest Puppy who pioneered the
subject. Some of these papers are included in the reference section at
the end of this paper.) Rather, I have designed this paper so that as
many readers as possible can try out the examples. To achieve this I
have used a PL/SQL procedure that uses dynamic SQL to demonstrate the
techniques of SQL injection from the ubiquitous SQL*Plus.

What is SQL Injection

SQL Injection is a way to attack the data in a database through a
firewall protecting it. It is a method by which the parameters of a
Web-based application are modified in order to change the SQL
statements that are passed to a database to return data. For example,
by adding a single quote (‘) to the parameters, it is possible to cause
a second query to be executed with the first.

An attack against a database using SQL Injection could be motivated by two primary objectives:

1. To steal data from a database from which the data should not normally
   be available, or to obtain system configuration data that would allow
   an attack profile to be built. One example of the latter would be
   obtaining all of the database password hashes so that passwords can be
   brute-forced.
2. 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.

There are many ways to use this technique on an Oracle
system. This depends upon the language used or the API. The following
are some languages, APIs and tools that can access an Oracle database
and be part of a Web-based application.

• JSP
• ASP
• XML, XSL and XSQL
• Javascript
• VB, MFC, and other ODBC-based tools and APIs
• Portal, the older WebDB, and other Oracle Web-based applications and API’s
• Reports, discoverer, Oracle Applications
• 3- and 4GL-based languages such as C, OCI, Pro*C, and COBOL
• Perl and CGI scripts that access Oracle databases
• many more.

Any of the above applications, tools, and products could be used as a
base from which to SQL inject an Oracle database. A few simple
preconditions need to be in place first though. First and foremost
amongst these is that dynamic SQL must be used in the application,
tool, or product, otherwise SQL Injection is not possible.

The final important point not usually mentioned in discussions about
SQL injection against any database including Oracle is that SQL
injection is not just a Web-based problem. As is implied in the
preceding paragraph, any application that allows a user to enter data
that may eventually end up being executed as a piece of dynamic SQL can
potentially be SQL injected. Of course, Web-based applications present
the greatest risk, as anyone with a browser and an Internet connection
can potentially access data they should not.

While second article of this series will include a much more in-depth
discussion of how to protect against SQL injection attacks, there are a
couple of brief notes that should be mentioned in this introductory
section. Data held in Oracle databases should be protected from
employees and others who have network access to applications that
maintain that data. Those employees could be malicious or may simply
want to read data they are not authorized to read. Readers should keep
in mind that most threats to data held within databases come from
authorized users.

Protecting against SQL Injection on Oracle-based systems is simple in principle and includes two basic stages. These are:

1. Audit the application code and change or remove the problems that
   allow injection to take place. (These problems will be discussed at
   greater length in the second part of this series.)
2. Enforce the principle of least privilege at the database
   level so that even if someone is able to SQL inject an application to
   steal data, they cannot see anymore data than the designer intended
   through any normal application interface.

The “Protection” section, which will be included in the
second part of this series, will discuss details of how to apply some
of these ideas specifically to Oracle-based applications.

How Can Oracle be Abused

Oracle is like any other database product and, as a result, is
vulnerable to SQL injection attacks. While Oracle fairs slightly better
than some of the others, the following abuses can be inflicted on an
Oracle database:

• UNIONS can be added to an existing statement to execute a second statement;
• SUBSELECTS can be added to existing statements;
• Existing SQL can be short-circuited to bring back all data. This
  technique is often used to gain access via third party-implemented
  authentication schemes;
• A large selection of installed packages and procedures are available, these include packages to read and write O/S files;
• Data Definition Language (DDL) can be injected if DDL is used in a dynamic SQL string;
• INSERTS, UPDATES and DELETES can also be injected; and,
• Other databases can be injected through the first by using database links.

On the other hand, the following abuses are not possible:

• Multiple statements are not allowed; and,
• It is also not possible to SQL inject a call that uses bind
  variables; this is therefore a good solution to most of the SQL
  injection issues.