4.8.7 Tester les injections ORM (OTG-INPVAL-007)

From OWASP
Jump to: navigation, search

!

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

L'injection ORM est une attaque utilisant une injection SQL contre un modèle d'accès aux données généré par un ORM. du point de vue du testeur, cette attaque est sensiblement identique à une attaque par injection SQL. Cependant, la vulnérabilité se situe dans le code généré par l'outil ORM.


Un ORM est un outil de correspondance objet / modèle relationnel. Il est utilisé pour faciliter les développements orientés objets avec les accès aux données, pour tout type d'application, y compris web. Utiliser un ORM a de multiples avantages, dont la génération rapide d'une couche objet pour communiquer avec une base relationnelle, des modèles de code standardisés pour ces objets, et souvent un ensemble de fonctions sûres pour la protection contre les attaques par injection SQL. Les objets ORM peuvent utiliser SQL, ou dans certains cas une variante de SQL, pour procéder à des opérations CRUD (Création, Lecture, Modification, Suppression) sur une base de données. Il est cependant possible à une application web utilisant des objets générés par un ORM d'être vulnérable aux attaques par injection SQL, si les méthodes de ces objets acceptent des paramètres d'entrées non validés.


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 raisonnablement complète des outils ORM, voir http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

Comment tester

Test en boite noire

Les tests en boite noire pour les vulnérabilités d'injection ORM sont identiques aux tests d'injection SQL (voir Tester les injections SQL). Dans la plupart des cas, la vulnréabilité dans la couche ORM résulte d'un code personnalisé qui ne valide pas correctement les paramètres d'entrée. La plupart des outils ORM fournissent des fonctions sûres pour échapper les entrées utilisateur. Cependant, si ces fonctions ne sont pas utilisées, et que le développeur utilise des fonctions personnalisées acceptant des entrées utilisateur, il peut être possible d'exécuter une attaque par injection SQL.


Test en boite 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 ORM et teste des applications web utilisant cet outil, il y a une plus grande probabilité de réussir une attaque sur l'application.


Les motifs à rechercher dans le code comprennent :

  • La concaténation de paramètres d'entrée avec des chaînes SQL. Ce code utilisant ActiveRecord pour Ruby on Rails est vulnérable (bien que tout ORM puisse être vulnérable)
Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Saisir simplement "' OR 1--" dans le champs order_date du formulaire peut renvoyer des résultats positifs.


Outils

Références

Whitepapers