Oracle SQL Injection Attacks Oracle Database Tips by Donald Burleson

Update - For a complete treatment of the topic of Oracle security on the web, see these books and resources:

• 2007 trends in Oracle web security management
   

• Oracle Forensics, by Paul M. Wright, Rampant TechPress
   

• Oracle Privacy Security Auditing, By Arup Nanda, and Donald K. Burleson, Rampant TechPress

---

Oracle has made huge efforts to plug vulnerabilities against SQL injection attacks, but many web databases remain vulnerable to SQL injection hacking.

Now we are seeming a rash of online how-to guides for using SQL Injection techniques to penetrate private databases. 

This scary must-see video that shows a real-world SQL injection attack and it's frightening how fast they can break into a allegedly secure database.  It's even more frightening that someone would publish step-by-step instructions where the criminals can see them.

This video shows a SQL Injection attack in Linux, "based on a true story", giving criminals complete directions to aid them in their acts.

Great.  Now any script kiddie can get step-by-step instructions for hacking into a database.

Should this be illegal?

The US has felony laws prohibiting aiding and abetting criminal activities, but it is not clear whether these laws extend to aiding cyber criminals, computer fraud, and computer forgery.

Do hacker how-to guides constitute aiding and abetting a criminal?

SQL injection techniques remain a major threat to many web-based systems and it is not always the database vendors fault.  Improve page design can also precipitate these types on SQL injection hacking attacks.

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.

This is an excerpt from the book "Oracle Privacy Security Auditing". You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle security and auditing scripts.