Explanation of N pose for SQL injection in the big talk Database

Explanation of N pose for SQL injection in the big talk Database
I. background

With its powerful data storage capabilities and excellent data processing performance, Databases play a key role in information construction in all walks of life. With the large-scale application of databases in various industries, Data leaks also occur frequently, which makes database security problems increasingly prominent and gradually become a concern for users. Although database vendors have made many effective measures to solve database security problems as much as possible, so far, database security vulnerabilities continue to increase. Shows the number of database vulnerabilities in the last five years.

 

SQL injection is the most common type of database vulnerabilities. Database security experts have summarized the classification of database Injection Based on the results of years of practice, so that you can have a more comprehensive understanding of SQL injection vulnerabilities.

SQL Injection not only occurs on the WEB, but also on custom databases or stored procedures, functions, and triggers of standard databases. The SQL injection vulnerability of the database itself poses a greater threat to the database than the WEB injection vulnerability. In this article, the classification of SQL injection is from the database perspective, regardless of the WEB side. The two have different classifications.

Before explaining the SQL Injection Vulnerabilities in different databases, we should briefly describe the main principle that database attackers can perform SQL injection: the SQL injection vulnerability allows users to mix program commands into the input. The most direct example is that attackers can transmit their SQL code to the corresponding application through user input on a normal Web page to execute some unauthorized SQL code, to modify, steal, or damage database information. SQL injection attacks can even help a group of attackers bypass the user authentication mechanism so that they can fully manipulate databases on remote servers. If the application uses user-input data to construct dynamic SQL statements to access the database, it may be vulnerable to SQL injection attacks. Similarly, if stored procedures are used in the code, and these stored procedures do not have reasonable restrictions on user input, SQL injection may easily occur.

Ii. SQL Injection Classification 1) injection route Classification

SQL injection vulnerabilities can be divided into two categories based on the physical channels of injection: injection attacks on databases through WEB terminals and injection attacks on directly accessing databases.

Direct access to the database for injection attacks is to directly connect to the database as a database user for SQL injection attacks. In this attack mode, attackers can execute SQL statements through SQL injection to improve user permissions or perform unauthorized execution. Stored Procedures, functions, triggers, and blocks that are not defined using authid current_user during user authorization in PL/SQL programs are more vulnerable to SQL injection attacks.

 

WEB application users can connect to databases and launch SQL injection attacks. In this type of SQL injection attacks, attackers usually use concatenated statements to change the query content. Obtain all information under the Account permission.

 

Some advanced attack methods often combine these two methods to obtain the basic information of the database and the server where the database is located by exploiting the SQL injection vulnerability on the WEB application. The SQL injection vulnerability of the database itself can be used to escalate the permissions of the acquired database account or escalate privileges. This can damage the database or obtain sensitive information.

2) injection Classification

According to the intrusion method, SQL Injection attacks against databases can be divided into four types: SQL Manipulation, Code Injection, Function Call Injection, and Buffer Overflows. The first two types of SQL injection attacks are more common than WEB-based SQL injection attacks. The latter two types of attacks are attacks directly against the database itself, so the security threats to the database are even more critical.

1. SQL manipulation is the most common type of SQL injection attacks. The principle of this attack is that the attacker tries to use the SET Operator in an existing SQL statement) for example, UNION, INTERSECT, or MINUS can add some content to the WHERE clause to change its function. Of course there may be many other changes. The most classic SQL manipulation attack exists in the logon verification process. A simple Web application can check whether user authentication has returned values by executing the following SQL statement:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'Guess ', attackers can modify the SQL statement: SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'xxxx' or 'A' = 'A'

Through the above modification to the WHERE clause, the user login can be identified as true, so that the attacker can bypass the user authentication and obtain the right to enter the background. UNION, a set operator, is often used in SQL injection attacks. The main purpose is to return certain rows from another table by operating SQL statements. A web form can return a required form from an existing product table by executing the following SQL statement:

SELECT product_name FROM all_products WHERE product_name like '%ddd%'

Attackers can modify the SQL statement:

SELECT product_name FROM all_products WHERE product_name like '%ddd%' UNION SELECT username,password FROM dba_users WHERE username like ‘%’

In this case, the results in the returned web form after the SQL statement is executed will include all product names and all database usernames and passwords (of course, the linked account must have the permission to query the table dba_users ).

2. code injection is an attempt to add additional SQL statements or commands to an existing SQL statement. Such attacks are often applied to Microsoft's SQLServer applications. In SQL Server, EXECUTE statements are often the targets of such SQL injection attacks. Although Oracle databases do not have corresponding statements, PL/SQL and Java do not support requests for Multiple SQL statements in a single database, however, some programming languages or APIs may allow simultaneous execution of Multiple SQL statements. PL/SQL and Java applications can dynamically execute anonymous PL/SQL blocks that are vulnerable to code injection attacks. Therefore, under certain circumstances, code injection attacks are still effective for databases that do not support multiple SQL requests.

