Difference between revisions of "Testing for ORM Injection (OTG-INPVAL-007)"

From OWASP
Jump to: navigation, search
m (Updated link to Nhibernate)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:OWASP Testing Guide v4}}
 
{{Template:OWASP Testing Guide v4}}
  
== Brief Summary ==  
+
== 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.  
 
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.
 
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
 
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 ==
+
==How to Test==
 +
=== Black Box testing ===
 
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see [[Testing for SQL Injection  (OWASP-DV-005)|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.
 
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see [[Testing for SQL Injection  (OWASP-DV-005)|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 tests web applications that use this tool, there is a higher probability of successfully attacking the application.  Patterns to look for in code include:
+
=== 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)
 
* Input parameters concatenated with SQL strings. This code that uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)
Line 20: Line 26:
  
 
Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.
 
Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.
 +
 +
 +
==Tools==
 +
* Hibernate http://www.hibernate.org<br>
 +
* NHibernate http://nhforge.org/<br>
  
 
== References ==
 
== References ==
Line 26: Line 37:
 
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping<br>
 
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping<br>
 
* [[Interpreter Injection#ORM Injection|OWASP Interpreter Injection]]
 
* [[Interpreter Injection#ORM Injection|OWASP Interpreter Injection]]
 
'''Tools''' <br>
 
* Hibernate http://www.hibernate.org<br>
 
* NHibernate http://nhforge.org/<br>
 
 
 
[[Category:FIXME|link not working
 
 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 <br>
 
 
 
]]
 

Latest revision as of 07:03, 8 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

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