Oracle SQL Injections Attacks Oracle Database Tips by Donald Burleson

SQL Injection

This is a technique used by hackers to gain access to data for which they are not authorized. We will explain the concept of SQL Injection, how it is done, and how it can be prevented.

One of the biggest problems DBAs face from developers is the passing of a SQL string to the database. Most developers, coming from a client tool background such as Visual Basic, Java, PowerBuilder, etc., are comfortable in passing a string of characters that makes up a query to the database.

For instance, an Active Server Page (ASP) program might use this program to validate the user trying to log into the database. Don't worry about the exact syntax of this program, it not important. The idea is to explain the concept of SQL Injection, not ASP programming.

DIM userName, password, query
DIM conn, rs
userName = Request.Form("userName")
password = Request.Form("password")
set conn = server.createObject("ADODB.Connection")
set rs = server.createObject("ADODB.Recordset")

query = "select * from app_users where userid ='" & userName & "' and userPass='" & password & "'"

conn.Open "Provider=SQLOLEDB; Data Source=CLAIMDB" rs.activeConnection = conn
rs.open query

if not rs.eof then
    response.write "Welcome to Claims Database"
else
    response.write "Invalid Userid or Password"
end if

Essentially, the user supplies a user ID and password, then the program validates them against the database by selecting from the app_users table. We came across the app_users table earlier in the Application Password Management section.

The important part of this script is the line:

query = "select * from app_users where userid ='" & userName & "' and userPass='" & password & "'"

This query is a pass-through query, i.e. it is passed as it is to the database for execution. The variables username and password are taken from the user's input to the form. If the user enters

UserId   : JUDY
Password: 5ucc355

The variable query now becomes:

select * from app_users where userid ='JUDY' and userpass = '5ucc355'

This is passed on to the server and since JUDY exists and her password matches, the program gets a response back, and then it executes successfully and logs in the user.

But, if a hacker enters these values for the same prompts:

UserId      : JUDY
Password: somepass' or '1' = '1

The variable query now becomes:

select * from app_users where userid ='JUDY' and userpass = 'somepass' or '1' = '1'

Executing this query in the database, the output is:

USERID     USERPASS
---------- ------------------------------
JUDY       5uc355
NATHAN     5urf43v3r

The application received some records and concluded that the user JUDY has a password SOMEPASS! The hacker got through without knowing the password. Worse, if the program displays some of the output on the screen, all the users and their passwords will be displayed

This technique is known as SQL Injection, named after the addition of the extra characters 'somepass' or  '1 = 1' after the password. The technique has many variants based on the technology used, but the concept is still the same - placement of a query that will always return true, e.g. 'OR 1=1'.

Another form of SQL Injection is done through the programming practice utilized. Some developers use dynamic SQL to construct the query, instead of using bind variables. For example, consider a procedure that returns claim_details of all claims of a member, the parameter passed is the Social Security Number. The developer may write a query like this in PL/SQL:

l_query := 'select claim_id, claim_amount from claims where SSN = '||l_ssn;

This is then executed by an EXECUTE IMMEDIATE or an elaborate OPEN - FETCH - CLOSE process. The proper SSN is passed to the program. What will happen if, at the prompt for SSN, the user passes the following?

'123456789' union all select claim_id, claim_amount from claims

The value of the l_query variable is transformed to:

select claim_id, claim_amount from claims where SSN = '123456789' union all select claim_id, claim_amount from claims

Note what happens now, the user will get all the claims, not just of the SSN 123456789. This is another variant of SQL Injection.

Steve Friedl has published a great paper on SQL injection attacks.  While his paper show how to attack a SQL Server database, his concepts also apply to Oracle database systems.

Titled "SQL Injection Attacks by Example", the highlights of the paper includes tests to see if the applications SQL is not being "sanitized" properly:

"There have been other papers on SQL injection, including some that are much more detailed, but this one shows the rationale of discovery as much as the process of exploitation.  . .

So the first test in any SQL-ish form is to enter a single quote as part of the data: the intention is to see if they construct an SQL string literally without sanitizing. When submitting the form with a quote in the email address, we get a 500 error (server failure), and this suggests that the "broken" input is actually being parsed literally. . .

This error response is a dead giveaway that user input is not being sanitized properly and that the application is ripe for exploitation. . .

Because the application is not really thinking about the query - merely constructing a string - our use of quotes has turned a single-component WHERE clause into a two-component one, and the 'x'='x' clause is guaranteed to be true no matter what the first clause is  . . .

Friedl then goes on to show some fascinating examples of how to guess the name of tables and the columns with the tables: