OWASP (Open Web Application Security Project) community whose primary motive is to encourage all organizations in improving their Software Security, is performing rigorous research and in taking feedback from various Security Experts around the globe and publishing Top 10 major vulnerabilities on a periodic basis. Refer to the below link for more details on the Top 10 vulnerabilities published by OWASP:
As we can see from the above article, OWASP organization has been publishing the list of top ten vulnerabilities on a frequent basis and SQL Injection is leading their published list from the year 2010. Hence in this article, I would like to take you through the Injections and the following section will explain Injection vulnerabilities in detail.
Injections: Application vulnerabilities which are taken advantage through client-side submission of malicious input are known as Injections. i.e. Malicious Input/Data/Commands are provided as input into the Client-side fields, which when accepted by the System will lead to compromising of vulnerabilities in the system and allowing the attacker to bypass the authentication & gaining administrative privileges to fully access the application and its database. The following screen-shot will help in understanding how the applications accept malicious code from client-side fields and result in compromising the system vulnerabilities by attackers.
Though the above diagram explains how the vulnerabilities in the system can be compromised at a high level, its required for us to know the actual root cause of ‘why this vulnerabilities are available in the system’ and ‘why security testing is required to identify these vulnerabilities’. The actual route cause for this is, when a developer writes code for an application, he/she would have probably verified that the application is verifying the anticipated data submitted by the users into the fields, but have missed verifying the validation of unanticipated malicious data that can be provided by attackers with an intention of performing security attacks.
OWASP Definition for Injection: Though we have understood how the Injection flaws can be used by the attacker in performing attacks, as a security enthusiast we should remember the following standard definition for Injection vulnerability provided by OWASP organization:
- Injection flaws, such as SQL, NoSQL, OS, LDAP injection, occur when the untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Types of Injections: Based on the type of malicious data supplied at the client-side, Injections can be categorized as following types:
- SQL Injection (SQLi)
- Hibernate Query Language Injection (HQLi)
- LDAP Injection
- XPath Injection
- XQuery Injection
- XSLT Injection
- XML Injection
- OS Command Injection
- Code Injection
- CRLF Injection
- Email (Mail command/SMTP) Injection
- Host Header Injection
- XSS Injection
- JavaScript Injection
- HTML Injection and many more.
Requirement for Security Testing around possible Injections: As part of Security Testing, we verify the input validations at the client-side, to make sure that the untrusted client is not sending malicious inputs to the server.
SQL Injection: Though there are different types of Injections, SQL Injection is the most exploited type of Injection. As per Verizon estimations, over 1 million records have been accessed by the attackers due to the SQL Injection alone. Using SQL Injection, attackers will supply the malicious data into the client-side fields, which will be accepted by the system and dynamically built into SQL statements. These dynamically built SQL statements will be executed against the Application Databases like Oracle, Microsoft SQL Server etc. and result in helping attackers in querying, operating and administering database system for which the attacker doesn’t have access to perform these operations. Hence attackers compromise SQL Injection vulnerabilities in the system with an intention of accessing and gaining control on the Application database systems. In order to understand how an SQL Injection can be performed on a system, it is recommended to learn/brush-up SQL basics. The below post will help you in learning/understanding the SQL basics which are required for performing SQL Injections:
SQL Injection and Client-side Input fields: Not all the client-side input fields can be used to perform SQL Injection, instead only the client-side input fields which intake the input data from the user and dynamically generate SQL queries to query and retrieve the data from the database can be SQL Injected. The following are few examples of client-side fields, for which the SQL Injection is possible.
Example #1 – Login Fields: The following is how the user input like username and password will get transformed into a dynamically generated SQL query for accessing the data from the database:
Other Examples: The input fields in the places like Update Profile, Change Password etc. needs to interact with DB to update the data. Hence there is a possibility of SQL Injection for these input fields.
Compromising SQL Injection Vulnerability: As part of SQL Injecting input fields which are vulnerable, the attackers pass the user data into these input fields in such a way that the malicious SQL query is dynamically generated from the inputted data and interpreter is tricked to execute the dynamically generated malicious SQL query. When the malicious SQL query is executed by the interpreter, the attacker may bypass the authentication process and also gain administrative privileges to fully access/control the application. The following example will help you in understanding how an attacker enters the unanticipated input into the Login fields with an intention of gaining admin access to the application.
Step#1 – Attacker navigates to vulnerable application say http://demo.testfire.net/ and click on ‘SignIn’ option (Don’t try this example on other websites, as they may result in legal issues for you. Only use the allowed application like http://demo.testfire.net/ where we can perform Security Testing activities)
Step#2 – Instead of entering the valid username and password into the Login fields, an attacker may enter unanticipated input like single quote ‘ into the Username and password fields as shown below and clicks on ‘Login’ button
Step#3 – Observe that an Error page having the details of the Application DB (i.e. OLEDB) is getting displayed as shown in the below screenshot.
From the above error page, Security Testing will identify the below things:
- If we are getting this kind of error page shown in the above screenshot, it is now confirmed that the Application is vulnerable to SQL Injection.
- If the attacker sees the above error, the attacker knows that the application is vulnerable to SQL Injection and performs other SQL Injection queries to further attack the vulnerable system.
- The error page is displaying the details of DB as OLEDB, which is nothing but the exposure of the Application DB details to the Attackers. Attackers now know the DB details used by the application and hence can trigger SQL Injections specific to the DB.
- Security Testing will report this defect to the Developers for the fix along with the above screen-shot.
From the above example, the attacker now knows that the Login fields in the Application are vulnerable to SQL Injection. With this outcome, the attacker will plan for next level of exploitation of the system. The following steps will demonstrate how the attacker performs next steps with an intention of gaining access to the system.
Step#1 – Attacker will again navigate to the ‘Login’ page and enter another unanticipated input into the Username field like ‘ or 1=1 – – , anything password text into the password field and clicks on Login button.
In the above screenshot, when the user enters unanticipated input (i.e. payload) as ‘ or 1=1 – – , the dynamically generated SQL query will be generated as below:
- Select * from Users where username= ‘ or 1=1 – – and password = abcdxyz
In the above query, single quote ‘ will concatenate or 1=1 to the SQL query that will be dynamically generated by the application, 1=1 is always true and – – will comment out the rest of the query. Hence the above query when executed will be executed as below:
- Select * from Users where username= or true – – and password = abcdxyz
- The green color text in the above query is commented and hence won’t be executed.
- Since the query is always true and password is commented and not required to be validated, the access to the application can be bypassed as shown below on clicking ‘Login’ button with the above-specified inputs.
From the above Admin access, the following points can be understood:
- Most of the DB’s have Admin users as the first user. Hence on inputting the unanticipated input (i.e. payload) ‘ or 1=1 – – , the attacker is provided with the access of the first user i.e. Admin User
- Now the attacker has full control on the Application and can retrieve the sensitive data, modify the data and delete the data in DB based on his intentions.
Similarly, there are different types of SQL Injection payloads that the attacker can use for exploiting the SQL Injection vulnerable flaws in the application. And, also there is a checklist of different SQL Injection payloads (known as SQL Injection cheat-sheet) which the attacker can use to exploit the vulnerable application. To protect the vulnerable applications, as a security testing enthusiasts we have to validate the application with all these different types and checklist of payloads. As complete SQL Injection cannot be explained in a single post, the further topics (including different types of SQL Injections, cheat-sheet of SQL Injections and others) will be explained in the following upcoming posts:
- SQL Injection – Part 2 (Coming soon)
- SQL Injection – Part 3 (Coming soon)
- SQL Injection – Part 4 (Coming soon)
- SQL Injection – Part 5 (Coming soon)
- SQL Injection – Part 6 (Coming soon)
Conclusion: Out of different types of Injections, SQL Injection is the most exploited one and hence tops OWASP Top 10 Vulnerabilities publication list from the year 2013. Using SQL Injection, attackers will supply the malicious data into the client-side fields, which will be accepted by the system and dynamically built into SQL statements. These dynamically built SQL statements will be executed against the Application Databases like Oracle, Microsoft SQL Server etc. and result in helping attackers in querying, operating and administering database system for which the attacker doesn’t have access to perform these operations. Hence attackers compromise SQL Injection vulnerabilities in the system with an intention of accessing and gaining control on the Application database systems. As everything on SQL Injection cannot be covered in the single post, we will be creating more posts on SQL Injections and release as part of future posts as Part 2, Part 3, Part 4, Part 5 and Part 6.
Please leave your questions/comments/feedback below.
Happy Learning 🙂
Arun Motoori (www.QAFox.com)
