Création d’un mauvais exemple

Dans l’article principal, j’ai sélectionné une page de
connexion basée sur un formulaire Web pour un certain
nombre de raisons. J’ai retenu cet exemple en partie afin de
créer un effet de choc. En effet, il est toujours salutaire de
rappeler que, même si l’authentification basée sur des formulaires
Web peut être aussi fiable que n’importe quelle
autre forme d’authentification, elle comporte certaines vulnérabilités.
J’aurais pu utiliser une zone de saisie de recherche,
qui constitue probablement le deuxième point d’attaque
le plus probable.


Parmi les éléments retenus pour cet article, une
deuxième tactique critiquable a consisté à  incorporer dans la
page d’exemple les informations d’identification de
connexion à  la base de données réelles utilisées par le
compte de service (sa) de mon application Web aux fins de
portabilité. Bien que je signale l’inconvenance de cette approche
plus loin dans l’article, vous avez probablement noté
qu’en exposant mes informations d’identification, j’ai
contourné une couche de sécurité. Mais la dissimulation des
informations d’identification de chaîne de connexion sort du
cadre de cet article. A l’évidence, les informations d’identification
n’ont rien à  faire sur la page, mais le fait de les placer
ici facilite la compréhension de l’exemple.

En revanche, quid du fait que j’ai employé un compte de
service au lieu des informations d’identification de l’utilisateur
pour l’accès à  la base de données ? La réponse à  cette
question comporte deux volets. Premièrement, la manière
dont j’ai authentifié les informations d’identification de l’utilisateur,
voire le fait de le faire, n’a pas d’importance.
L’exemple de page de connexion vous rappelle que les applications
basées sur Internet sont intrinsèquement non sécurisées,
à  moins que vous preniez toutes les mesures pour les
sécuriser. Si vous envisagez d’autoriser les requêtes anonymes
sur une base de données de produits, vous acceptez
les saisies utilisateur. Si vous conservez votre liste des
comptes clients ou utilisateurs dans SQL Server, comme c’est
le cas avec de nombreuses applications Web, votre application
utilise un modèle similaire à  celui repris dans notre
exemple. SQL Server authentifie les comptes définis dans
une table SQL Server uniquement après la connexion d’un
compte de service à  la base de données.

Deuxièmement, l’utilisation d’un compte proxy en tant
que partie d’une application Web est une pratique que
Microsoft supporte pleinement. Une bonne référence qui
traite de l’utilisation des comptes de service est la section
« Authentication in Data Access Components » du chapitre 3
du guide de référence Microsoft Patterns and Practices
« Application Architecture for .NET: Designing Applications
and Services » (http://msdn.microsoft.com/library/default.
asp?url=/library/en-us/dnbda/html/AppArchCh3.asp).

Selon le guide, il est approprié d’autoriser l’accès par le biais
de comptes de service dans les situations pour lesquelles
vous n’avez peut-être pas d’ensemble valide d’informations
d’identification de compte pour chaque utilisateur ou pour
lesquelles vous souhaitez utiliser les pools de connexions aux
fins d’évolutivité. Les sites Internet à  accès public constituent
des exemples où ces circonstances peuvent se produire. Afin
d’optimiser la mise en pool de connexions, ADO.NET impose
le recours à  une chaîne de connexion commune pour chaque
connexion faisant partie du pool. Le point essentiel à  retenir
est que, indépendamment du type d’authentification
employé, un utilisateur anonyme va interroger la base de
données de votre application.

Enfin, vous vous demandez peut-être si vous devez employer
l’authentification SQL Server ou l’authentification
Windows. La deuxième solution présente plusieurs avantages,
mais il faudrait un autre article pour les décrire. MRAO
(Microsoft Reference Architecture for OpenHack) fournit un
bon exemple de l’utilisation efficace du compte utilisateur
ASP.NET pour l’authentification SQL Server. Mais, même si
j’avais appliqué les meilleures pratiques recommandées par
MRAO, je serais encore en mesure de reproduire l’exemple
d’attaque de l’article principal, y compris l’utilisation d’une
page de connexion. Il existera toujours des vulnérabilités.
L’exemple de l’article principal illustre plusieurs mauvaises
pratiques de sécurité et vous permet de comprendre facilement
les vulnérabilités qu’elles créent.