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

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

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.