Partager via

Protection des chaînes de connexion et d’autres informations de configuration (C#)

  • Article

par Scott Mitchell

Télécharger le PDF

Une application ASP.NET stocke généralement les informations de configuration dans un fichier Web.config. Certaines de ces informations sont sensibles et justifient une protection. Par défaut, ce fichier ne sera pas servi à un visiteur du site Web, mais un administrateur ou un pirate peut accéder au système de fichiers du serveur Web et afficher le contenu du fichier. Dans ce tutoriel, nous apprenons que ASP.NET 2.0 nous permet de protéger les informations sensibles en chiffrant les sections du fichier Web.config.

Introduction

Les informations de configuration pour les applications ASP.NET sont généralement stockées dans un fichier XML nommé Web.config. Au cours de ces didacticiels, nous avons mis à jour quelques Web.config fois. Lors de la création du Northwind Jeu de données typé dans le premier tutoriel, par exemple, chaîne de connexion informations ont été ajoutées Web.config automatiquement dans la <connectionStrings> section. Plus tard, dans le didacticiel de navigation des pages maîtres et du site, nous avons mis à jour Web.configmanuellement, en ajoutant un <pages> élément indiquant que toutes les pages ASP.NET de notre projet doivent utiliser le DataWebControls thème.

Dans la mesure Web.config où il peut contenir des données sensibles telles que des chaîne de connexion, il est important que le contenu d’être Web.config conservé en sécurité et masqué des visionneuses non autorisées. Par défaut, toute requête HTTP adressée à un fichier avec l’extension .config est gérée par le moteur ASP.NET, qui retourne le message de ce type de page n’est pas servi dans la figure 1. Cela signifie que les visiteurs ne peuvent pas afficher le contenu de votre Web.config fichier en entrant http://www.YourServer.com/Web.config simplement dans leur barre d’adresses du navigateur.

La visite de Web.config via un navigateur renvoie un type de page qui n’est pas servi message

Figure 1 : La visite Web.config via un navigateur renvoie un message de ce type de page (cliquez pour afficher l’image de taille complète)

Mais que se passe-t-il si un attaquant est en mesure de trouver un autre exploit qui lui permet d’afficher le contenu de votre Web.config fichier ? Qu’est-ce qu’un attaquant peut faire avec ces informations et quelles mesures peuvent être prises pour protéger davantage les informations sensibles au sein Web.configde ces informations ? Heureusement, la plupart des sections ne Web.config contiennent pas d’informations sensibles. Quel préjudice un attaquant peut-il perpétrer s’il connaît le nom du thème par défaut utilisé par vos pages ASP.NET ?

Toutefois, certaines Web.config sections contiennent des informations sensibles qui peuvent inclure des chaîne de connexion, des noms d’utilisateur, des mots de passe, des noms de serveur, des clés de chiffrement, etc. Ces informations se trouvent généralement dans les sections suivantes Web.config :

  • <appSettings>
  • <connectionStrings>
  • <identity>
  • <sessionState>

Dans ce tutoriel, nous allons examiner les techniques de protection de ces informations de configuration sensibles. Comme nous le verrons, .NET Framework version 2.0 inclut un système de configurations protégés qui permet de chiffrer et déchiffrer par programmation les sections de configuration sélectionnées.

Remarque

Ce tutoriel se termine par un aperçu des recommandations de Microsoft relatives à la connexion à une base de données à partir d’une application ASP.NET. Outre le chiffrement de vos chaîne de connexion, vous pouvez renforcer votre système en vous assurant que vous vous connectez à la base de données de manière sécurisée.

Étape 1 : Exploration des options de configuration protégées de ASP.NET 2.0

ASP.NET 2.0 inclut un système de configuration protégé pour le chiffrement et le déchiffrement des informations de configuration. Cela inclut des méthodes dans le .NET Framework qui peuvent être utilisées pour chiffrer ou déchiffrer par programmation les informations de configuration. Le système de configuration protégé utilise le modèle de fournisseur qui permet aux développeurs de choisir l’implémentation de chiffrement utilisée.

Le .NET Framework est fourni avec deux fournisseurs de configuration protégés :

Étant donné que le système de configuration protégé implémente le modèle de conception du fournisseur, il est possible de créer votre propre fournisseur de configuration protégé et de le connecter à votre application. Pour plus d’informations sur ce processus, consultez Implémentation d’un fournisseur de configuration protégé.

Les fournisseurs RSA et DPAPI utilisent des clés pour leurs routines de chiffrement et de déchiffrement, et ces clés peuvent être stockées au niveau de l’ordinateur ou de l’utilisateur. Les clés au niveau de l’ordinateur sont idéales pour les scénarios où l’application web s’exécute sur son propre serveur dédié ou s’il existe plusieurs applications sur un serveur qui doivent partager des informations chiffrées. Les clés au niveau de l’utilisateur sont une option plus sécurisée dans les environnements d’hébergement partagé où d’autres applications sur le même serveur ne doivent pas être en mesure de déchiffrer les sections de configuration protégées de votre application.

Dans ce tutoriel, nos exemples utiliseront le fournisseur DPAPI et les clés au niveau de l’ordinateur. Plus précisément, nous allons examiner le chiffrement de la <connectionStrings> section dans Web.config, bien que le système de configuration protégé puisse être utilisé pour chiffrer la plupart des Web.config sections. Pour plus d’informations sur l’utilisation de clés de niveau utilisateur ou sur l’utilisation du fournisseur RSA, consultez les ressources de la section Autres lectures à la fin de ce tutoriel.

Remarque

Les RSAProtectedConfigurationProvider fournisseurs et DPAPIProtectedConfigurationProvider les fournisseurs sont inscrits dans le machine.config fichier avec les noms RsaProtectedConfigurationProvider du fournisseur et DataProtectionConfigurationProvider, respectivement. Lors du chiffrement ou du déchiffrement des informations de configuration, nous devons fournir le nom du fournisseur approprié (RsaProtectedConfigurationProvider ou DataProtectionConfigurationProvider) plutôt que le nom de type réel (RSAProtectedConfigurationProvider et DPAPIProtectedConfigurationProvider). Vous trouverez le machine.config fichier dans le $WINDOWS$\Microsoft.NET\Framework\version\CONFIG dossier.

Étape 2 : Sections de configuration de chiffrement et de déchiffrement par programmation

Avec quelques lignes de code, nous pouvons chiffrer ou déchiffrer une section de configuration particulière à l’aide d’un fournisseur spécifié. Le code, comme nous le verrons bientôt, doit simplement référencer par programmation la section de configuration appropriée, appeler son ou UnprotectSection sa ProtectSection méthode, puis appeler la Save méthode pour conserver les modifications. En outre, .NET Framework inclut un utilitaire de ligne de commande utile qui peut chiffrer et déchiffrer les informations de configuration. Nous allons explorer cet utilitaire de ligne de commande à l’étape 3.

Pour illustrer la protection par programmation des informations de configuration, nous allons créer une page ASP.NET qui inclut des boutons pour chiffrer et déchiffrer la <connectionStrings> section dans Web.config.

Commencez par ouvrir la EncryptingConfigSections.aspx page dans le AdvancedDAL dossier. Faites glisser un contrôle TextBox de la boîte à outils sur le Concepteur, en définissant sa ID propriété sur WebConfigContents, sa TextMode propriété MultiLinesur , et ses Width Rows propriétés sur 95 % et 15 , respectivement. Ce contrôle TextBox affiche le contenu de ce qui nous permet de Web.config voir rapidement si le contenu est chiffré ou non. Bien sûr, dans une application réelle, vous ne voudriez jamais afficher le contenu de Web.config.

Sous la zone de texte, ajoutez deux contrôles Button nommés EncryptConnStrings et DecryptConnStrings. Définissez leurs propriétés de texte pour chiffrer les chaînes de connexion et déchiffrer les chaînes de connexion.

À ce stade, votre écran doit ressembler à la figure 2.

Capture d’écran montrant Visual Studio ouvert à la page EncryptingConfigSections.aspx, qui a un nouveau contrôle TextBox et deux contrôles Button.

Figure 2 : Ajouter une zone de texte et deux contrôles web bouton à la page (cliquez pour afficher l’image de taille complète)

Ensuite, nous devons écrire du code qui charge et affiche le contenu de la WebConfigContents zone de Web.config texte lorsque la page est chargée pour la première fois. Ajoutez le code suivant à la classe code-behind de la page. Ce code ajoute une méthode nommée DisplayWebConfig et l’appelle à partir du Page_Load gestionnaire d’événements quand est Page.IsPostBack false:

protected void Page_Load(object sender, EventArgs e)
{
    // On the first page visit, call DisplayWebConfig method
    if (!Page.IsPostBack)
        DisplayWebConfig();
}
private void DisplayWebConfig()
{
    // Reads in the contents of Web.config and displays them in the TextBox
    StreamReader webConfigStream = 
        File.OpenText(Path.Combine(Request.PhysicalApplicationPath, "Web.config"));
    string configContents = webConfigStream.ReadToEnd();
    webConfigStream.Close();
    WebConfigContents.Text = configContents;
}

La DisplayWebConfig méthode utilise la File classe pour ouvrir le fichier s de Web.config l’application, laStreamReader classe pour lire son contenu dans une chaîne et la Path classe pour générer le chemin d’accès physique au Web.config fichier. Ces trois classes sont toutes trouvées dans l’espace System.IO de noms. Par conséquent, vous devez ajouter une using System.IO instruction en haut de la classe code-behind ou, sinon, préfixer ces noms System.IO. de classes .

Ensuite, nous devons ajouter des gestionnaires d’événements pour les deux événements de contrôles Click Button et ajouter le code nécessaire pour chiffrer et déchiffrer la section à l’aide d’une clé au niveau de l’ordinateur <connectionStrings> avec le fournisseur DPAPI. Dans le Concepteur, double-cliquez sur chacun des boutons pour ajouter un gestionnaire d’événements Click dans la classe code-behind, puis ajoutez le code suivant :

protected void EncryptConnStrings_Click(object sender, EventArgs e)
{
    // Get configuration information about Web.config
    Configuration config = 
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
    // Let's work with the <connectionStrings> section
    ConfigurationSection connectionStrings = config.GetSection("connectionStrings");
    if (connectionStrings != null)
        // Only encrypt the section if it is not already protected
        if (!connectionStrings.SectionInformation.IsProtected)
        {
            // Encrypt the <connectionStrings> section using the 
            // DataProtectionConfigurationProvider provider
            connectionStrings.SectionInformation.ProtectSection(
                "DataProtectionConfigurationProvider");
            config.Save();
            
            // Refresh the Web.config display
            DisplayWebConfig();
        }
}
protected void DecryptConnStrings_Click(object sender, EventArgs e)
{
    // Get configuration information about Web.config
    Configuration config = 
        WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
    // Let's work with the <connectionStrings> section
    ConfigurationSection connectionStrings = 
        config.GetSection("connectionStrings");
    if (connectionStrings != null)
        // Only decrypt the section if it is protected
        if (connectionStrings.SectionInformation.IsProtected)
        {
            // Decrypt the <connectionStrings> section
            connectionStrings.SectionInformation.UnprotectSection();
            config.Save();
            // Refresh the Web.config display
            DisplayWebConfig();
        }
}

Le code utilisé dans les deux gestionnaires d’événements est presque identique. Ils commencent par obtenir des informations sur le fichier d’application Web.config actuel via laWebConfigurationManager méthode de classe.OpenWebConfiguration Cette méthode retourne le fichier de configuration web pour le chemin d’accès virtuel spécifié. Ensuite, la Web.config section s du <connectionStrings> fichier est accessible via laConfiguration méthode s de GetSection(sectionName) classe, qui retourne un ConfigurationSection objet.

L’objet ConfigurationSection inclut une SectionInformation propriété qui fournit des informations et des fonctionnalités supplémentaires concernant la section de configuration. Comme le montre le code ci-dessus, nous pouvons déterminer si la section de configuration est chiffrée en vérifiant la propriété de IsProtected la SectionInformation propriété. De plus, la section peut être chiffrée ou déchiffrée via les SectionInformation méthodes et UnprotectSection les propriétésProtectSection(provider).

La ProtectSection(provider) méthode accepte comme entrée une chaîne spécifiant le nom du fournisseur de configuration protégé à utiliser lors du chiffrement. Dans le EncryptConnString gestionnaire d’événements Button, nous transmettons DataProtectionConfigurationProvider à la ProtectSection(provider) méthode afin que le fournisseur DPAPI soit utilisé. La UnprotectSection méthode peut déterminer le fournisseur utilisé pour chiffrer la section de configuration et ne nécessite donc aucun paramètre d’entrée.

Après avoir appelé la ou UnprotectSection la ProtectSection(provider) méthode, vous devez appeler la Configuration méthode de l’objet Save pour conserver les modifications. Une fois les informations de configuration chiffrées ou déchiffrées et les modifications enregistrées, nous appelons DisplayWebConfig à charger le contenu mis à jour Web.config dans le contrôle TextBox.

Une fois que vous avez entré le code ci-dessus, testez-le en visitant la EncryptingConfigSections.aspx page via un navigateur. Vous devez d’abord voir une page qui répertorie le contenu de Web.config la <connectionStrings> section affichée en texte brut (voir la figure 3).

Capture d’écran montrant la page EncryptingConfigSections.aspx chargée dans un navigateur web.

Figure 3 : Ajouter une zone de texte et deux contrôles web bouton à la page (cliquez pour afficher l’image de taille complète)

Cliquez maintenant sur le bouton Chiffrer les chaînes de connexion. Si la validation de la demande est activée, le balisage publié à partir de TextBox WebConfigContents génère un HttpRequestValidationExceptionmessage qui affiche le message, une valeur potentiellement dangereuse Request.Form a été détectée à partir du client. La validation de la demande, activée par défaut dans ASP.NET 2.0, interdit les postbacks qui incluent du code HTML non codé et est conçu pour empêcher les attaques par injection de script. Cette vérification peut être désactivée au niveau de la page ou de l’application. Pour le désactiver pour cette page, définissez le ValidateRequest paramètre false sur la @Page directive. La @Page directive se trouve en haut du balisage déclaratif de la page.

<%@ Page ValidateRequest="False" ... %>

Pour plus d’informations sur la validation des demandes, son objectif, la désactivation de celle-ci au niveau de la page et de l’application, ainsi que sur la façon d’encoder le balisage HTML, consultez Validation de la demande - Prévention des attaques de script.

Après avoir désactivé la validation de la demande pour la page, réessayez de cliquer sur le bouton Chiffrer les chaînes de connexion. Lors de la publication, le fichier de configuration est accessible et sa <connectionStrings> section chiffrée à l’aide du fournisseur DPAPI. La zone de texte est ensuite mise à jour pour afficher le nouveau Web.config contenu. Comme le montre la figure 4, les <connectionStrings> informations sont désormais chiffrées.

Cliquer sur le bouton Chiffrer les chaînes de connexion chiffre la <section connectionString>

Figure 4 : Cliquer sur le bouton Chiffrer les chaînes de connexion chiffre la <connectionString> section (Cliquez pour afficher l’image de taille complète)

La section chiffrée <connectionStrings> générée sur mon ordinateur suit, bien que certains contenus de l’élément <CipherData> aient été supprimés pour concision :

<connectionStrings 
    configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/...zChw==</CipherValue>
    </CipherData>
  </EncryptedData>
</connectionStrings>

Remarque

L’élément <connectionStrings> spécifie le fournisseur utilisé pour effectuer le chiffrement (DataProtectionConfigurationProvider). Ces informations sont utilisées par la UnprotectSection méthode lorsque le bouton Déchiffrer les chaînes de connexion est cliqué.

Lorsque les informations chaîne de connexion sont accessibles à partir Web.config du code que nous écrivons, à partir d’un contrôle SqlDataSource ou du code généré automatiquement à partir de TableAdapters dans nos DataSets typés, il est automatiquement déchiffré. En bref, nous n’avons pas besoin d’ajouter de code ou de logique supplémentaire pour déchiffrer la section chiffrée <connectionString> . Pour illustrer cela, visitez l’un des didacticiels précédents à ce stade, tels que le didacticiel Simple Display de la section Création de rapports de base (~/BasicReporting/SimpleDisplay.aspx). Comme le montre la figure 5, le didacticiel fonctionne exactement comme prévu, indiquant que les informations chiffrées chaîne de connexion sont automatiquement déchiffrées par la page ASP.NET.

La couche d’accès aux données déchiffre automatiquement les informations de chaîne de connexion

Figure 5 : La couche d’accès aux données déchiffre automatiquement les informations de chaîne de connexion (cliquez pour afficher l’image de taille complète)

Pour rétablir la représentation en texte brut de la <connectionStrings> section, cliquez sur le bouton Déchiffrer les chaînes de connexion. Dans le postback, vous devriez voir les chaîne de connexion dans Web.config le texte brut. À ce stade, votre écran doit ressembler à celui-ci lors de la première visite de cette page (voir la figure 3).

Étape 3 : Chiffrement des sections de configuration à l’aide de aspnet_regiis.exe

Le .NET Framework inclut un large éventail d’outils en ligne de commande dans le $WINDOWS$\Microsoft.NET\Framework\version\ dossier. Dans le didacticiel Utilisation des dépendances du cache SQL, par exemple, nous avons examiné l’utilisation de l’outil aspnet_regsql.exe en ligne de commande pour ajouter l’infrastructure nécessaire pour les dépendances de cache SQL. Un autre outil de ligne de commande utile dans ce dossier est l’outil d’inscription IIS ASP.NET (aspnet_regiis.exe). Comme son nom l’indique, l’outil d’inscription IIS ASP.NET est principalement utilisé pour inscrire une application ASP.NET 2.0 auprès du serveur Web professionnel microsoft, IIS. En plus de ses fonctionnalités liées à IIS, l’outil d’inscription IIS ASP.NET peut également être utilisé pour chiffrer ou déchiffrer les sections de configuration spécifiées dans Web.config.

L’instruction suivante montre la syntaxe générale utilisée pour chiffrer une section de configuration avec l’outil en aspnet_regiis.exe ligne de commande :

aspnet_regiis.exe -pef section physical_directory -prov provider

section est la section de configuration à chiffrer (comme connectionStrings), l’physical_directory est le chemin d’accès physique complet au répertoire racine de l’application web et le fournisseur est le nom du fournisseur de configuration protégé à utiliser (par exemple, DataProtectionConfigurationProvider). Sinon, si l’application web est inscrite dans IIS, vous pouvez entrer le chemin d’accès virtuel au lieu du chemin physique à l’aide de la syntaxe suivante :

aspnet_regiis.exe -pe section -app virtual_directory -prov provider

L’exemple suivant aspnet_regiis.exe chiffre la <connectionStrings> section à l’aide du fournisseur DPAPI avec une clé au niveau de l’ordinateur :

aspnet_regiis.exe -pef
"connectionStrings" "C:\Websites\ASPNET_Data_Tutorial_73_CS"
-prov "DataProtectionConfigurationProvider"

De même, l’outil aspnet_regiis.exe en ligne de commande peut être utilisé pour déchiffrer les sections de configuration. Au lieu d’utiliser le -pef commutateur, utilisez -pdf (ou au lieu de -pe, utilisez -pd). Notez également que le nom du fournisseur n’est pas nécessaire lors du déchiffrement.

aspnet_regiis.exe -pdf section physical_directory
  -- or --
aspnet_regiis.exe -pd section -app virtual_directory

Remarque

Étant donné que nous utilisons le fournisseur DPAPI, qui utilise des clés spécifiques à l’ordinateur, vous devez exécuter aspnet_regiis.exe à partir de la même machine à partir de laquelle les pages web sont traitées. Par exemple, si vous exécutez ce programme de ligne de commande à partir de votre ordinateur de développement local, puis chargez le fichier Web.config chiffré sur le serveur de production, le serveur de production ne pourra pas déchiffrer les informations chaîne de connexion, car elle a été chiffrée à l’aide de clés spécifiques à votre ordinateur de développement. Le fournisseur RSA n’a pas cette limitation, car il est possible d’exporter les clés RSA sur un autre ordinateur.

Présentation des options d’authentification de base de données

Avant que toute application puisse émettreSELECT, INSERTou DELETE UPDATEinterroger une base de données Microsoft SQL Server, la base de données doit d’abord identifier le demandeur. Ce processus est appelé authentification et SQL Server fournit deux méthodes d’authentification :

  • Authentification Windows : processus sous lequel l’application s’exécute est utilisé pour communiquer avec la base de données. Lors de l’exécution d’une application ASP.NET via visual Studio 2005 s ASP.NET Development Server, l’application ASP.NET suppose l’identité de l’utilisateur actuellement connecté. Pour ASP.NET applications sur Microsoft Internet Information Server (IIS), ASP.NET applications supposent généralement l’identité ou domainName``\MachineName domainName``\NETWORK SERVICE, bien que cela puisse être personnalisé.
  • Authentification SQL : les valeurs d’ID d’utilisateur et de mot de passe sont fournies en tant qu’informations d’identification pour l’authentification. Avec l’authentification SQL, l’ID d’utilisateur et le mot de passe sont fournis dans le chaîne de connexion.

Authentification Windows est préférable à l’authentification SQL, car elle est plus sécurisée. Avec Authentification Windows l’chaîne de connexion est libre d’un nom d’utilisateur et d’un mot de passe et si le serveur web et le serveur de base de données résident sur deux ordinateurs différents, les informations d’identification ne sont pas envoyées sur le réseau en texte brut. Toutefois, avec l’authentification SQL, les informations d’identification d’authentification sont codées en dur dans le chaîne de connexion et transmises du serveur web au serveur de base de données en texte brut.

Ces didacticiels ont utilisé Authentification Windows. Vous pouvez indiquer quel mode d’authentification est utilisé en inspectant le chaîne de connexion. Les chaîne de connexion de Web.config nos didacticiels ont été les suivantes :

Data Source=.\SQLEXPRESS; AttachDbFilename=|DataDirectory|\NORTHWND.MDF; Integrated Security=True; User Instance=True

La sécurité intégrée =True et le manque de nom d’utilisateur et de mot de passe indiquent que Authentification Windows est utilisé. Dans certains chaîne de connexion le terme « Connexion approuvée = Oui ou Sécurité intégrée = SSPI » est utilisé au lieu d’Integrated Security=True, mais les trois indiquent l’utilisation de Authentification Windows.

L’exemple suivant montre un chaîne de connexion qui utilise l’authentification SQL. $CREDENTIAL_PLACEHOLDER$ est un espace réservé pour la paire clé-valeur de mot de passe. Notez que les informations d’identification sont incorporées dans le chaîne de connexion :

Server=serverName; Database=Northwind; uid=userID; $CREDENTIAL_PLACEHOLDER$

Imaginez qu’un attaquant est en mesure d’afficher le fichier de Web.config votre application. Si vous utilisez l’authentification SQL pour vous connecter à une base de données accessible via Internet, l’attaquant peut utiliser cette chaîne de connexion pour vous connecter à votre base de données via SQL Management Studio ou à partir de ASP.NET pages sur leur propre site web. Pour atténuer cette menace, chiffrez les informations de chaîne de connexion à Web.config l’aide du système de configuration protégé.

Remarque

Pour plus d’informations sur les différents types d’authentification disponibles dans SQL Server, consultez Building Secure ASP.NET Applications : Authentification, Autorisation et Communication sécurisée. Pour obtenir d’autres exemples chaîne de connexion illustrant les différences entre la syntaxe d’authentification Windows et SQL, reportez-vous à ConnectionStrings.com.

Résumé

Par défaut, les fichiers avec une .config extension dans une application ASP.NET ne sont pas accessibles via un navigateur. Ces types de fichiers ne sont pas retournés, car ils peuvent contenir des informations sensibles, telles que des chaîne de connexion de base de données, des noms d’utilisateur et des mots de passe, etc. Le système de configuration protégé dans .NET 2.0 permet de protéger davantage les informations sensibles en autorisant le chiffrement des sections de configuration spécifiées. Il existe deux fournisseurs de configuration protégés intégrés : un qui utilise l’algorithme RSA et l’autre qui utilise l’API de protection des données Windows (DPAPI).

Dans ce tutoriel, nous avons examiné comment chiffrer et déchiffrer les paramètres de configuration à l’aide du fournisseur DPAPI. Cette opération peut être effectuée par programmation, comme nous l’avons vu à l’étape 2, ainsi que via l’outil en ligne de commande, qui a été abordé à l’étape aspnet_regiis.exe 3. Pour plus d’informations sur l’utilisation de clés de niveau utilisateur ou sur l’utilisation du fournisseur RSA à la place, consultez les ressources de la section Autres lectures.

Bonne programmation !

Pour aller plus loin

Pour plus d’informations sur les sujets abordés dans ce tutoriel, consultez les ressources suivantes :

À propos de l’auteur

Scott Mitchell, auteur de sept livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille en tant que consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 en 24 heures. Il peut être accessible à mitchell@4GuysFromRolla.com. ou via son blog, qui peut être trouvé à http://ScottOnWriting.NET.

Merci spécial à

Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Les réviseurs principaux de ce tutoriel étaient Teresa Murphy et Randy Schmidt. Vous souhaitez consulter mes prochains articles MSDN ? Si c’est le cas, déposez-moi une ligne à mitchell@4GuysFromRolla.com.

PrécédentSuivant