Nouveaux risques et dangers

merveille à  l’interopérabilité
entre systèmes basés sur le Web.
Les sociétés exposent les fonctions
et transactions internes à 
d’autres systèmes – internes et
externes. Les développeurs peuvent
exposer des fonctions
comme des services Web de
nombreuses manières différentes,
dont certaines sont
simples mais dangereuses. Par
exemple, les releases Web de
XML for SQL Server 2000
(SQLXML) étoffent les possibilités
intégrées de SQL Server avec
le moyen de créer des services
Web XML à  partir des procédures
stockées de SQL Server. Avec
SQLXML, vous pouvez appeler une
procédure stockée nommée, par
exemple, sp_update_company_customers
en utilisant le modèle XML que
montre le listing 1.
Avec ce modèle, construire un service
Web basé sur des procédures stockées
est facile – trop facile. Le développeur
initial a probablement écrit la
procédure stockée sp_update_ company_
customers pour qu’on ne l’utilise
que dans une application base de
données et dans des environnements
contrôlés. Supposons que la procédure
stockée sp_update_ company_
customers utilise le nom de la société
et met à  jour tous les clients de celle-ci
en concaténant le nom de la société à 
la clause WHERE. Dès lors qu’un développeur
construit un nouveau service
Web autour de cette procédure stockée,
n’importe qui peut appeler
sp_update_company_customers à  partir
de n’importe où. Un pirate futé peut
appeler ce service Web et transmettre
une chaîne de requête comme ACME,
avec DROP TABLE customers comme
argument. Résultat : suppression d’une
grande quantité de données et, probablement,
tout le système à  genoux.
A l’évidence, les concepteurs de la
procédure stockée décrite et du service
Web devraient avoir soigné davantage
la validation de l’entrée et la mise
en oeuvre d’un contrôle de sécurité
propre à  l’application dans la procédure
stockée. En réalité, la plupart des
attaques de systèmes, y compris la
classe de problèmes par débordement
de buffer que les produits Microsoft
comme SQL Server ont subi, tirent
parti des paramètres non vérifiés qui
résultent quand les développeurs
prennent des raccourcis. Donc, même
si une application bien conçue, bien
codée et bien testée, est théoriquement
très sûre, les meilleures pratiques
de sécurité actuelles obligent à 
utiliser des couches de sécurité supplémentaires
externes aux applications
et qui peuvent s’ajouter aux bonnes
habitudes de coding.