Thèmes de sécurité ASP.NET Core
ASP.NET Core permet aux développeurs de configurer et de gérer la sécurité. La liste suivante fournit des liens vers des rubriques sur la sécurité :
- Authentification
- Autorisation
- Protection des données
- Application de HTTPS
- Stockage sécurisé des secrets des applications lors du développement
- Prévention XSRF/CSRF
- CORS (Cross Origin Resource Sharing)
- Attaques de scripting intersite (XSS)
Ces fonctionnalités de sécurité vous permettent de créer des applications ASP.NET Core robustes et sécurisées.
Pour une couverture de sécurité Blazor, qui complète ou remplace les instructions de ce nœud, consultez Authentification et autorisation ASP.NET Core Blazor et les autres articles du nœud Sécurité et Identity de Blazor.
Fonctionnalités de sécurité ASP.NET Core
ASP.NET Core offre un grand nombre d’outils et de bibliothèques pour sécuriser vos applications ASP.NET Core, notamment des fournisseurs d’identity intégrés et services d’identity tiers, comme Facebook, Twitter et LinkedIn. ASP.NET Core fournit plusieurs approches pour stocker des secrets d’application.
Authentification ou autorisation
L’authentification est un processus dans lequel un utilisateur fournit des informations d’identification qui sont ensuite comparées à celles stockées dans un système d’exploitation, une base de données, une application ou une ressource. Si elles correspondent, les utilisateurs sont authentifiés et peuvent alors effectuer les actions pour lesquelles ils disposent d’autorisations déterminées par un processus d’autorisation. L’autorisation désigne le processus qui détermine ce qu’un utilisateur est autorisé à faire.
Vous pouvez aussi vous représenter l’authentification comme un moyen d’entrer dans un espace, tel qu’un serveur, une base de données, une application ou une ressource, tandis que l’autorisation consiste à définir quelles actions l’utilisateur peut effectuer sur quels objets à l’intérieur de cet espace (serveur, base de données ou application).
Failles de sécurité courantes dans les logiciels
ASP.NET Core et Entity Framework contiennent des fonctionnalités qui vous aident à sécuriser vos applications et à empêcher les violations de sécurité. La liste de liens ci-après vous permet d’accéder à une documentation décrivant en détail des techniques destinées à éviter les failles de sécurité les plus courantes dans les applications web :
- Attaques de scripting intersite (XSS)
- Attaques par injection de code SQL
- Attaque par falsification de requête intersites (XSRF/CSRF)
- Attaques par redirection ouverte
Il existe d’autres failles de sécurité que vous devez connaître. Pour plus d’informations, consultez les autres articles de la section Sécurité et Identity de la table des matières.
Flux d’authentification sécurisés
Nous vous recommandons d’utiliser l’option d’authentification sécurisée la plus sécurisée. Pour les services Azure, l’authentification la plus sécurisée est Identités managées.
Évitez l’octroi d’informations d’identification avec mot de passe du propriétaire de la ressource, car :
- Cela expose le mot de passe de l’utilisateur au client.
- Cela peut constituer un risque de sécurité significatif.
- Cela doit être utilisé uniquement lorsque les autres flux d’authentification sont impossibles.
Les identités managées sont un moyen sécurisé de s’authentifier auprès de services sans avoir à stocker les informations d’identification dans le code, les variables d’environnement ou les fichiers de configuration. Les identités managées sont disponibles pour les services Azure et peuvent être utilisées avec Azure SQL, Stockage Azure et d’autres services Azure :
- Identités managées dans Microsoft Entra pour Azure SQL
- Identités managées pour App Service et Azure Functions
- Flux d’authentification sécurisés
Quand l’application est déployée sur un serveur de test, une variable d’environnement peut être utilisée pour définir la chaîne de connexion à un serveur de base de données de test. Pour plus d’informations, consultez Configuration. Les variables d'environnement sont généralement stockées en texte brut non crypté. Si la machine ou le processus est compromis, les variables d'environnement peuvent être consultées par des parties non fiables. Nous vous recommandons d’utiliser des variables d’environnement pour stocker une chaîne de connexion de production, car ce n’est pas l’approche la plus sécurisée.
Instructions relatives aux données de configuration :
- Ne stockez jamais des mots de passe ou d’autres données sensibles dans le code du fournisseur de configuration ou dans les fichiers de configuration en texte clair. Vous pouvez utiliser l’outil Secret Manager pour stocker des secrets lors du développement.
- N’utilisez aucun secret de production dans les environnements de développement ou de test.
- Spécifiez les secrets en dehors du projet afin qu’ils ne puissent pas être validés par inadvertance dans un référentiel de code source.
Instructions relatives aux données de configuration :
- Ne stockez jamais des mots de passe ou d’autres données sensibles dans le code du fournisseur de configuration ou dans les fichiers de configuration en texte clair. Vous pouvez utiliser l’outil Secret Manager pour stocker des secrets lors du développement.
- N’utilisez aucun secret de production dans les environnements de développement ou de test.
- Spécifiez les secrets en dehors du projet afin qu’ils ne puissent pas être validés par inadvertance dans un référentiel de code source.
Pour plus d’informations, consultez l’article suivant :
- Recommandations relatives aux meilleures pratiques liées aux identity managées
- Connexion de votre application à des ressources sans gérer les informations d’identification dans votre code
- Services Azure qui peuvent utiliser des identités managées pour accéder à d’autres services
- Bonne pratique actuelle en matière de sécurité IETF OAuth 2.0
Pour plus d’informations sur d’autres fournisseurs de cloud, consultez :
- AWS (Amazon Web Services) : AWS Service de gestion de clés (KMS)
- Vue d’ensemble de Google Cloud Service de gestion de clés
