{"id":12250,"date":"2021-05-13T12:31:26","date_gmt":"2021-05-13T07:01:26","guid":{"rendered":"https:\/\/www.varutra.com\/?p=12250"},"modified":"2022-12-02T12:44:19","modified_gmt":"2022-12-02T07:14:19","slug":"second-order-sql-injection-attack","status":"publish","type":"post","link":"https:\/\/www.varutra.com\/varutravrt3\/second-order-sql-injection-attack\/","title":{"rendered":"SECOND ORDER SQL INJECTION ATTACK"},"content":{"rendered":"

<\/p>\n

Second Order SQL Injection Attack:<\/u><\/strong><\/h3>\n

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<\/a> anyone can a better understanding of the application flows which helps to detect such injection attacks.<\/p>\n

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.<\/p>\n

 <\/p>\n

Exploitation Scenario – Second Order SQL Injection with Example:<\/u><\/strong><\/h3>\n

To illustrate the vulnerability, let us consider a website that has User login, signup, and password change functionality.<\/p>\n

\"Login<\/p>\n

Fig: 1.1: Login Page<\/p>\n

In Fig-1.2 there are two users in the database in the \u2018users<\/strong>\u2019 table.<\/p>\n

\"Pre-registration<\/p>\n

Fig: 1.2: Pre-registration database<\/p>\n

Let us consider a new user registers, then login and changes the password. It\u2019s a very common functionality among all dynamic web applications.\u00a0 Firstly, the users are required to either signup or sign in. Here in Fig 1.3 new user sign-up with username \u2018test<\/strong>\u2019 and password \u2018123456<\/strong>\u2019.<\/p>\n

\"New<\/p>\n

Fig: 1.3: New User Registered \u2013 Creating an account<\/p>\n

In Fig-1.4 we observe that a \u2018test<\/strong>\u2019 user is created in the database.<\/p>\n

\"Post-registration<\/p>\n

Fig: 1.4: Post-registration database<\/p>\n

To Perform Second Order SQL Injection an attacker will register with the following username<\/p>\n

\u2018test\u2019 —<\/strong>\u2019 and creates the new account.<\/p>\n

\"New<\/p>\n

Fig: 1.5: New User Registered<\/p>\n

\"User<\/p>\n

Fig: 1.6:: User Successfully Registered<\/p>\n

In Fig-1.7 we observe that \u2018test\u2019 —<\/strong> \u2019 user is created in the database.<\/p>\n

\"Post-registration<\/p>\n

Fig: 1.7: Post-registration database<\/p>\n

Now the attacker login with the \u2018test\u2019 —<\/strong>\u2019 account and go to change password functionality and then changes the password.<\/p>\n

\"Login<\/p>\n

Fig: 1.8: Login Form<\/p>\n

\"Change<\/p>\n

Fig: 1.9: Change Password Functionality<\/p>\n

In Fig 1.9 as there is password change functionality, the attacker will change the password from \u201cabc\u201d to \u201chacked\u201d <\/strong>and click on the \u2018Reset\u2019 <\/em>button.<\/p>\n

Note that the username is\u00a0\u2018test\u2019 —<\/strong>\u00a0\u2019<\/strong>so below is the query processing in the backend in MySQL to update the password.<\/p>\n

UPDATE users SET password=’hacked’<\/p>\n

WHERE username=’test’–‘ and password=’abc’<\/p>\n

 <\/p>\n

As the username in WHERE clause is\u00a0\u2018test\u2019 \u2013\u2019<\/strong>,\u00a0 after\u00a0—<\/strong> the query will get discarded and it will consider\u00a0 ‘and password=’abc’<\/strong> as a comment because in MySQL\u00a0—<\/strong>\u00a0is used to start comments<\/a>. So Logically query ends up like: –<\/p>\n

UPDATE users\u00a0 SET password=’123′\u00a0 WHERE username=’test’<\/p>\n

 <\/p>\n

The Query results in updating the password for the user\u00a0\u2018<\/strong>test<\/strong>\u2019<\/strong>\u00a0instead of\u00a0\u2018<\/strong>test\u2018 —<\/strong>\u2019<\/strong>. Henceattacker has performed Second-Order SQLInjection<\/em> successfully. For demonstration, we have considered \u2018test<\/strong>\u2019 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.<\/p>\n

 <\/p>\n

Post-Exploitation of the attack we can login into the database and check the \u2018users<\/strong>\u2019 table:<\/p>\n

We can observe that password of the \u2018test<\/strong>\u2019 user is changed instead of \u2018test\u2019 —<\/strong>\u2019.<\/p>\n

\"Successful<\/p>\n

Fig: 1.10:\u00a0Successful Second Order SQL Injection<\/p>\n

 <\/p>\n

Attack Probability:<\/u><\/strong><\/h3>\n

The success rate of identifying a first-order SQL Injection is common as compared with the second-order SQL injection.<\/p>\n