Sécurisation de l'accès aux données

Article
10/22/2014

Mise à jour : novembre 2007

La plupart des applications Web ASP.NET impliquent un accès aux données. Beaucoup d'applications collectent des données à stocker dans une base de données ou un fichier, et ces données à stocker sont généralement basées sur des informations provenant des utilisateurs. Étant donné que les données initiales peuvent provenir de sources non fiables, que les informations sont stockées dans un format persistant et que vous souhaitez être sûr que les utilisateurs non autorisés ne peuvent pas accéder directement à votre source de données, vous devez accorder une attention particulière aux questions de sécurité qui s'appliquent à l'accès aux données. Les informations contenues dans cette rubrique décrivent les meilleures pratiques pour améliorer la sécurité de l'accès aux données dans votre application Web ASP.NET.

Bien que l'application des meilleures pratiques en matière de codage et de configuration puisse améliorer la sécurité de votre application, il est également important de mettre à jour régulièrement votre serveur Web en installant les mises à jour de sécurité les plus récentes pour Microsoft Windows et les services IIS (Internet Information Services), ainsi que les mises à jour de sécurité pour Microsoft SQL Server ou autres logiciels de sources de données.

Vous trouverez des informations plus détaillées sur les meilleures pratiques pour écrire du code sécurisé et sécuriser les applications dans l'ouvrage intitulé « Writing Secure Code » (Écriture de code sécurisé) de Michael Howard et David LeBlanc, ou dans les conseils fournis sur le site Web Microsoft Patterns and Practices

Sécurisation de l'accès à une source de données

Les sections suivantes fournissent des informations sur la sécurisation des différents aspects de l'accès aux données.

Chaînes de connexion

La connexion à une base de données requiert une chaîne de connexion. Étant donné que les chaînes de connexion peuvent contenir des données sensibles, vous devez suivre les indications ci-après :

Ne stockez pas les chaînes de connexion dans une page. Par exemple, évitez de définir les chaînes de connexion comme des propriétés déclaratives du contrôle SqlDataSource ou d'autres contrôles de source de données. Stockez-les plutôt dans le fichier Web.config du site. Pour obtenir un exemple, consultez Comment : sécuriser des chaînes de connexion lors de l'utilisation de contrôles de source de données.
Ne stockez pas les chaînes de connexion sous forme de texte brut. Pour que la connexion à votre serveur de base de données demeure sécurisée, il est recommandé de chiffrer des informations de la chaîne de connexion dans le fichier de configuration en utilisant la configuration protégée. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.

Connexion à SQL Server à l'aide de la sécurité intégrée

Si possible, connectez-vous à une instance de SQL Server à l'aide de la sécurité intégrée au lieu d'utiliser un nom d'utilisateur et un mot de passe explicites. Cela permet d'éviter que la chaîne de connexion soit compromise et que votre ID d'utilisateur et votre mot de passe soient accessibles.

Il est recommandé de vérifier que l'identité du processus (par exemple, le pool d'applications) qui exécute ASP.NET correspond au compte de processus par défaut ou à un compte d'utilisateur restreint. Pour plus d'informations, consultez Emprunt d'identité ASP.NET.

Dans les scénarios où différents sites Web se connectent à différentes bases de données SQL Server, l'utilisation de la sécurité intégrée peut ne pas convenir. Par exemple, sur les sites d'hébergement Web, une base de données SQL Server différente est généralement assignée à chaque client, mais tous les utilisateurs utilisent le serveur Web en tant qu'utilisateurs anonymes. Dans de tels cas, vous devez utiliser des informations d'identification explicites pour vous connecter à une instance de SQL Server. Assurez-vous de stocker les informations d'identification de façon sécurisée, comme décrit dans cette rubrique sous Chaînes de connexion.

Autorisations de base de données SQL Server

Il est recommandé d'assigner les privilèges minimaux à l'ID d'utilisateur employé pour se connecter aux bases de données SQL Server de votre application.

Restriction des opérations SQL

Les contrôles liés aux données peuvent prendre en charge plusieurs opérations de données, et notamment la sélection, l'insertion, la suppression et la mise à jour d'enregistrements dans les tables de données. Il est recommandé de configurer les contrôles de données pour exécuter les fonctionnalités minimales requises sur une page ou dans votre application. Par exemple, si un contrôle n'autorise pas les utilisateurs à supprimer des données, n'incluez pas une requête de suppression dans un contrôle de source de données et n'activez pas la suppression dans le contrôle.

