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
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.
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.
- 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.
Mohammed Musharraf Raza
Attack & Pentest Team
Varutra Consulting Pvt. Ltd.