Powered by GitBook

Owasp Testing Guide v4

Testing for ORM Injection (OTG-INPVAL-007)

Summary

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 tool.

An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects, and usually 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 tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

How to Test

Black Box testing

Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see Testing for SQL Injection). In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM tools provide safe functions to escape user input. However, if these functions are not used, and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

Gray Box testing

If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and tests web applications that use this tool, there is a higher probability of successfully attacking the application.

Patterns to look for in code include:

  • Input parameters concatenated with SQL strings. This code that uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)
    Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"
    Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

Tools

References

Whitepapers