{{Modèle:Testing Guide}}


# Résumé #


L'injection ORM est une attaque par injection SQL contre le modèle de données objet ORM . Du point de vue d'un testeur, cette attaque est pratiquement identique à une attaque par injection SQL. Cependant, la vulnérabilité d'injection existe dans le code généré par l'outil ORM.


# Description #


ORM est un outil de mapping objet-relationnel. Il est utilisé pour accélérer le développement orienté objet dans la couche d'accès aux données des applications logicielles, y compris les applications Web. Les avantages d'utiliser un outil d'ORM comprennent la génération rapide d'une couche objet pour communiquer avec une base de données relationnelle, en utilisant des modèles de code normalisées pour ces objets, et le plus souvent un ensemble de fonctions de sécurité pour se protéger contre les attaques par injection SQL. Les objets ORM générés peuvent utiliser SQL ou, dans certains cas, une variante du SQL, pour effectuer des opérations CRUD (Create, Read, Update, Delete) sur une base de données. Il est possible, cependant, pour une application Web  utilisant objets ORM générés d'être vulnérable aux attaques par injection SQL si les méthodes peuvent accepter des paramètres d'entrée non épurées.

Les outils ORM comprennent Hibernate pour Java, Nhibernate pour .NET, ActiveRecord pour Ruby on Rails, EZPDO pour PHP et bien d'autres. Pour une liste assez complète d'outils ORM, voir http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software


# Test boîte noire #


Le test de vulnérabilités d'injection ORM  boîte noire est identique au test d'injection SQL (voir Test pour injection SQL). Dans la plupart des cas, la vulnérabilité dans la couche ORM est un résultat de code personnalisé qui ne valide pas correctement les paramètres d'entrée. La plupart des outils ORM fournissent des fonctions de sécurité pour échapper les entrées utilisateur. Toutefois, si ces fonctions ne sont pas utilisées, et si le développeur utilise des fonctions personnalisées qui acceptent des entrées utilisateur, il peut être possible d'exécuter une attaque par injection SQL.


# Test boîte grise #


Si un testeur a accès au code source d'une application web, ou peut découvrir des vulnérabilités d'un outil d'ORM et d'applications Web qui utilisent  cet outil, il y a une plus grande probabilité de d'attaquer l'application avec succès . Les modèles à rechercher dans le code sont:


## Les paramètres d'entrée concaténé avec chaînes SQL. ##


Ce code qui utilise ActiveRecord pour Ruby on Rails est vulnérable (cependant, tout objet ORM peut être vulnérable)

<code>Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"
</code>
Il suffit d'envoyer "' OR 1--" dans le formulaire où la order_date peut être saisie peut donner des résultats positifs.


# Références #



## Livres blancs ##


  * Les reéférences dans [[testing_for_sql_injection]] sont applicables àl'injection ORM  
  * //'Wikipedia// - ORM http://en.wikipedia.org/wiki/Object-relational_mapping
  * OWASP Interpreter Injection


## Outils ##


  * **Hibernate** http://www.hibernate.org
  * **NHibernate** http://nhforge.org/