Testing for ORM Injection (OTG-INPVAL-007)

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

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

Description

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

Black Box testing and example

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 and example

If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and test 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.

References

Whitepapers

• References from Testing for SQL Injection are applicable to ORM Injection
• Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping
  
• OWASP Interpreter Injection

Tools

• Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43
  
• Hibernate http://www.hibernate.org
  
• NHibernate http://www.nhibernate.org
  
• Also, see SQL Injection References