Developpez.com - Microsoft DotNET
X

Choisissez d'abord la catégorieensuite la rubrique :


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.

info 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".


.Net



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 :

info 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.

warning 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.



Valid XHTML 1.1!Valid CSS!

Copyright © 2007 Ronald Vasseur. Aucune reproduction, même partielle, ne peut être faite de ce site et 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.

Responsable bénévole de la rubrique Microsoft DotNET : Hinault Romaric -