Second-order SQL Injection

In fact, most of your search SQL Injection articles on the Internet can be classified into "first-order" SQL injection, because the events involved in these examples occur in a single HTTP request and response, as shown below:

 

(1) The attacker submits some conceived input in the HTTP request.

(2) The application processes the input, resulting in execution of SQL queries injected by attackers.

(3) If feasible, the query results will be returned to the attacker in the application's response to the request.

Another different SQL injection attack is "second-order (second-order)" SQL injection. The attack event sequence is usually as follows:

(1) The attacker submits some conceived input in the HTTP request.

(2) The application stores the input (usually stored in the database) for later use and response to the request.

(3) The attacker submits the second (different) request.

(4) In order to process the second request, the application will retrieve and process the stored input, resulting in execution of SQL queries injected by attackers.

(5) If feasible, the query results will be returned to the attacker in the application's response to the second request.

Second-order SQL injection is as powerful as the equivalent first-order SQL injection. However, it is a more subtle vulnerability, which is usually more difficult to detect.

A simple error that developers make when considering infected and verified data usually results in second-order SQL injection. It is obvious that the input is potentially infected at the point where the user directly obtains the input. Developers who receive the prompt will try to defend against Level 1 SQL injection, such as double encoding of single quotes or (more inclined) using parameterized queries. However, if the input is persistent and will be reused in the future, it is not easy to see that the data has been infected, which may cause some developers to incorrectly process the data.

Think about an address book application. You can save contact information of a friend. When creating a contact, you can enter detailed information such as name, email, and address. The application uses the INSERT statement to create a new database record for the contact and double encode the quotation marks in the input to prevent SQL injection attacks such:

The application also allows you to modify the details of the selected contacts. When you modify an existing contact, the application uses the SELECT statement to retrieve the current details of the contact and save it to the memory; then, use the new details provided by the user to update the related data items and double encode the quotation marks in the input again. The data items not updated by the user will remain unchanged in the memory; finally, use the UPDATE statement to write all data items in the memory back to the database. See:

 

Double encoding of quotation marks in the example can effectively prevent SQL injection of level 1. However, applications are still vulnerable to second-order SQL injection attacks. To exploit this vulnerability, we first need to use a field to attack the Net Load to create a contact. Assume that the database is Microsoft SQL Server, and create a contact with the following name:

1. a'+@@version+'a  www.2cto.com

The quotation marks in the input are double encoded. The final INSERT statement is as follows:

1. INSERT INTO tblContacts VALUES ('a''+@@version+''a', 'foo@example.org',…) 

Store the contact name securely to the database using the committed literal value.

