INJECTION FLAWS
Introduction to Injection Flaws
Introduction
Injection Flaws are security vulnerabilities that permit programmers to get to the back-end database, shell command, or operating system call if the web-app takes client input. Programmers can put malicious code to another system by appending additional information in input boxes or appending scripts into applications. Therefore, they can read, update, delete or create data in the database. This data or information present in the database may incorporate individual and delicate information like Mastercard numbers, any significant ID, or some other private information.
Resources Used
WebGoat was used to gain an understanding of Injection flaws vulnerability. WebGoat is a deliberately insecure application that allows interested developers to test vulnerabilities commonly found in Java-based applications that use common and popular open-source components. To intercept requests, BURP SUITE was used. Mitigation of the given attacks was then done on a web app using NodeJS and SQL as backend and database.
The following screenshots are also taken from WebGoat to facilitate a clearer understanding.
Detailed Injection Flaws
- SQL Injections: If an SQL query like SELECT * FROM user_data WHERE userid = ? returns the correct information, the page will accept the input, and we can successfully get all the data related to that user id. If all ids need to be displayed, the input can be 101 AND 1=1, where 101 is a correct id and 1=1 is an always correct statement. This will always satisfy the query, and all information related to that SQL query can be obtained.
Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. This helps us create an SQL statement that always resolves to TRUE. SQL statements can be simple or complex and can be numerical or in string form. Some examples of attacks related to SQL injections are as follows: -
These applications take the input from the select box and insert it at the end of a pre-formed SQL command, with the help of 101 or 1=1 (in numerical-based) and Lim’ OR ‘1’=’1(in string-based), it always resolves to be true, and all the data becomes entirely accessible as shown below:
Two more examples related to SQL injections are:-
In these attacks, the only output returned by the webpage is whether a given account exists or not. Therefore, we cannot simply request the pin number for this account. We have to guess an existing pin number by checking the conditions. Here we have to use compound statements and ASCII concepts to check the range of numbers or alphabets in which the account number exists, like 101 AND ((SELECT pin FROM pins WHERE cc_number=’1111222233334444') > 10000 );(for blind numerical) or 101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number=’4321432143214321'), 1, 1) < ‘H’ );(for blind string). These attacks are mainly to inject SQL compound statements that we can use as a true/false statement. So, by using true/false statements multiple times, we get the correct account number.
2. Command Injection:
The application is using a system command to return the contents of a file. Append “ & netstat -an & ipconfig to the Helpfile parameter. Do not forget the double quote! The result contains the output of the command netstat and ipconfig.
3. Log Spoofing:
This lesson accepts any input for a username and appends the information to the log file.
Enter for username the text: smith Login Succeeded for username: admin. The text is added to the same line, not a new line. But any input is allowed.
In this way, you can inject carriage return (%0d) and line feed (%0a) to the application. So, Fill out the text for the username: Smith%0d%0aLogin Succeeded for username: admin or you can try to inject a malicious JavaScript to the log file, which will be viewed by the administrator using a browser like Smith%0d%0aLogin Succeeded for username: admin <script>alert(document.cookie)</script>
4. Xpath Injection:
XPath is an attack where malicious user input can grant unauthorized access or reveal sensitive information such as XML document structure and content. XPath injection attacks are much more adaptable and ubiquitous. Remember that the data is stored in XML format.
Injecting Smith’ or 1=1 or ‘a’=’a will log you in as the system's first user. Password is a required field, so there you can enter whatever you want.
This is what the server gets:
expression = “/employees/employee[loginID/text()=’Smith’ or 1=1 or ‘a’=’a’ and passwd/text()=’password’]”
And this is how the server interprets it:
expression = “/employees/employee[ ( loginID/text()=’Smith’ or 1=1 ) OR ( ‘a’=’a’ and passwd/text()=’password’ ) ]”
5. Database Backdoors:
Databases are used as a backend, medium of storage, and as a place to store malicious activities such as a trigger. A trigger is called by the database management system upon the execution of a database operation like insert, select, update or delete. So, in the below form, the input is not validated; thus, it becomes easy to do an SQL Injection.
E.g., CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email=’john@hackme.com’WHERE userid = NEW.userid
Mitigation Techniques: -
It is always good practice to sanitize all input data, especially data used in OS commands, scripts, and database queries, even if the threat of SQL injection has been prevented in some other manner.
The following are some of the main techniques for mitigation of injection flaws -
1. Input Validation: The developer ensures that the application accepts only legitimate input. For input validation, we should restrict the inputs to only regular expressions used everywhere — input the name, date of birth, email, and more. Regular expressions are patterns used to match character combinations (likewise, one can reject those characters that do not fulfil the requirements). So, restricting only to regular expressions rather than inputting anything in the backend is far better as it prevents almost all vulnerabilities.
2. Parameterized Statements: After applying the input validation method, we filter through all the inputs, but there is still a good chance that an attack pattern exists which we haven’t considered with the potential to sneak in through your own character filtering logic. Parameterized queries prevent an attacker from changing the intent of a query, and enable the SQL interpreter to distinguish clearly between code and data.
As seen below, this is the best method to prevent injection flaws, as we can map values in the array to their placeholders (the question marks) in the same order as they are passed. If we don’t prepare the SQL query, MySQL will execute the string exactly how it was entered.
3. Stored Procedure
A stored procedure is a prepared SQL code that can be saved, such that code can be reused over and over again. In the case a query contains sensitive information, we can avoid users from actually seeing the query run by using stored procedures. Users may simply know the functionality of the stored procedure but not know the actual query written. This helps mitigate attacks and also gives control of who may execute the stored procedure, thus improving the security of the web app.
Acknowledgement
A special thank you to my mentors Yash Kumar Gupta and Meghna Kashyap of ACM NITK for having guided me through the course of my project work & having assisted me with resources.
