Second-Order SQL Injection Attack inserts SQL language code into data requests, causing the application backend database server to either secret surrender data or execute malicious programming material on the database, potentially leading to the host’s full penetration.
SQL injection is one of the most common online application threats, ranking first in the OWASP Top 10. In a normal SQL injection attack, once the user provides malicious input. It becomes part of the SQL query that will process at the backend. The output will provide in the response; the result is instantly visible (generally a SQL database error message).
However, with a Second Order SQL Injection, this is not the case. It’s also a lesser-known type of assault. Let’s have a look at what it is and how it works.
Introduction
The malicious user-supplied inject input will save in a Second Order SQL Injection in the database. It is then utilised (without sufficient sanitisation) in a new SQL query when a user visits another capability of the same application.
A Second-Order SQL Injection is what this is referring to as. In a nutshell, injection and response occur in separate parts/functionalities of the same application.
Second-Order SQL Injection Attack Scenario:
- An application has a “Register” Page where a new user initially registers himself before logging in to utilise the program’s core functions.
- A malicious person establishes a new account and registers with the username “administrator” –” and password “[email protected]” After that, the database stores the newly form login and password without any validation.
- This program also features a post-login feature that allows registered users to update their passwords. This function is used by registered user who wants to update their existing password. However, because the user-supplied input is not adequately sanitised, this capability is vulnerable to a Second-Order SQL Injection.
- The malicious user goes to the “Update Password” option and enters “administrator”. The username and “[email protected]” as the password, then hit the Update button. Because this “–” comments out the trailing query, the final SQL query will create to change the password of the user “administrator” rather than the user “administrator’ –”. Consequently, a malicious user can alter the password of the “administrator” account, giving them illegal access to the account.
Second-Order SQL Injection Example
Assume you have a Web-based application that saves usernames and other session data. You wish to extract the current username from a session identifier, such as a cookie, and then use it to access specific user information. As a result, you may have code for an “Update User Profile” panel that looks like this:
Execute immediate ‘SELECT username FROM session table WHERE session
=’’’||session id||’’’ into username;
Execute immediate ‘SELECT ssn FROM users WHERE
Username=’’’||username||’’’ into ssn;
This will be an injectable username, such as: in the “Create Account” screen.
XXX’ OR username= ‘JHON
Which create the query:
SELECT ssn FROM users WHERE username= ‘XXX’ OR username=’JHONE’The attacker will successfully get JHON’s social security number if the user XXX does not exist.
By utilising double quotation marks to introduce harmful constructions. The attacker can build malicious database objects such as a function called part of an API or a malicious table. An attacker can, for example, construct a table with a name like “tab’) or 1=1–” that can subsequently be abused in a second-order SQL injection attack.
How to Identify
Because they are not meant to execute instantly, this vulnerability is more difficult to find. The most common way is to do a Source Code Review of the application’s codebase to identify possibly susceptible code.
Understand how data flows inside the target application for a Dynamic analysis. And discover features where user-supplied data will store and utilise later, such as the “Update Password” capability (data will keep in the database and perform later). Something along the lines of Stored XSS).
Tools
- A web application proxy such as burp suite
- SQLMap
The Potential Impact of Attack
Second-order code injection attacks have a more significant impact than first-order code injection attacks. This is partly due to:
- The opportunity to target the application’s administrators and the supportive environment.
- The ability to target non-technical personnel like customer service representatives.
- The possibility for internal hosts (such as help-desk workstations and databases) to be harmed.
- The ability to “seed” attack code into application data storage regions before exploitation.
How to Protect From SQL Injection Attack
The procedures for preventing second-order code injection attacks are nearly identical to those for dealing with any other type of code injection attack. The following are examples of remedial guidance and security best practices:
- Never rely on information provided by users.
Data sanitisation on the client-side is always vulnerable. - Therefore, data should always be sanitised on the server.
- To sanitise data, use a white-list method (i.e. disallow everything by default and explicitly enumerate data characters that are allowed or deemed “safe”).
- Be aware that data declared “safe” for one application component might not be safe for another.
- Before processing the stored data further, any program that accesses it (particularly if the data will contribute by users) must apply its data sanitisation techniques.
Here is PHP code from OWASP showing how to prevent this attack by sanitising the input.
String firstname = req.getParameter("firstname");
String lastname = req.getParameter("lastname");
String query = "SELECT id, firstname, lastname FROM authors WHERE firstname = ? and lastname = ?";
// Using a PreparedStatement to take the user’s query and sanitize it
// by setting it as a string, instead of directly passing it to DB
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, firstname );
pstmt.setString( 2, lastname );
try
{
ResultSet results = pstmt.execute( );
}The probability of Attack
At this point, the chances of a successful attack are limited. This is due to a variety of reasons, including:
- Classical (first-order) code injection assaults are so widespread. However, they have a lower relative attack probability than second-order code injection.
- The application security industry’s ‘low hanging fruit’ is first-order code injection. As a result, attackers are unlikely to fully target an organisation using these attack vectors until these first-order code injection locations are difficult to find within a specific program.
- Second-order code injection must be performed “blindly” in many circumstances. The attacker must attempt to exploit backend functionality without knowing anything about the system beforehand. As a result, predicting whether or not an attack would succeed is challenging.
- Because the success of an attack may not be known for several hours, days, or weeks, an attacker would most likely try alternative attack paths that give quick verification first.
The likelihood of an attack is projected to rise in the coming years as businesses implement systems. That better identifies and defends them against first-order code injection assaults. But are unable to detect increasingly complicated second-order attack routes.
Furthermore, well-trained criminals upload attack code into an application’s short-term or long-term data storage locations. It is typically easy to seed an application before the assault, making it a perfect vector for them.
Second-Order SQL Injection Attack – Business Risks
It’s tough to assess the commercial risks of second-order code injection vulnerabilities. While the chances of successful exploitation are now minimal, the consequences of exploitation are frequently severe. As a result, second-order code injection vulnerabilities pose a medium-to-high risk to data integrity and business continuity.
This risk factor will anticipate rising in the coming years as tools and approaches aid in mitigating first-order code injection vulnerabilities but are less likely to aid in the mitigation of second-order code injection vulnerabilities. Furthermore, new attack avenues will emerge as backend systems get more complex and data share more openly.
Conclusion
Automat methods or procedures are frequently used to find traditional code injection vulnerabilities. On the other hand, standard vulnerability assessment tools are incapable of detecting second-order code injection vulnerabilities as applications become more sophisticated and integrate with more backend systems that may not directly respond to malicious code injections, providing false comfort to the organisations that rely on them. For more Blog articles related to security, visit our website.
Automated tools will never be able to detect all second-order code injection flaws. Instead, suppose security experts are to detect and block these increasingly common attack routes. They must collaborate closely with application development and support staff, using data processing schematics and understanding auxiliary programs. Organizations must guarantee that all significant data processing components and subsequent applications can sanitise the data they utilise and that data from other process sources is not automatically trustable.