SQL Server Express Edition

Lorsqu'un processus est joint à une base de données SQL Server Express Edition (fichier .mdf), celui-ci doit disposer d'autorisations d'administration. En général, cela implique que les bases de données SQL Server Express Edition ne peuvent pas être utilisées pour les sites Web de production, car le processus ASP.NET ne s'exécute pas (et ne doit pas s'exécuter) avec des privilèges d'administrateur. Par conséquent, utilisez les bases de données SQL Server Express Edition uniquement dans les cas suivants :

Utilisez la base de données comme une base de données de test lors du développement de votre application Web. Lorsque vous êtes prêt à déployer votre application, vous pouvez transférer la base de données de SQL Server Express Edition à une instance de production de SQL Server.
Utilisez la base de données si vous exécutez un site Web qui peut utiliser l'emprunt d'identité et que vous pouvez contrôler les privilèges de l'utilisateur emprunté. Dans la pratique, cette stratégie est utile uniquement si l'application s'exécute sur un réseau local (et non un site Web public).
Stockez le fichier .mdf dans le dossier App_Data de votre site, parce que le contenu du dossier ne sera pas retourné aux demandes HTTP directes. Vous devez également mapper l'extension .mdf à ASP.NET dans IIS et au gestionnaire HttpForbiddenHandler dans ASP.NET à l'aide de l'élément suivant du fichier Web.config du site :
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Pour plus d'informations sur la façon de mapper une extension de nom de fichier avec ASP.NET dans IIS, consultez Comment : enregistrer des gestionnaires HTTP.

Bases de données Microsoft Access

Les bases de données Microsoft Access (fichiers .mdb) contiennent moins de fonctionnalités de sécurité que les bases de données SQL Server. Elles ne sont pas recommandées pour les sites Web de production. Toutefois, si vous avez une raison valable d'utiliser un fichier .mdb dans le cadre de votre application Web, suivez les indications ci-après :

Stockez le fichier .mdb dans le dossier App_Data de votre site, parce que le contenu du dossier ne sera pas retourné aux demandes HTTP directes. Vous devez également mapper l'extension .mdb à ASP.NET dans IIS et au gestionnaire HttpForbiddenHandler dans ASP.NET à l'aide de l'élément suivant du fichier Web.config du site :
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Pour plus d'informations sur la façon de mapper une extension de nom de fichier avec ASP.NET dans IIS, consultez Comment : enregistrer des gestionnaires HTTP.
Ajoutez des autorisations appropriées pour le ou les comptes d'utilisateur qui lisent et écrivent dans le fichier .mdb. Si le site Web prend en charge l'accès anonyme, il s'agit généralement du compte d'utilisateur ASPNET local ou du compte SERVICE RÉSEAU. Étant donné qu'Access doit créer un fichier .ldb pour prendre en charge le verrouillage, le compte d'utilisateur doit disposer d'autorisations en écriture pour le dossier qui contient le fichier .mdb.
Si la base de données est protégée par un mot de passe, n'utilisez pas le contrôle AccessDataSource pour établir une connexion avec celle-ci, car le contrôle AccessDataSource ne prend pas en charge le passage des informations d'identification. Utilisez plutôt le contrôle SqlDataSource avec le fournisseur ODBC et passez les informations d'identification dans la chaîne de connexion. Veillez à sécuriser la chaîne de connexion comme décrit dans cette rubrique sous Chaînes de connexion.

Fichiers XML

Si vous stockez les données dans un fichier XML, placez le fichier XML dans le dossier App_Data de votre site Web, parce que le contenu du dossier ne sera pas retourné en réponse aux demandes HTTP directes.

Protection contre les entrées d'utilisateur nuisibles

Si votre application accepte les entrées d'utilisateurs, vous devez vérifier qu'elles ne contiennent pas de contenu nuisible qui peut compromettre votre application. Les entrées d'utilisateur malveillantes peuvent être utilisées pour lancer les attaques suivantes :

Injection de script Une attaque d'injection de script tente d'envoyer un script exécutable à votre application pour que d'autres utilisateurs l'exécutent. Une attaque d'injection de script classique envoie le script à une page qui le stocke dans une base de données, afin qu'un autre utilisateur qui consulte les données exécute le code par inadvertance.
Injection SQL Une attaque d'injection SQL tente de compromettre votre base de données (et éventuellement l'ordinateur sur lequel la base de données s'exécute) en créant des commandes SQL qui sont exécutées à la place, ou en plus, des commandes créées dans votre application.

Indications générales

Pour toutes les entrées d'utilisateur, suivez les indications ci-après :

Utilisez si possible des contrôles de validation pour limiter les entrées d'utilisateur aux valeurs acceptables.
Assurez-vous toujours que la valeur de la propriété IsValid est true avant d'exécuter votre code serveur. La valeur false signifie qu'un ou plusieurs contrôles de validation ont échoué.
Exécutez toujours une validation côté serveur même si le navigateur exécute également une validation côté client, afin de se protéger contre les utilisateurs contournant la validation côté client. Ceci est particulièrement vrai pour les contrôles CustomValidator ; n'utilisez pas uniquement la logique de validation côté client.
Revalidez toujours les entrées d'utilisateur dans la couche métier de votre application. Ne comptez pas sur le processus appelant pour fournir des données sûres. Par exemple, si vous utilisez le contrôle ObjectDataSource, ajoutez la validation redondante et le codage dans l'objet qui exécute les mises à jour de données.

Injection de script

Pour éviter toute attaque d'injection de script, suivez les indications ci-après :

Codez les entrées d'utilisateur à l'aide de la méthode HtmlEncode qui change HTML en représentation textuelle (par exemple, <b> devient &ltb>) et permet d'éviter l'exécution du balisage dans un navigateur.
Lorsque vous utilisez des objets paramètre pour transmettre des entrées d'utilisateur à une requête, ajoutez des gestionnaires pour les événements de pré-requête du contrôle de source de données et exécutez le codage dans ces événements. Par exemple, gérez l'événement Inserting du contrôle SqlDataSource, puis dans l'événement, codez la valeur de paramètre avant l'exécution de la requête.
Si vous utilisez le contrôle GridView avec des champs liés, affectez la valeur true à la propriété HtmlEncode de l'objet BoundField. Le contrôle GridView code les entrées d'utilisateur lorsque la ligne est en mode édition.
Pour les contrôles qui peuvent être affichés en mode édition, il est recommandé d'utiliser des modèles. Par exemple, les contrôles GridView, DetailsView, FormView, DataList et Login peuvent afficher des zones de texte modifiables. Toutefois, à l'exception du contrôle GridView (voir le point précédent), les contrôles ne valident pas ou ne codent pas automatiquement au format HTML les entrées d'utilisateur. Par conséquent, il est recommandé de créer des modèles pour ces contrôles, et dans le modèle, incluez un contrôle d'entrée comme le contrôle TextBox et ajoutez un contrôle de validation. De plus, lorsque vous extrayez la valeur du contrôle, vous devez la coder.

Injection SQL

Pour éviter toute attaque d'injection SQL, suivez les indications ci-après :

Ne créez pas de commandes SQL en concaténant les chaînes ensembles, notamment pour les chaînes qui contiennent des entrées d'utilisateurs. Utilisez plutôt des requêtes paramétrées ou des procédures stockées.
Si vous créez une requête paramétrée, utilisez des objets paramètre pour créer les valeurs des paramètres. Pour plus d'informations, consultez Utilisation de paramètres avec le contrôle SqlDataSource et Utilisation de paramètres avec des contrôles de source de données.

Chiffrement des données d'état d'affichage

Certains contrôles liés aux données, comme le contrôle GridView, doivent parfois faire persister des informations considérées comme sensibles. Par exemple, le contrôle GridView peut gérer une liste de clés dans la propriété DataKeys, même si ces informations ne s'affichent pas. Entre les allers-retours, le contrôle stocke les informations dans l'état d'affichage.

Comme les informations de l'état d'affichage sont codées et stockées avec le contenu de la page, elles peuvent être décodées et exposées à une source non désirée. Si vous devez stocker des informations sensibles dans l'état d'affichage, vous pouvez demander que la page chiffre les données d'état d'affichage. Pour chiffrer les données, affectez la valeur true à la propriété ViewStateEncryptionMode de la page.

Mise en cache

Il est recommandé d'éviter de stocker des informations sensibles dans l'objet Cache lorsque l'emprunt d'identité du client est activé et que les résultats de la source de données sont récupérés en fonction de l'identité du client. Si la mise en cache est activée, les données en cache relatives à un seul utilisateur peuvent être consultées par tous les utilisateurs et des informations sensibles pourraient être exposées à une source non désirée. L'emprunt d'identité du client est activé lorsque l'attribut impersonate de l'élément de configuration identity a la valeur true et que l'identification anonyme est désactivée pour l'application sur le serveur Web.

Partager via