3. function call injection is caused by some vulnerabilities in database functions or custom functions, attackers inject SQL statements into problematic functions to execute unexpected functions. Strictly speaking, not only may functions in the database have stored procedures, triggers, and other similar vulnerabilities. These function calls can be used to generate data or system calls in the database.

Taking Oracle as an example, Oracle databases allow user-defined functions or functions in the package to be executed as part of SQL statements. At the same time, Oracle database provides more than 175 functions in 1000 standard database packages, a small part of which may be vulnerable to SQL injection attacks, and those functions used for network communication can also be exploited by attackers. Any user-defined function or function that exists in the User-Defined package can be executed in an SQL statement. When a function is executed as a part of the SQL SELECT statement, the database cannot be converted into any change except the number of other functions, which is marked as "PRAGMATRANSACTION ". Only a small number of standard database functions are automatically executed, and the functions executed in the insert, update, and delete statements modify the data in the database. When attackers use standards with Vulnerabilities

When using Oracle functions, you can send information in the database to a remote computer or execute attacks on other database servers. Many Oracle-based applications may use database software packages with vulnerabilities, these custom software packages may include functions that can change passwords or execute sensitive applications.

For function call injection attacks, any dynamically generated SQL statements are fragile, and even the simplest SQL statements can be exploited by attackers.

Example: Create a stored procedure test

Create a custom stored procedure with DBA permissions:

 

create or replace procedure test (putin varchar2) astype c_type is ref cursor;cv c_type;buffer varchar2(200);begindbms_output.enable(1000000);open cv for ‘select object_name from all_objects where owner =’’’||putin||’’’and object_type=’’library’’’’;…close cv;End;/

 

 

This SQL statement is not vulnerable to injection attacks of other types, but is vulnerable to function injection attacks. This is because the function lacks constraints on input variables. Attackers may enter a command to execute. For example, grant dba to public;

A low-Permission user constructs a function containing the command to be executed:

Create or replace function get_dba return varchar authid current_user isPragma autonomous_transaction;BeginExecute immediate ‘grant dba to scott’;End;/

In this example, the stored procedure test is used to query the databases owned by users. However, to facilitate the execution of test by other users, this permission is granted to all users, as a result, any user can execute the test stored procedure. However, because the definer permission is used in the function to define test, all users obtain the DBA permission when executing test.

In this process, a low-Permission user creates the injection function get_dba. Use test to escalate any low-permission account to DBA permissions.

Exec sys.test(‘AAAA’||username.get_dba()—‘);

At this point, low-Permission users can exploit this vulnerability to escalate their permissions to DBA for illegal control of the entire database. The solution of the database vendor is to delete the public execution permission of the function with the vulnerability.

4. many standard database functions are vulnerable to buffer over flows attacks, this is because the buffer overflow vulnerability can be easily exploited by performing SQL injection attacks on databases that are not patched in time. The buffer overflow vulnerability is very harmful, which often causes attackers to directly control the database or the operating system where the database is located.

Take Oracle as an example. In some versions of standard database software packages and standard database functions:

TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, andNUMTODSINTERVAL, and other functions have the buffer overflow vulnerability. To use these standard database packages and functions with the buffer overflow vulnerability to attack the buffer overflow vulnerability, you must use the function injection method described earlier; when attackers use SQL injection to exploit the buffer overflow vulnerability, they can connect to the operating system remotely. In addition, some applications and WEB servers cannot normally handle database connection interruptions caused by buffer overflow. In general, Web processes will be suspended and even cause DoS attacks.

Iii. Protection against SQL Injection

Database vendors have done a lot of work on SQL injection. oracle is used as an example to develop a dbms_assert patch package when Oracle Releases 10G r2. This patch pack is mainly used to fix the SQL injection vulnerability and enhance the defense of user input information. Fixed a large number of existing database vulnerabilities. However, it cannot completely solve all SQL injection vulnerabilities of the database itself. According to the test results, DBMS_ASSERT lacks effective defense against second-order SQL injection and cross-language parameter passing.

Although the database vendor has been working hard, it is limited by the database application environment and scenarios. In many cases, the database cannot be updated with patches in a timely manner, so many times the database threats still exist. Database security experts recommend that database users use third-party products to reinforce database security when necessary, in addition to timely updating database patches.

Here, database security experts provide two ideas for database reinforcement:

1. Encrypt sensitive information from the source. Even If attackers obtain sensitive information, they can ensure that the information is fully ciphertext and the attackers cannot obtain valuable information;

2. From the perspective of database security reinforcement. The database firewall can effectively defend against external attacks. The professional database Firewall should be based on the precise resolution of database protocols. It precisely identifies risks in SQL syntax/Lexical, and has the database Virtual patch technology for fine-grained permission control, core features such as behavior auditing and monitoring and analysis are used to prevent database intrusion. Play the role of protecting database security.

We believe that any of the above methods will make the data in the user database more secure.