Crypter les chaînes de connexion dans le fichier Web.config (en cours de rédaction)
Date de publication : 27/09/2007
Par
Ronald VASSEUR (autres articles)
Nous allons voir dans cet article comment sécuriser les chaînes de connexion
aux bases de données dans les fichiers de configuration des application
ASP.Net 2.0 (Web.config) en cryptant leur valeur. Pour cela nous aurons le
choix entre DPAPI et l'algorithme RSA.
Introduction
1. Pour mieux comprendre
2. Concrètement comment cela se passe ?
Conclusion
Introduction
Comme vous le savez certainement déjà les applications ASP.Net
utilisent des fichiers XML nommés Web.config pour stocker un certain
nombre de paramètres d'application. Avec la version 2.0 du Framework
.Net et d'ASP.Net le nombre de paramètres gérés par ces fichiers de
configuration à considérablement augmenté, de plus, il est désormais
beaucoup plus facile d'accéder, de gérer et même d'étendre ces fichiers
de configuration, ainsi on peut y stocker très facilement presque
quasiment tout ce que l'on veut. Ces fichiers ASP.Net ne sont
accessibles que directement depuis le serveur, c'est-à-dire qu'un
client se connectant à un serveur Web ne peut pas accéder au contenu
de ce fichier. Mais ces fichiers contiennent des informations souvent
sensibles telles qu'une chaine de connexion à une base de données, ou
même les identifiants permettant de se connecter à toute autre ressource...
Bref, autant dire que ces fichiers sont critiques et potentiellement un point
faible des applications ASP.Net, du moins un point qui est à surveiller
tout particulièrement. Deux niveaux de protections valant souvent mieux
qu'un, une pratique courante est de crypter les valeurs sensibles stockées
dans ce fichier. Il ne s'agit ici pas de crypter en bloc tout le fichier,
cela ne serait pas souhaitable, entre autre pour des raisons de performances.
De plus, il faut savoir distinguer les informations sensibles des informations
qui le sont moins. ASP.Net en version 2.0 à été une évolution majeure dans le
sens où la quantité de code à écrire à été très fortement réduite par rapport
à la version 1.1, chez Microsoft on parle parfois de 70% en moins, mais comme
tout chiffre général il est à prendre avec précautions, cela dépend beaucoup
du type d'application et du contexte de développement. Mais néanmoins il est
vrai que le déclaratif à beaucoup progressé, la version 2.0 nous épargne
beaucoup de code pour les opérations courantes et/ou répétitives. La sécurisation
des données sensibles stockées dans ces fichiers de configuration n'a pas
échappé à la règle, et il est désormais possible de crypter ces valeurs
automatiquement sans devoir écrire une seule ligne de code, chose qui n'était
tout simplement pas possible en ASP.Net 1.1.
 |
