Testing for ORM Injection
Last updated
Last updated
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.
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.
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 chapter, you should be aware of the technology being used by the application at hand. Check this .
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 , without worrying about the ORM layer.
A vulnerable scenario where the ORM layer was not implemented properly, taken from :
The above didn't implement the positional parameter, which allows the developer to replace the input with a ?
. An example would be as such:
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.
MySQL
abc\' INTO OUTFILE --
PostgreSQL
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)
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 which was found to be vulnerable in 2019. In another research done by , bypasses were identified in the .
Based on their , a cheat sheet that could allow the tester to identify issues could be outlined as follows:
`=chr(61)
Another example would include the , which was found to be .
]