Categories: Vulnerability DisclosureWeb Application Security

SECOND ORDER SQL INJECTION ATTACK

Second Order SQL Injection Attack:

Second Order SQL Injection Attack are those which are not widely discussed. Important to know that these cannot be detected by tools or via scanning. One needs to understand the application logic and flow of the applications to detect this vulnerability. These attacks are based on the logical flaw in the web application so by conducting the Secure/ Source Code Review anyone can a better understanding of the application flows which helps to detect such injection attacks.

Generally, an Injection attacks happen when the developer trusts the input or fails to sanitize user input to build up the query being used in the application. The primary reason or cause for injection vulnerabilities is usually insufficient user input validation.

Exploitation Scenario – Second Order SQL Injection with Example:

To illustrate the vulnerability, let us consider a website that has User login, signup, and password change functionality.

Fig: 1.1: Login Page

In Fig-1.2 there are two users in the database in the ‘users’ table.

Fig: 1.2: Pre-registration database

Let us consider a new user registers, then login and changes the password. It’s a very common functionality among all dynamic web applications. Firstly, the users are required to either signup or sign in. Here in Fig 1.3 new user sign-up with username ‘test’ and password ‘123456’.

Fig: 1.3: New User Registered – Creating an account

In Fig-1.4 we observe that a ‘test’ user is created in the database.

Fig: 1.4: Post-registration database

To Perform Second Order SQL Injection an attacker will register with the following username

‘test’ —’ and creates the new account.

Fig: 1.5: New User Registered

Fig: 1.6:: User Successfully Registered

In Fig-1.7 we observe that ‘test’ — ’ user is created in the database.

Fig: 1.7: Post-registration database

Now the attacker login with the ‘test’ —’ account and go to change password functionality and then changes the password.

Fig: 1.8: Login Form

Fig: 1.9: Change Password Functionality

In Fig 1.9 as there is password change functionality, the attacker will change the password from “abc” to “hacked” and click on the ‘Reset’ button.

Note that the username is ‘test’ — ’so below is the query processing in the backend in MySQL to update the password.

UPDATE users SET password=’hacked’

WHERE username=’test’–‘ and password=’abc’

As the username in WHERE clause is ‘test’ –’, after — the query will get discarded and it will consider ‘and password=’abc’ as a comment because in MySQL — is used to start comments. So Logically query ends up like: –

UPDATE users SET password=’123′ WHERE username=’test’

The Query results in updating the password for the user ‘test’ instead of ‘test‘ —’. Henceattacker has performed Second-Order SQLInjection successfully. For demonstration, we have considered ‘test’ user but its common most of the websites have users as admin, administrator, etc. It is very easy to guess such usernames and an attacker can perform the attack on such guessable usernames or accounts.

Post-Exploitation of the attack we can login into the database and check the ‘users’ table:

We can observe that password of the ‘test’ user is changed instead of ‘test’ —’.

Fig: 1.10: Successful Second Order SQL Injection

Attack Probability:

The success rate of identifying a first-order SQL Injection is common as compared with the second-order SQL injection.

The First-order Injections often referred to as ‘shooting fish in a barrel’ can be observed directly by different scanners (Burp Suite, Acunetixetc.) whereas the relative probability of second-order SQL Injection is low.
The Second-order SQL Injection attack must be performed “blindly” in most of cases because the attacker performs the attack on the backend functionality without any prior knowledge of the system.

Impact:

With the successful exploitation of this vulnerability, a remote user or an attacker can compromise the user account. Any successful attack will result in an impact on CIA (Confidentiality, Integrity, and Availability) of the critical data.

Recommendation:

The most effective way to prevent SQL injection attacks is to use of stored Procedures, parameterized queries, or prepared statements.
Do not parse the user input directly. Properly sanitize the user input.