Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Oracle SQL Injections Attacks

Oracle Database Tips by Donald Burleson

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

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 query

if not rs.eof then
    response.write "Welcome to Claims Database"
    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:

---------- ------------------------------
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:

"We'd dearly love to perform a SHOW TABLE, but in addition to not knowing the name of the table, there is no obvious vehicle to get the output of this command routed to us.

So we'll do it in steps. In each case, we'll show the whole query as we know it, with our own snippets shown specially. . .

The intent is to use a proposed field name (email) in the constructed query and find out if the SQL is valid or not. . .

If we get a server error, it means our SQL is malformed and a syntax error was thrown: it's most likely due to a bad field name. If we get any kind of valid response, we guessed the name correctly. "

Overall, this is one of the best step-by-step examples of SQL injection attacks and a must-read for any Oracle professional.
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.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.