Le weblogue de SeB

J’avoue que le titre de cette note est quelque peu alarmiste. C’est avant tout pour retenir l’attention et marquer les développeurs qui se croient à l’abri de ce genre d’attaque parce qu’ils utilisent Hibernate.

En effet, l’utilisation de ce framework ne vous protège pas forcément des SQL">injections SQL comme le rappelle TSS dans son article intitulé “Une légende urbaine à propos d’Hibernate“.

L’auteur explique que la création de requête SQL par concaténation de chaîne de caractères rend possible les attaques par injection de code SQL. Et ce même si vous utilisez Hibernate (contrairement à ce que certaines personnes semblent croire) ! Alors, comment s’en protéger ?

Pour empêcher les injections SQL, il suffit d’utiliser les paramètres nommés lors de la création de requête SQL. Ce genre de pratique est une bonne habitude à avoir.

Donc n’oubliez pas d’utiliser les paramètres SQL plutôt que de construire la requête SQL à la main ! Ce message ne s’adresse pas seulement aux utilisateurs d’Hibernate, ni qu’aux développeurs Java par ailleurs.

Introduction

Hibernate propose plusieurs solutions pour réaliser des requêtes en base de données. Lorsque que le développeur doit écrire une requête avec Hibernate, il a trois possibilités :

• le SQL natif
• le HQL
• l’API Criteria (et Example)

Quelle est la meilleure solution pour écrire une requête avec Hibernate ?

Solutions

SQL natif

L’un des objectifs d’Hibernate est de s’éloigner de la base de données^[1]. Or, l’utilisation du SQL natif va à l’encontre de cet objectif. De ce point de vue, le SQL natif est à éviter. Néanmoins, l’équipe du projet le conseille seulement de façon exceptionnelle pour des points qui ont besoin d’utiliser une optimisation liée spécifique à la base de données.

HQL

C’est un language propre à Hibernate qui s’inspire du SQL mais orienté objet. Il est très souple et donne accès à toutes les possibilités d’Hibernate.

API Criteria

C’est une API en Java qui permet de faire la même chose qu’avec le language HQL. Le code source à écrire est très simple.

Conclusion

Si l’on élimine le SQL natif, il reste le HQL et l’API Criteria qui font la même chose. La différence concerne le développeur :

• l’écriture de requête sous forme de chaîne de caractères
• l’appel à une API de requête

Laquelle choisir ?

• pour obtenir une meilleure souplesse en terme de développement et de maintenance
• pour atteindre les meilleures performances

Jusqu’à présent j’avais utilisé naïvement simplement Hibernate avec l’API Criteria.

Pourquoi ce choix ? Cette API est très bien faite et la syntaxe des requêtes est validée à la compilation Java. De plus, je suppose que c’est plus rapide puisque qu’il n’y a pas besoin d’analyser de chaîne de caractères pour exécuter la requête. L’analyse du choix de l’implémentation des requêtes mérite d’être poursuivie.

Valère Viandier conseille de mélanger l’utilisation du HQL et de l’API Criteria. Selon lui, toute requête statique doit être implémentée avec le HQL^[2]. Et toute requête dynamique doit être codée avec l’API Criteria. Cette dernière permet d’éviter la concaténation de String lors de la construction de la requête.

John Ferguson Smart rejoint le point de vue de V. Viandier dans son article sur l’utilisation de l’API Criteria vis-à-vis de HQL. Puisque selon ce dernier, l’API doit être utilisée pour des requêtes dynamiques. Et inversement HQL doit être utilisé pour des requêtes statiques. Celà permet d’externaliser les requêtes qui pourront être mises en cache, analysées par un administrateur de base de données, etc…

L’utilisation de deux languages de requête peut troubler^[3] beaucoup de personnes^[4]. Pourtant, pour tirer parti des points forts de chaque language, il est tout à fait résonnable d’utiliser à la fois le HQL et l’API Criteria.

Quelqu’un a-t-il un avis sur le sujet ? Ou des retours d’expériences ?

Notes

[1] En terme d’implémentation.

[2] Idéalement dans les fichiers de configuration de mapping hbm.xml.

[3] La maintenance applicative semble moins évidente.

[4] Moi le premier dans un premier temps.