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 fourni à un visiteur du site Web, mais un administrateur ou un pirate informatique 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 des informations sensibles en chiffrant les sections du fichier Web.config.

Introduction

Les informations de configuration des applications ASP.NET sont généralement stockées dans un fichier XML nommé Web.config. Au cours de ces tutoriels, nous avons mis à jour les Web.config quelques 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é automatiquement ajoutées à Web.config dans la <connectionStrings> section . Plus tard, dans le didacticiel Pages maîtres et navigation de 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.

Étant donné Web.config que peut contenir des données sensibles telles que des chaînes de connexion, il est important que le contenu de Web.config soit conservé en sécurité et masqué aux 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 de ASP.NET, qui retourne le message Ce type de page n’est pas servi comme illustré 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 la barre d’adresse de leur navigateur.

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

Figure 1 : La visite Web.config via un navigateur renvoie un message Ce type de page n’est pas servi (cliquez pour afficher l’image en taille réelle)

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

Toutefois, certaines Web.config sections contiennent des informations sensibles qui peuvent inclure des chaînes 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, le .NET Framework version 2.0 inclut un système de configurations protégées qui facilite le chiffrement et le déchiffrement par programmation des sections de configuration sélectionnées.

Notes

Ce tutoriel se termine par un aperçu des recommandations de Microsoft pour la connexion à une base de données à partir d’une application ASP.NET. En plus de chiffrer vos chaînes 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ée de ASP.NET 2.0 s

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 brancher à 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 utilisent 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 Web.config des 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 Lectures supplémentaires à la fin de ce tutoriel.

Notes

Les RSAProtectedConfigurationProvider fournisseurs et DPAPIProtectedConfigurationProvider sont inscrits dans le machine.config fichier avec les noms RsaProtectedConfigurationProvider de fournisseurs 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 : Chiffrement et déchiffrement par programmation des sections de configuration

Avec quelques lignes de code, nous pouvons chiffrer ou déchiffrer une section de configuration particulière à l’aide d’un fournisseur spécifié. Comme nous le verrons bientôt, le code doit simplement référencer par programmation la section de configuration appropriée, appeler sa ProtectSection méthode ou UnprotectSection , puis appeler la Save méthode pour conserver les modifications. En outre, le .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 programmatique des informations de configuration, créons une page ASP.NET qui inclut des boutons pour le chiffrement et le déchiffrement de 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 Designer, affectez à sa ID propriété la valeur MultiLine, TextMode et ses Width propriétés et à Rows 95 % et 15, respectivement.WebConfigContents 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 textBox, ajoutez deux contrôles Button nommés EncryptConnStrings et DecryptConnStrings. Définissez leurs propriétés Text sur 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 sur la page EncryptingConfigSections.aspx, avec un nouveau contrôle TextBox et deux contrôles Button.

Figure 2 : Ajouter un contrôle Web TextBox et deux boutons à la page (cliquer pour afficher l’image en taille réelle)

Ensuite, nous devons écrire du code qui charge et affiche le contenu de dans la WebConfigContents zone de texte lors du premier chargement de Web.config la page. 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 Page.IsPostBack est 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 de l’application Web.config , la StreamReader classe pour lire son contenu dans une chaîne et la Path classe pour générer le chemin physique du Web.config fichier. Ces trois classes se trouvent toutes dans l’espace deSystem.IO noms . Par conséquent, vous devez ajouter une usingSystem.IO instruction en haut de la classe code-behind ou, sinon, préfixer ces noms de classe avec System.IO. .

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 <connectionStrings> d’une clé au niveau de l’ordinateur avec le fournisseur DPAPI. À partir du Designer, 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 tous deux par obtenir des informations sur le fichier de l’application Web.config actuelle via la WebConfigurationManager méthode class sOpenWebConfiguration. 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 class sGetSection(sectionName), 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é. En outre, la section peut être chiffrée ou déchiffrée via les méthodes et UnprotectSection les SectionInformationProtectSection(provider) propriétés.

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 s, nous passons 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 ProtectSection(provider) méthode ou UnprotectSection , vous devez appeler la méthode de l’objet SaveConfiguration pour conserver les modifications. Une fois les informations de configuration chiffrées ou déchiffrées et les modifications enregistrées, nous appelons DisplayWebConfig pour 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 initialement voir une page qui répertorie le contenu de Web.config avec 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 un contrôle Web TextBox et Deux boutons à la page (cliquer pour afficher l’image en taille réelle)

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 WebConfigContents TextBox génère un HttpRequestValidationException, qui affiche le message : Une valeur potentiellement dangereuse Request.Form a été détectée à partir du client. La validation des demandes, qui est activée par défaut dans ASP.NET 2.0, interdit les publications qui incluent du code HTML non codé et est conçue pour empêcher les attaques par injection de script. Cette case activée peut être désactivée au niveau de la page ou de l’application. Pour le désactiver pour cette page, définissez le paramètre false sur ValidateRequest dans 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 façon de la désactiver au niveau de la page et de l’application, ainsi que sur l’encodage HTML du balisage, consultez Validation de la demande - Prévention des attaques de script.