Remarque : on parle de déclaratif quand il s'agit de déclarer certains
paramètres par exemple dans des fichiers de configurations plutôt
que de le "coder en dur".
|
1. Pour mieux comprendre
Au cours de cet article nous allons voir comment crypter, et bien
évidemment décrypter les valeurs sensibles stockées dans les fichiers
de configuration. Vous allez le voir, ASP.Net 2.0 peut réaliser cela
de façon transparente, et de plus la mise en place de cette ligne
supplémentaire de sécurité est très aisée. Même si crypter les valeurs
sensibles contenues dans les fichiers de configuration n'est pas en
soit une garantie absolue, je pense que cela est indispensable, de
plus cela participe à la sécurité globale de l'application. En sécurité
rien n'est totalement suffisant, mais de nombreuses choses sont
nécessaires.
ASP.Net 2.0 nous offre deux manières de sécuriser le contenu sensible
des fichiers de configurations. D'ailleurs quand je parle de fichier
de configurations ASP.Net, je parle aussi bien des fichiers au niveau
des applications (web.config) que celui du niveau supérieur, le
machine.config. Les deux solutions apportées par ASP.Net 2.0 en la
matière reposent sur DPAPI, qui est l'API de chiffrement intégrée à
Windows, et sur l'algorithme RSA qui est intégré directement dans le
Framework .Net. Globalement les deux solutions se valent à la
différence suivante. DPAPI étant intégré directement dans le système
d'exploitation le cryptage d'un fichier de configuration va s'appuyer
sur la machine (ou l'utilisateur), c'est-à-dire les informations
cryptées ne seront décryptables que sur cette même machine (ou
uniquement par l'utilisateur qui à crypté ces données), cela peut
être un avantage pour certains, mains un inconvénient pour d'autres,
par exemple si une application doit être basculée rapidement d'une
machine à une autre, ou alors si par exemple l'application doit être
répartie sur plusieurs serveurs pour faire face à des contraintes de
charge. RSA utilise quand à lui une clé publique qui peut être export
ée, ce qui le rend plus souple, en effet il suffit d'importer la clé
sur une autre machine pour pouvoir crypter et décrypter les informations
sensibles dans le fichier. Autre détail, mais je pense que vous l'aurez
déjà deviné, ces processus d'encryptage et de décryptage de données
sensibles sont totalement transparents pour le développeur, il n'a donc
pas à s'occuper de ces traitements. Comme très souvent avec .Net, le
développeur peut se focaliser sur la problématique métier que plutôt
que sur des contraintes de plateformes et de systèmes.
Donc même si DPAPI (pour Data Protection Application Programming Interface)
et RSA ont la même finalité on voit que l'on choisira l'un ou l'autre des
procédés en fonction des différentes contraintes de son application. Voyons
tout d'abord voyons un peu plus en détails à quoi ressemble un fichier de
configuration, qui par exemple contient une chaine de connexion à une base
de données.
| Fichier Web.config |
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings>
<add name="aConnectionString" connectionString="Initial Catalog=aDataBase; data source=aServer; Integrated Security=SSPI;"
providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<compilation debug="false" />
<authentication mode="Windows" />
</system.web>
</configuration>
|
Vous le voyez, des informations sensibles telles que l'identifiant,
le mot de passe, le nom ainsi que l'adresse de cette base de données
sont stockées en clair. De telles informations sont critiques, et un
utilisateur malveillant ayant un accès direct au fichier, et donc à
ces informations, pourrait avoir accès aux données et même y causer
de sérieux dégâts. C'est pourquoi il est important de ne pas laisser
d'informations aussi sensibles en clair dans un fichier de configuration.
Voyons maintenant concrètement comment crypter les valeurs sensibles
relatives à la chaine de connexion à la base de données contenues
dans le fichier Web.Config.
2. Concrètement comment cela se passe ?
Pour crypter le contenu d'un fichier web.config il y a deux solutions,
on code tout le processus en dur ce qui est long et relativement complexe
ou alors on automatise plus ou moins tout cela. Nous allons voir ici la
manière qui me semble la plus logique, vu qu'ASP.Net peut rendre le
processus totalement transparent pour l'utilisateur mais aussi le
développeur pourquoi s'en priver ? Je vais donc vous présenter comment
réaliser cette opération grâce à un outil bien connu des développeurs
ASP.Net, je veux parler d'aspnet_regiis.exe. Cet utilitaire en ligne
de commande va permettre de crypter le contenu sensible des fichiers
de configuration, mais aussi évidemment de le décrypter. Cet outil
supporte deux providers, DPAPI et RSA. Que ce soit pour l'un comme
pour l'autre le processus reste globalement le même. La commande de
base pour crypter le contenu va consister à passer en paramètres le
nom de la section du fichier à sécuriser, l'emplacement du fichier
et le provider à utiliser. Voici quelques exemples de commandes
couvrant la majorité des situations courantes :
|
Je vous renvoie au MSDN, et plus particulièrement à cette page pour
avoir la liste complète des arguments qui peuvent être passé à cet utilitaire.
|
Une fois que la commande s'est correctement effectuée le contenu du fichier
de configuration à changé. Voyons plus en détails ces changements :
| Fichier protégé avec DPAPI |
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAA1oHd61oHEG6Oylb2oIzwQQAAAAC
AAAAAAADZgAAqAAAABAAAAAmnQal+FDi86vgvgA0fCnZAAAAAASAAACgAAAAEAAAAHWqsAfTP8Opv0O
KBoXbNx2oAQAAnq10zHcIkk5FtnQII5o5OalUkuAEnjvr9YQvRmBL79tXuOt0EqMQIo217RNeBmG0l8
063y0WLD9mPtWaXbWOe0wNkIrr1ETSH0rI7N40sfQvx62Za6QMxlpv5dUlFx8tKGfIVCZh1ARa2xtfO
v9kPyYCSwndKBVzfjNJ3x7MkgHkAXHB1ftwtnVnhG22QG4zJyHH6Y020IZaCn9LkbMHSH+BXA4eZ5Eq
ZkhGYwu1QZYgHAEZtjVjZwmIMSx09nLaU0mK/032MKFGoP61vGfLJVTZGv529tcW7sef7PetysAYm9b
qWmMk2GMl4N8FbKzERDrR2xq0NMp1x0uRbOJmSCr7zkdGnUP7Iu9+7FF5eB+Ath5vq0Wt26yrppbn4e
HT3X6Sz6jNLQ4Th1bB5VtCne0IQoBvrc1+pELHhTSQ2FpynWHIKwMhc55R0w6gHmcn0vvVRGcTQlgwc
WvlzN8jsLPffB0D6faBchJW4smTDenKIKXd5nom6hv3ANw5W+vy8U2KfiY9WGrPDKOHE7TUSUVkS30e
Ek26J3n/LPi1p24LSNWXRXJ2ihQAAACKfzfb4Wmi+5BR94n0ecpxq8ooJQ==</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
<system.web>
<compilation debug="false" />
<authentication mode="Windows" />
</system.web>
</configuration>
|
| Fichier protégé avec RSA |
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>dqasVzOjPnGU72BQBiXCvl5iO2rVaLowVPBi3qLehvCB3WYRxQqt+2
MbdBu5jFfyuxtHOt9z+hJ53JmoYqITWR0V37XcxNsW1eCvNwdM03lM1YcLwURqVgNN19tDZMS
oyZKb4K7oVkG2LVz2NJaWfWj83seaJYquNxvecBhE3kM=</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>slZHGjwG56A4z9qwIO9lTCfQJ0kkpwYXa9JdFw7JRA1SvNUm9CvdvNLwjbj52n
GskVYNQYxKg97W49HC4F0GuGzv6OD1hO+qo/QwY9CItf0WkC5/u3uH/dgMNeYVUimh++OoIji0yxhTKso/
WpavN+xkolCJA9zuzDib4q5hY4JJBx/OTLn5ahDDTppe3bTI+Kb1W2b6Fu/IJRDVxrCXp9udbnyK1vwkZ7
gVQSmSxLnSE4hyaQsCXLnqU1o3fO8OQDic3w2rX7wIcln9s6ye7gWvaPch1dvvhOYNIG2Ze9I=</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
<system.web>
<compilation debug="false" />
</system.web>
</configuration>
|
De nouvelles balises sont apparues dans le fichier, on voit de plus
que la valeur en clair à disparue et l'on a désormais une valeur
cryptée. Ces nouvelles balises vont ainsi indiquer à la CLR qu'il
s'agit de données cryptées, et quel provider il faut employer pour
les décrypter.
ASP.Net va se charger de décrypter automatiquement les valeurs nécessaires,
ainsi le fichier Web.config sera sécurisé sans qu'il y ait le moindre impact
que ce soit pour l'utilisateur comme pour le développeur.
 |
Remarque : il n'est pas possible d'encrypter des données sensibles
stockées à l'intérieur des balises suivantes :
|
Conclusion
Comme vous l'avez vu sécuriser les informations sensibles contenues
dans le fichier de configuration est très simple depuis la version
2.0 d'ASP.Net il ne faut donc plus s'en priver. La seule chose qu'il
faut étudier est le choix du provider, il faudra bien prendre en
compte les spécifications de votre application avant de faire un choix.
Copyright © 2007 Ronald Vasseur.
Aucune reproduction, même partielle, ne peut être faite
de ce site ni de l'ensemble de son contenu : textes, documents, images, etc.
sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à
trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.
