1. Introduction
Lors de la création d'applications ASP.NET 2.0, les développeurs stockent généralement des informations de configuration sensibles dans le fichier Web.config. L'exemple le plus typique est la chaîne de connexion à la base de données, mais d'autres informations sensibles incluses dans le fichier Web.config incluent les informations de connexion au serveur SMTP et les données d'identification de l'utilisateur, etc. Bien qu'ASP.NET puisse être configuré par défaut pour refuser toutes les requêtes HTTP pour les ressources de fichiers avec une extension .config, si un pirate informatique parvient à accéder au système de fichiers de votre serveur Web, des informations sensibles peuvent toujours être volées. Par exemple, vous avez peut-être accidentellement autorisé un accès FTP anonyme à votre site Web, permettant ainsi à un pirate informatique de simplement télécharger votre fichier Web.config via le protocole FTP.
Heureusement, ASP.NET 2.0 permet d'atténuer ce problème en vous permettant de chiffrer des parties sélectionnées du fichier Web.config, telles que la section <connectionStrings> ou une section de configuration personnalisée utilisée par votre application. Les sections de configuration peuvent facilement être pré-chiffrées à l'aide du codage ou de aspnet_regiis.exe (un programme en ligne de commande). Une fois chiffrés, les paramètres Web.config sont protégés des regards indiscrets. De plus, lors de la récupération par programme des paramètres de configuration chiffrés de votre page ASP.NET, ASP.NET déchiffre automatiquement la partie chiffrée qu'il lit. En bref, une fois les informations de configuration chiffrées, vous n'avez pas besoin d'écrire d'autre code ni d'effectuer d'autres actions dans votre application pour utiliser les données chiffrées.
Dans cet article, nous verrons comment chiffrer et déchiffrer par programme cette section de paramètres de configuration et examinerons l'utilisation du programme de ligne de commande aspnet_regiis.exe. Nous évaluerons ensuite les options de chiffrement fournies par ASP.NET 2.0. De plus, nous expliquons brièvement comment chiffrer les informations de configuration dans ASP.NET version 1.x.
2. Prémisse
Avant de commencer à discuter de la façon de chiffrer les informations de configuration d'ASP.NET 2.0, n'oubliez pas les points suivants :
1. Toutes les formes de chiffrement contiennent une sorte de secret, et ce secret est utilisé lors du chiffrement et du déchiffrement des données. Les algorithmes de chiffrement symétrique utilisent la même clé lors du chiffrement et du déchiffrement d'un message, tandis que les algorithmes de chiffrement asymétriques utilisent des clés différentes pour le chiffrement et le déchiffrement. Quelle que soit la technologie utilisée, le plus important est la sécurité de la clé de déchiffrement.
2. La technologie de cryptage de configuration fournie par ASP.NET 2.0 est conçue pour empêcher les pirates informatiques de récupérer vos fichiers de configuration d'une manière ou d'une autre. L'idée est que s'il y a votre fichier Web.config sur l'ordinateur du pirate informatique, il ne peut pas déchiffrer la partie cryptée. Cependant, lorsqu'une page ASP.NET sur le serveur Web demande des informations à un fichier de configuration chiffré, les données doivent être déchiffrées avant de pouvoir être utilisées (et cela se produit sans que vous écriviez de code). Par conséquent, si un pirate informatique parvient à télécharger une page Web ASP.NET sur votre système qui interroge le fichier de configuration et affiche ses résultats, il peut alors afficher les paramètres cryptés sous forme de texte brut. (Pour plus de détails, veuillez vous référer à l'exemple de page ASP.NET fourni dans cet article, qui montre comment chiffrer et déchiffrer diverses parties du fichier Web.config ; comme vous pouvez le voir, une page ASP.NET peut accéder (et afficher) les données cryptées (sous forme de texte ordinaire)
3. Le cryptage et le déchiffrement des informations de configuration nécessitent un certain coût en termes de performances. Par conséquent, il est courant de chiffrer uniquement les parties de la configuration contenant des informations sensibles. Par exemple, il n'est peut-être pas nécessaire de chiffrer les sections de configuration <compilation> ou <authorization>.
3. Quels types d'informations peuvent être chiffrées ?
Avant d'analyser comment chiffrer les informations de configuration ASP.NET 2.0, examinons d'abord quelles informations de configuration peuvent être chiffrées. À l'aide des bibliothèques fournies par .NET Framework 2.0, les développeurs peuvent chiffrer la plupart des sections de configuration dans un fichier Web.config ou machine.config. Ces parties de configuration sont des éléments XML qui sont des nœuds enfants de l'élément <configuration> ou <system.web>. Par exemple, l'exemple de fichier Web.config suivant contient trois paramètres de configuration, explicitement définis comme :
<connectionStrings>, <compilation> et <authentication>.
＜?version XML="1.0"?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜chaînesdeconnexion＞
＜ajouter name="MembershipConnectionString" connectionString="connectionString"/＞
＜/chaînesdeconnexion＞
<système.web>
＜compilation debug="true"/＞
＜mode d'authentification="Formulaires" /＞
</system.web>
Chacune de ces sections peut éventuellement être chiffrée, soit par programme, soit via aspnet_regiis.exe (un outil de ligne de commande). Une fois chiffré, le texte chiffré est stocké directement dans le fichier de configuration. Par exemple, si nous devions chiffrer la section <connectionStrings> ci-dessus, le fichier Web.config résultant pourrait ressembler à ceci : (Remarque : en raison de limitations d'espace, nous avons omis une grande partie de <CipherValue>)
<?xml version= "1.0" ?＞
＜configuration xmlns=" http://schemas.microsoft.com/.NetConfiguration/v2.0 "＞
＜connectionStrings configProtectionProvider="DataProtectionConfigurationProvider"＞
＜Données cryptées＞
＜Données de chiffrement＞
＜Valeur de chiffrement＞AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAed...GicAlQ==＜/Valeur de chiffrement＞
＜/Données de chiffrement＞
＜/Données cryptées＞
＜/chaînesdeconnexion＞
<système.web>
＜compilation debug="true"/＞
＜mode d'authentification="Formulaires" /＞
＜/system.web＞
De plus, certaines parties de configuration ne peuvent pas être chiffrées à l'aide de cette technique :
· ＜processModel＞
· ＜exécution＞
· ＜mscorlib＞
·＜démarrage＞
· ＜system.runtime.remoting＞
· ＜configProtectedData＞
· ＜assemblages satellites＞
· ＜Paramètres de cryptographie＞
· ＜cryptoNameMapping＞
· <cryptoClasses>
Afin de chiffrer ces parties de configuration, vous devez chiffrer ces valeurs et les stocker dans le registre. Il existe un outil de ligne de commande aspnet_setreg.exe qui peut vous aider dans ce processus ; nous discuterons de cet outil plus loin dans cet article.
[Astuce] La différence entre Web.Config et Machine.Config :
le fichier Web.config spécifie les paramètres de configuration d'une application Web spécifique et se trouve dans le répertoire racine de l'application tandis que le fichier machine.config spécifie tous les paramètres de configuration situés ; sur le serveur Web. Paramètres de configuration du site sur et situés dans le répertoire $WINDOWSDIR$Microsoft.NetFrameworkVersionCONFIG.
4. Options de chiffrement
Les développeurs peuvent utiliser le modèle de fournisseur ASP.NET 2.0 pour protéger les informations de la section de configuration, ce qui permet à toute implémentation d'être connectée de manière transparente à l'API. Le .NET Framework 2.0 fournit deux fournisseurs intégrés pour protéger les informations de la section de configuration :
· Fournisseur DPAPI (Windows Data Protection API) (DataProtectionConfigurationProvider) : ce fournisseur utilise la technologie de cryptographie intégrée de Windows pour crypter et déchiffrer les sections de configuration. Par défaut, ce fournisseur utilise la clé native. Vous pouvez également utiliser des clés utilisateur, mais cela nécessite un peu de personnalisation.
· Fournisseur de configuration protégé RSA (RSAProtectedConfigurationProvider) : utilise le cryptage à clé publique RSA pour crypter et déchiffrer les sections de configuration. À l'aide de ce fournisseur, vous devez créer un conteneur de clés qui stocke les clés publiques et privées utilisées pour chiffrer et déchiffrer les informations de configuration. Vous pouvez utiliser RSA dans une batterie multi-serveurs en créant des conteneurs de clés exportables.
Bien entendu, vous pouvez également créer votre propre fournisseur de paramètres de protection si nécessaire.
Dans cet article, nous discutons uniquement de l'utilisation de clés au niveau machine à l'aide du fournisseur DPAPI. Il s’agit de loin de la méthode la plus simple car elle ne nécessite pas la création de clés ou de conteneurs de clés. L'inconvénient, bien sûr, est qu'un fichier de configuration crypté ne peut être utilisé que sur le serveur Web qui a implémenté le cryptage en premier lieu. De plus, l'utilisation d'une clé machine permettra au texte crypté d'être déchiffré par n'importe quel site du serveur Web.
5. Chiffrez la section de configuration par programme.
La classe System.Configuration.SectionInformation résume la description d'une section de configuration. Pour chiffrer une section de configuration, utilisez simplement la méthode ProtectSection(provider) de la classe SectionInformation, en passant le nom du fournisseur que vous souhaitez utiliser pour effectuer le chiffrement. Pour accéder à une section de configuration spécifique dans le fichier Web.config de votre application, vous pouvez utiliser la classe WebConfigurationManager (dans l'espace de noms System.Web.Configuration) pour référencer votre fichier Web.config, puis utiliser son GetSection. La méthode (sectionName) renvoie un Instance de ConfigurationSection. Enfin, vous pouvez obtenir un objet SectionInformation via la propriété SectionInformation de l'instance ConfigurationSection.
Ci-dessous, nous illustrons le problème à travers un exemple de code simple :
privatevoid ProtectSection(string sectionName, string supplier)
{
Configuration config = WebConfigurationManager.
OpenWebConfiguration(Request.ApplicationPath);
Section ConfigurationSection = config.GetSection(sectionName);
si (section != null &&!section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(fournisseur);
config.Save();
}
}
private void UnProtectSection (string sectionName) {
Configuration config =WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
Section ConfigurationSection = config.GetSection n(sectionName);
si (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
Vous pouvez appeler cette méthode ProtectSection(sectionName, supplier) à partir d'une page ASP.NET, ses paramètres correspondants sont un nom de section (tel que connectionStrings) et un fournisseur (tel que DataProtectionConfigurationProvider), et elle ouvre le fichier Web.config, faisant référence à Dans cette section, la méthode ProtectSection(provider) de l'objet SectionInformation est appelée et enfin les modifications de configuration sont enregistrées.
D'autre part, la méthode UnProtectSection(provider) implémente le déchiffrement d'une section de configuration spécifique. Ici, seule la section à déchiffrer doit être transmise - nous n'avons pas besoin de déranger le fournisseur puisque ces informations sont déjà stockées dans la balise accompagnant la section chiffrée (c'est-à-dire la section <connectionStrings> dans l'exemple ci-dessus, qui est chiffré Plus tard, il inclut le fournisseur : <connectionStringsconfigProtectionProvider="DataProtectionConfigurationProvider">).
N'oubliez pas qu'une fois ces données chiffrées, lors de leur lecture à partir d'une page ASP.NET (c'est-à-dire lors de la lecture des informations de chaîne de connexion à partir d'un contrôle SqlDataSource ou par programme via ConfigurationManager.ConnectionStrings[connStringName].ConnectionString) , ASP.NET déchiffrera automatiquement le chaîne de connexion et renvoie une valeur en texte brut. En d’autres termes, vous n’avez pas du tout besoin de modifier votre code après avoir implémenté le cryptage. Plutôt cool, non ?
Dans l'exemple de site Web ASP.NET 2.0 téléchargé à partir de cet article, vous trouverez un exemple de page qui affiche le fichier Web.config du site, qui comporte une zone de texte multiligne et les boutons de contrôle Web correspondants pour la configuration du chiffrement. déposer. Cet exemple utilise également les méthodes ProtectSection() et UnProtectSection() décrites ci-dessus.
6. Utilisez l'outil de ligne de commande aspnet_regiis.exe
Vous pouvez également utiliser l'outil de ligne de commande aspnet_regiis.exe pour crypter et déchiffrer la partie de configuration du fichier Web.config. Vous pouvez la trouver dans le fichier "%WINDOWSDIR%Microsoft.Net. Répertoire Frameworkversion". outil. Afin de chiffrer une section du fichier Web.config, vous pouvez utiliser la clé machine DPAPI dans cet outil de ligne de commande comme suit :
Forme courante de chiffrement d'un fichier Web.config pour un site Web spécifique :
aspnet_regiis.exe -pef section physical_directory - fournisseur prov
ou :
aspnet_regiis.exe -pe section -app virtual_directory -prov
Une instance spécifique de fournisseur cryptant le fichier Web.config d'un site Web spécifique :
aspnet_regiis.exe -pef "connectionStrings" "C:InetpubwwwrootMySite" -prov " DataProtectionConfigurationProvider"
ou :
aspnet_regiis.exe -pe "connectionStrings" -app "/MySite" -prov "DataProtectionConfigurationProvider"
Une forme courante de décryptage du fichier Web.config d'un site Web spécifique :
aspnet_regiis.exe -pdf section physical_directory
ou :
aspnet_regiis. exe -pd Section -app virtual_directory
Exemple spécifique de décryptage du fichier Web.config d'un site Web spécifique :
aspnet_regiis.exe -pdf "connectionStrings" "C:InetpubwwwrootMySite"
ou :
Vous pouvez également spécifier que aspnet_regiis.exe s'exécute machine.config Cryptage/déchiffrement de fichiers.
[Astuce] Chiffrement des paramètres de configuration dans ASP.NET version 1.x
Pour protéger les paramètres de configuration dans ASP.NET version 1.x, les développeurs doivent chiffrer et stocker les paramètres sensibles dans le registre du serveur Web et utiliser un stockage de clé « fort ». méthode. Plutôt que de stocker le contenu chiffré (comme dans ASP.NET 2.0), le fichier de configuration contient simplement une référence à la clé de registre dans laquelle la valeur chiffrée est stockée. Par exemple :
<identity impersonate="true"
userName="registre :HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,userName"
password="registry:HKLMSOFTWAREMY_SECURE_APPidentityASPNET_SETREG,password" />
Microsoft fournit aux développeurs l'outil de ligne de commande aspnet_setreg.exe pour crypter les informations de configuration sensibles et les déplacer vers une entrée de registre « forte ». Malheureusement, cet outil ne fonctionne qu'avec des paramètres de configuration spécifiques ; en revanche, ASP.NET 2.0 permet de chiffrer n'importe quelle section de configuration.
Pour plus d’informations sur l’utilisation de aspnet_setreg.exe dans une application ASP.NET 1.x, consultez la base de connaissances n° 32990 sur MSDN. Malheureusement, ce programme de ligne de commande ne peut chiffrer que les sections prédéfinies dans les paramètres de configuration et ne vous permet pas de chiffrer les chaînes de connexion à la base de données et autres informations sensibles que vous ajoutez vous-même.
7. Conclusion
Dans cet article, nous avons appris à utiliser les différentes options de chiffrement fournies par ASP.NET 2.0 pour protéger les informations de la section de configuration. Nous avons également expliqué comment utiliser les techniques de programmation et aspnet_regiis.exe pour chiffrer respectivement la section de configuration dans Web.config. . La protection de vos paramètres de configuration sensibles contribue à rendre votre site plus difficile à pirater, en rendant plus difficile la découverte des paramètres de configuration sensibles. Aujourd'hui, ASP.NET 2.0 propose déjà une technologie de chiffrement et de déchiffrement relativement simple, et il n'y a aucune raison pour que les développeurs n'utilisent pas cette méthode pour protéger vos paramètres de configuration sensibles.