Utilisation d’ADO pour un typage fort

Le typage fort des données est une arme précieuse
contre les attaques par injection de
code SQL. L’objet ADO Command est à  cet
égard important : il garantit non seulement
que vous passez les données appropriées, mais
que SQL Server pourra distinguer les parties
d’une requête correspondant à  du code SQL et celles correspondant
à  des données. Examinons deux méthodes d’appel
d’une procédure stockée. La procédure suivante est appelée
directement à  partir d’une page ASP :

<%
Set Conn =
Server.CreateObject
("ADODB.Connection")
Conn.open application
("connection_string")
Set RS = Conn.Execute ("exec
sp_checkloginrights " &
param1 & "," & param2 )
>%

Ce code constitue un mauvais
exemple d’appel d’une procédure
stockée à  partir de Visual Basic (VB). Il
utilise une technique de « création de
chaîne » pouvant jouer des mauvais
tours, en raison de la validation insuffisante
des saisies.

Le deuxième appel, illustré sur le
listing 3, est un exemple de code VB
utilisable pour appeler la même procédure
stockée à  partir d’une DLL COM.
Par quel moyen ce deuxième appel de
procédure procure-t-il un niveau de sécurité
accru ? La réponse réside dans le
fait que vous n’effectuez plus de « création
de chaîne », comme dans le code
ASP précédent. Dans les appels SQL
avec création de chaîne, vous générez
une chaîne de texte et vous la passez à  SQL Server au cours
d’un même appel. En revanche, dans l’exemple de la DLL
COM, vous utilisez l’objet Command pour appliquer les
types de données et vous laissez le soin à  ADO de créer la
chaîne à  votre place. Le principal avantage de l’approche VBCOM
est qu’elle intercepte toutes les erreurs provoquées par
les programmeurs d’applications frontales ne validant pas
correctement les saisies.
A noter que vous devez gérer les erreurs de manière à  ne
pas donner d’indication sur la structure de vos tables à  un attaquant potentiel. Toute erreur liée à  la base de données
doit retourner un message d’erreur générique et journaliser
les détails en vue d’une analyse par le développeur.
L’affichage de messages d’erreur ADO fournit trop d’informations
à  l’utilisateur final et pourrait s’avérer dangereuse
entre de mauvaises mains. Par ailleurs, ne partez jamais du
principe que les personnes situées à  l’autre bout effectuent
une validation en bonne et due forme. Ils pensent probablement
la même chose vous concernant. En exécutant une validation
appropriée à  tous les niveaux, un bloc de code un
tant soit peu soigné sera moins susceptible de mettre en
danger l’ensemble de votre application.