Next, we turn to the new contact creation function. We only need to provide a new value for the address field (which can be any data that can be received. When performing these operations, the application first uses the following statement to retrieve the details of an existing contact:

1. SELECT * FROM tblUsers WHERE contactId=123 

The retrieved details are stored in the memory. Of course, the retrieved value based on the name field is the same as the literal value originally submitted, because it is the content stored in the database. The application uses the new value to replace the address value in the memory. Note that the quotation marks are double encoded. Next, run the following UPDATE statement to save the new information to the database:

1. UPDATE tblUsers  

2. SET name = 'A' + @ version + 'A', address = '52 Throwley Way ',...
3. WHERE contentd = 123

So far, the attack has successfully executed and overturned application queries. The name retrieved from the database is unsafely processed. You can get rid of the data context in the query and modify the query structure. In this concept verification attack, we copied the database version string to the contact name. When you view the details of an updated contact, it is displayed on the screen:

1. Name: aMicrosoft SQL Server 7.00 - 7.00.623 (Intel X86) Nov 27 1998  

2. 22:20:07 Copyright (c) 1988-1998 Microsoft Corporation Desktop
3. Edition on Windows NT 5.1 (Build 2600:)
4. Address: 52 Throwley Way

If you want to execute a more effective attack, you must first put the attack in a contact field by using the technology that is frequently used in injection UPDATE statements (see Chapter 8th, then, the vulnerability is triggered by updating a different field.

Search for Level 2 Vulnerabilities

Second-order SQL injection is more difficult to detect than one vulnerability, because after one request is submitted for exploitation, the exploitation must be performed in the application's processing of another request. Second-order SQL injection is not suitable for core technologies used to discover most input-based vulnerabilities. These technologies use a variety of constructed inputs to repeatedly submit independent requests and monitor exceptions in the response. Unlike the above technology, we need to submit the conceived input in a request, and then gradually track other functions in the application that may use the input to find exceptions. In some cases, the related input only has one instance (for example, the display name of the user). In this case, gradually tracking all functions of the application may need to test each net load.

Today's automatic scanner cannot effectively detect second-order SQL injection. They usually use different inputs to submit each request multiple times and monitor the response of each request. If you search for other areas of the application and encounter database error messages, they will display these messages to the user, hoping that the user can investigate and diagnose the existing problems. However, they cannot associate error messages returned from a location with some conceptual inputs submitted from other locations. Sometimes there is no error message, and the effect of the second-order condition may be processed blindly. If there is only one associated persistent item instance or multiple steps (for example, user registration) are required to make the data items persistent in the application, the problem is more serious. Therefore, today's scanners cannot perform a rigorous system approach to finding second-level vulnerabilities.

If you cannot understand the meaning and usage of data items in an application, the workload involved in second-order SQL Injection detection will increase exponentially as the application function increases. However, manual testers can reduce the complexity of tasks by understanding the functions and making intuitive judgments on frequent error locations. In most cases, you can use the following system method to identify second-level vulnerabilities:

(1) After the application content and functions are planned, review and find all data items that can be controlled by users. These data items will be permanently stored by the application and reused by subsequent functions. Operate on each data item separately and perform the following steps for each instance.

(2) Submit a simple value in the data item. It may cause problems when the data item is not safely used in SQL queries. For example, single quotes or alphanumeric strings caused by single quotes. If necessary, quickly check all processes that contain multiple stages (such as user registration) to ensure that the data value exists permanently in the application.

(3) If the application's input filter blocks the input, use the encoding case and so on to bypass the filter. There are related articles on the Internet.

(4) quickly check all functions of explicitly using data items in the application and the functions that may be implicitly used. Find all abnormal behaviors that indicate that the input has caused a problem, for example, database error messages, HTTP 500 Status Code, more confidential error messages, damaged functions, lost or destroyed data.

(5) For each potential problem identified, try to develop a concept verification attack to check whether the SQL injection vulnerability exists. Note that defective persistent data may be indirectly attacked (for example, Integer Conversion error or subsequent data verification failure) to cause exception conditions. Try to use two quotation marks to provide the same input and check whether the exception disappears. Try to use a database-specific structure (such as a string connection function and version ID) to confirm that the SQL query is being modified. If the exception condition is blind (for example, no query results or any error messages are returned), try the Time Delay technique to confirm the existence of the vulnerability.

We should be aware that some second-order SQL injection vulnerabilities are pure blind and will not have a recognizable impact on any content in the application response. For example, if a function of an application writes persistent login data in an insecure manner and gracefully handles all exceptions, you may not be able to find this vulnerability by using the steps we just introduced. To detect this type of defect, You need to repeat the above steps by using various inputs in step (1) (which triggers a time delay when these inputs are not safely used in SQL queries, then, monitor all the functions of the application to detect abnormal latency. To effectively achieve this goal, you need to use a syntax dedicated to the currently used database type and the currently executed query (SELECT, INSERT, etc. In fact, this is a skill that requires long-term practice.

Tools and traps ......

Causes of second-level Vulnerabilities

Second-order SQL injection is common, which is a little surprising. The author of this book has encountered this vulnerability in mature and secure applications (such as online banking programs. These vulnerabilities can be hidden for several years because it is relatively difficult to detect them.

Many (or even the majority) developers are aware of the threat of SQL injection and know how to use parameterized queries to securely integrate infected data into SQL queries. However, they also know that it takes more effort to write a parameterized query than to construct a simple dynamic query. Many developers still have misunderstandings about the concept of infection, believing that they can be considered trusted data only after receiving the data provided by users.

A common method for writing SQL queries is to use parameterized queries for data that is significantly infected (such as the content received from the current HTTP request). In addition, in each case, you can determine whether the data can be used securely in dynamic queries. This method is dangerous because it can easily lead to negligence and incorrectly process infected data. Trusted data sources may be infected by changes elsewhere in the basic code in the future, so that second-level vulnerabilities are introduced without knowledge. This misconception that data items seem trustworthy, but they are not credible, is that data items must be processed securely only after they are received.

To defend against second-level vulnerabilities, the most robust method is to use parameterized queries for All Database Access and properly parameterize each variable data item integrated into the query. Using this method to find truly trustable data requires a small amount of effort, but it can avoid the above errors. Using this policy can also make SQL Injection-related code security review easier and faster.

Note that before assigning data items to their placeholders, sub-partitions (such as columns and table names) of some SQL queries cannot be parameterized, because the structure composed of these child parts after the query is defined is fixed. If you want to integrate the data provided by the user into the subparts of the query, you should determine whether you can use different methods to implement your own functions. For example, you can pass the mapped index number to the table and column name on the server. If this is not feasible, the user data should be carefully verified according to the whitelist principle (before use ).

 

From FUCK 1 T!