Testing for ORM Injection
Summary
Object Relational Mapping (ORM) Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM layer.
The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardize code templates for these objects, and that they usually provide a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases, a variant of SQL, to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.
How to Test
ORM layers can be prone to vulnerabilities, as they extend the surface of attack. Instead of directly targeting the application with SQL queries, you’d be focusing on abusing the ORM layer to send malicious SQL queries.
Identify the ORM Layer
To efficiently test and understand what’s happening between your requests and the backend queries, and as with everything related to conducting proper testing, it is essential to identify the technology being used. By following the information gathering chapter, you should be aware of the technology being used by the application at hand. Check this list mapping languages to their respective ORMs.
Abusing the ORM Layer
After identifying the possible ORM being used, it becomes essential to understand how its parser is functioning, and study methods to abuse it, or even maybe if the application is using an old version, identify CVEs pertaining to the library being used. Sometimes, ORM layers are not properly implemented, and thus allow for the tester to conduct normal SQL Injection, without worrying about the ORM layer.
Weak ORM Implementation
A vulnerable scenario where the ORM layer was not implemented properly, taken from SANS:
List results = session.createQuery("from Orders as orders where orders.id = " + currentOrder.getId()).list();
List results = session.createSQLQuery("Select * from Books where author = " + book.getAuthor()).list();
The above didn’t implement the positional parameter, which allows the developer to replace the input with a ?. An example would be as such:
Query hqlQuery = session.createQuery("from Orders as orders where orders.id = ?");
List results = hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list(); // 0 is the first position, where it is dynamically replaced by the string set
This implementation leaves the validation and sanitization to be done by the ORM layer, and the only way to bypass it would be by identifying an issue with the ORM layer.
Vulnerable ORM Layer
ORM layers are code, third-party libraries most of the time. They can be vulnerable just like any other piece of code. One example could be the sequelize ORM npm library which was found to be vulnerable in 2019. In another research done by RIPS Tech, bypasses were identified in the hibernate ORM used by Java.
Based on their blog article, a cheat sheet that could allow the tester to identify issues could be outlined as follows:
| DBMS | SQL Injection |
|---|---|
| MySQL | abc\' INTO OUTFILE -- |
| PostgreSQL | ` = ′ =' =′=chr(61) |
| Oracle | NVL(TO_CHAR(DBMS_XMLGEN.getxml('select 1 where 1337>1')),'1')!='1' |
| MS SQL | 1<LEN(%C2%A0(select%C2%A0top%C2%A01%C2%A0name%C2%A0from%C2%A0users) |
Another example would include the Laravel Query-Builder, which was found to be vulnerable in 2019.
396
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