Après avoir désactivé la validation des demandes pour la page, essayez de cliquer à nouveau 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 en taille réelle)

La section chiffrée <connectionStrings> générée sur mon ordinateur suit, bien qu’une partie du contenu de l’élément <CipherData> ait été supprimée par souci de concision :

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

Notes

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 vous cliquez sur le bouton Déchiffrer les chaînes de connexion.

Lorsque l’chaîne de connexion informations est accessible à partir du Web.config code que nous écrivons, d’un contrôle SqlDataSource ou du code généré automatiquement à partir des TableAdapters de nos DataSets typés, elles sont automatiquement déchiffrées. 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, consultez l’un des didacticiels précédents à l’heure actuelle, comme le tutoriel Affichage simple de la section Rapports de base (~/BasicReporting/SimpleDisplay.aspx). Comme le montre la figure 5, le tutoriel 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 (cliquer pour afficher l’image en taille réelle)

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 la publication, vous devez voir les chaînes de connexion dans Web.config en texte brut. À ce stade, votre écran doit ressembler à celui-ci lors de la première visite de cette page (voir figure 3).

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

Le .NET Framework inclut divers outils en ligne de commande dans le $WINDOWS$\Microsoft.NET\Framework\version\ dossier. Dans le didacticiel Utilisation des dépendances du cache SQL, pour instance, 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 du cache SQL. Un autre outil en 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 d’UN serveur Web de niveau professionnel de Microsoft, IIS. En plus de ses fonctionnalités 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 aspnet_regiis.exe en ligne de commande :

aspnet_regiis.exe -pef section physical_directory -prov provider

section est la section de configuration à chiffrer (comme connectionStrings), le physical_directory est le chemin physique complet du répertoire racine de l’application web et le fournisseur est le nom du fournisseur de configuration protégé à utiliser (par exemple, DataProtectionConfigurationProvider). Si l’application web est inscrite dans IIS, vous pouvez également 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 section à l’aide <connectionStrings> 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

Notes

É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 que vous chargez le fichier Web.config chiffré sur le serveur de production, le serveur de production ne sera pas en mesure de déchiffrer les informations chaîne de connexion, car elles ont été chiffrées à 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 vers un autre ordinateur.

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

Avant qu’une application puisse émettre SELECTdes requêtes , INSERT, UPDATEou DELETE sur 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 : le 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é de domainName``\MachineName ou domainName``\NETWORK SERVICE, bien que cela puisse être personnalisé.
  • Authentification SQL : un ID utilisateur et des valeurs de mot de passe sont fournis en tant qu’informations d’identification pour l’authentification. Avec l’authentification SQL, l’ID 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 le 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. Avec l’authentification SQL, toutefois, les informations d’identification d’authentification sont codées en dur dans le chaîne de connexion et sont transmises du serveur web au serveur de base de données en texte brut.

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

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

La valeur Integrated Security=True et l’absence de nom d’utilisateur et de mot de passe indiquent que Authentification Windows est utilisé. Dans certaines chaînes de connexion, le terme Trusted Connection=Yes ou Integrated Security=SSPI est utilisé au lieu de 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 se connecter à votre base de données via SQL Management Studio ou à partir de ASP.NET pages de son propre site web. Pour atténuer cette menace, chiffrez les informations chaîne de connexion à Web.config l’aide du système de configuration protégé.

Notes

Pour plus d’informations sur les différents types d’authentification disponibles dans SQL Server, consultez Création d’applications ASP.NET sécurisées : 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înes 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 mieux protéger 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 : l’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. Cela peut être effectué à la fois par programmation, comme nous l’avons vu à l’étape 2, ainsi que par le biais de l’outil aspnet_regiis.exe en ligne de commande, qui a été abordé à l’étape 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 Lecture supplémentaire.

Bonne programmation !

En savoir plus

Pour plus d’informations sur les sujets abordés dans ce tutoriel, reportez-vous aux 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 comme consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 in 24 Heures. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui peut être trouvé à l’adresse http://ScottOnWriting.NET.

Un merci spécial à

Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Les principaux réviseurs 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