What is a Second-Order SQL Injection and how to identify Attack Scenario, Potential Impact and Remediation!

What is SQL Injection?

SQL Injection — the process of injecting SQL language code within data requests that result in application backend database server either surrendering confidential data or cause the execution of malicious scripting content on the database that could result in a complete compromise of the host.

SQL injection is one of the most frequent attacks of web applications and is included in the Top 1 of OWASP Top 10. In a typical SQL injection attack, the result is observed immediately once the user-supplied malicious input and that becomes a part of the SQL query which gets executed at the backend and the output is returned in the response (generally a SQL database error message). But this is not the case with a Second Order SQL Injection. It is also a lesser-known attack vector. Let us see what it is and how it is triggered.

Introduction:

In a Second Order SQL Injection, the malicious user-supplied injected input is stored in the Database and later it is used (without proper sanitization) in a new SQL query when a user accesses some other functionality of the same application. This is what is called a Second Order SQL Injection. In short, Injection and Response take place in different parts/functionalities of the same application.

Attack Scenario: 

1. An application has a “Register” Page wherein a new user registers himself at first and then logs in to the application to use the internal application functionalities.
2. A malicious user creates a new account with the username as “administrator’ –” & password as “Admin@123” and registered himself. This newly created username and password is then stored in the database without validation.
3. This application also has a post-login functionality to update the passwords of registered users. If a registered user wishes to update his/her existing password, then he/she can use this feature. This functionality is prone to a Second-Order SQL Injection since the user-supplied input is not sanitized properly.
4. A malicious user visits the “Update Password” functionality and injects the username as “administrator’ –“and password as “Newpass@123”, then clicks on the Update button. The final SQL query is then built to change the password of the user “administrator” instead of the user “administrator’ –” since this “–” comments out the trailing query. As a result, a malicious user has successfully changed the password of the “administrator” account and now has unauthorized access to the administrator account.  

 How to Identify:

This type of vulnerability is more difficult to locate because they are not designed to execute immediately. The primary method is to perform a Source Code Review of the Application codebase to find out potentially vulnerable code.

For a Dynamic analysis, understand how the data flows within the target application and identify the functionality where the user-supplied data are stored and reused later such as “Update Password” functionality (Data gets stored in the database and executed later. Something like Stored XSS).

Tools:

1. A Web Application Proxy such as Burp Suite 
2. SQLMap (to dump data from the database)

Figure 1: A second-order SQL injection attack flow (Generic)

Potential Impact:

1. Unauthorized access to sensitive information
2. Account Takeover of the other user (Victim)

Remediation:

A prepared statement is an effective way to prevent all types of SQL Injection attacks. Since it ensures that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. Data encryption (data at rest) would also work here as a secondary level of defense.  

The above blog is one of the many steps taken by our team at AFour Technologies towards our continuous efforts of educating businesses about various security threats. If this is something you or your business is also concerned about, our security experts would love to have a conversation with you.