> Data > Utilisation d’ADO pour un typage fort

Utilisation d’ADO pour un typage fort

Data - Par iTPro.fr - Publié le 24 juin 2010
email

Mis en ligne le 11/05/2005 - Publié en Juin 2004

Le plein de conseils...
 

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.

Téléchargez gratuitement cette ressource

Endpoint Security : Etude IDC Enjeux & Perspectives

Endpoint Security : Etude IDC Enjeux & Perspectives

Quel est l'état de l'art des solutions de Endpoint Security et les perspectives associées à leur utilisation ? Comment garantir la sécurité des environnements sensibles en bloquant au plus tôt les cyber attaques sophistiquées, avant qu’elles n'impactent durablement vos environnements de travail ?

Data - Par iTPro.fr - Publié le 24 juin 2010