- Is XSS Vulnerability Possible on Mobile Apps - 17/04/2024
- Difference Between Privilege Escalation Attack and IDOR Attack - 04/03/2024
- Exploring TISAX Version 6 – A Comprehensive Guide - 10/01/2024
Test cases for SQL Injection via ORM Sink
What is an SQL injection?
SQL injection (SQLi) is a major or one of the top OWASP application security weakness that allows attackers/hackers to inject, gain control in an application’s database and letting them access or delete data, change an application’s data-driven behaviour or flow, and do other undesirable things by tricking the application through injections into sending unexpected SQL commands.
SQL injection weaknesses or flaws occur when an application uses untrusted data or data entered into web form fields, as part of a database query or when the user input is not sanitized. Once the application fails to properly sanitize this untrusted data before adding it to an SQL query, an attacker can include their own constructed SQL commands which the database will execute if the application is tricked. Such SQLi vulnerabilities exist and are easy to prevent, yet SQLi remains one of the top OWSP flaws or application risk, and many organizations remain vulnerable to potentially damaging data breaches resulting from SQL injection.
What is an ORM?
Object-relational mapping (ORM) is a concept or a mechanism that addresses , accesses and manipulates objects without considering how the objects relate to their data sources and how they further communicate with them. ORM allows programmers to maintain a consistent view or schema of objects over time, even as the sources that are to deliver them, the sinks that are destined to receive them and the applications that have the capability to accesses them.
Based on the concept of abstraction, ORM manages the mapping between a set of objects -relational databases, XML repositories, sources and sinks, and simultaneously hides often, the changing details of related interfaces from developers and the their code.
ORM performs hiding and encapsulation in the data source itself, so that when there is a change in data sources or their APIs, only the ORM needs to change to keep up—not the applications that use ORM. This helps the developers take advantage of new classes as they become available and also makes it easy to extend ORM-based applications. Also, ORM changes tends to incorporate new technology and capability without requiring changes to the code for related applications and automatically generating a part of the configuration code.
What is an ORM sink?
In computer science terminology, a sink, event sink or data sink is understood as a class or a function that is designed to receive incoming events from another object or function. This is commonly implemented and referred in C++to as callbacks. Other Object-oriented languages, such as Java and C#, have built-in support for sinks by allowing events to be fired to delegate functions. This function is most widely used in an ORM framework which gives a call to other functions internally for an application.
What are the different ORMs used?
Refer the following table for understanding what are the different frameworks used for the respective programming languages :
What are the Injection techniques for ORM frameworks?
ORM Injection is of a kind, an attack using SQL Injection against an ORM framework generated data access object model. From the perspective of a tester, this attack is more identical to an SQL Injection attack. However, the injection vulnerability does exist in code generated by the ORM tool.
An ORM is referred to as an Object Relational Mapping tool. It can be used to fasten the object oriented development within the data access layer of software applications, including web applications. The advantages of using an ORM tool includes quick generation of an object layer in order to communicate to a relational database, standardized code templates for these objects, and a set of safe functions/procedures to protect against SQL Injection attacks. ORM generated objects can use SQL and in some cases, a variant of SQL, to perform CRUD (Create, Read, Update, Delete) operations on a database. It is also possible for a web application using ORM generated objects to be vulnerable to SQL Injection attacks or ORM injections if methods can accept unsanitized input parameters.
In this case, we have demonstrated using NHibernate framework installed on the .NET web page as the front end and back end as the MySQL. We know, NHibernate’s HQL supports SELECT, inner and outer JOIN, WHERE, HAVING, simple GROUP BY, UNION, ORDER BY and self-joins.
HQL does not support recursion, common table expressions, window functions, derived tables, other set operators, table functions, array or structured types, APPLY/OUTER APPLY, CROSS JOIN, GROUP BY CUBE/ROLLUP/GROUPING SETS, FULL OUTER JOIN.
Few rules were considered while constructing the test cases for SQL injection as well as HQL injection. The rules are as follows:
• NHibernate escapes char ‘ with “ . Chars ‘’ are considered ‘ escaped char by HQL and an ‘’ in MySQL.
• MySQL escapes char ‘ with \’ . Chars \’ are considered \’ by HQL (\ is normal for HQL ), but ‘ (escaped quote) by MySQL.
The constructed test cases are mentioned as follows :
