Comment configurer votre ASP.NET Applications Web et API pour exiger HTTPS

Pour toute application hébergée sur le Web, il est essentiel que la sécurité soit intégrée dès le départ.
Permettre à votre application Web de diffuser un trafic sécurisé via HTTPS et appliquer cette stratégie est l’une des premières choses que vous devez implémenter, ce qui est tout aussi important pour les applications Web que pour les API.

Avec des services bien établis comme Let’s Encrypt qui fournissent des certificats TLS gratuits, il n’y a plus de raison technique ou financière impérieuse de ne pas utiliser HTTPS pour vos applications Web.
Dans cet article, je montre comment configurer correctement vos applications Web de manière à ce qu’elles nécessitent HTTPS et je couvre des exemples pour les deux ASP.NET et ASP.NET Projets de base.

Redirection HTTPS

Afin de vous assurer que votre site est correctement sécurisé, après avoir obtenu et installé un nouveau certificat SSL / TLS brillant, vous voudrez vous assurer que HTTPS est toujours utilisé.

Pour vos applications Web, par exemple les applications MVC, vous pouvez configurer le trafic pour qu’il soit redirigé de HTTP vers HTTPS.

Pour diverses raisons, il est toujours conseillé de garder le port HTTP par défaut (port 80) ouvert et de rediriger vos utilisateurs vers le port HTTPS par défaut (port 443) pour les applications Web accessibles via un navigateur.

Ceci fait partie des conseils officiels sur les meilleures pratiques dans la documentation Let’s Encrypt. Le meilleur chercheur en sécurité, Scott Helm, a également un très bon article qui explique pourquoi la fermeture du port 80 est mauvaise pour la sécurité dans le contexte des applications Web.

Dans les sections ci-dessous, je montre comment configurer la redirection HTTPS pour ASP.NET et ASP.NET Applications web de base.

ASP.NET applications web

Le ASP.NET Le framework MVC a commodément une classe RequireHttpsAttribute intégrée dont nous pouvons profiter.

Une fois appliqué, l’attribut entraînera le renvoi d’une réponse de redirection au client si une requête a été envoyée via HTTP au lieu de HTTPS.

L’attribut peut être appliqué par contrôleur ou par action. Cependant, je recommande fortement d’appliquer l’attribut globalement pour appliquer la redirection HTTPS sur l’ensemble du site, comme indiqué ci-dessous.

 filtres.Ajouter (nouveau RequireHttpsAttribute());

La ligne de code ci-dessus apparaît généralement dans une méthode statique RegisterGlobalFilters dans une classe FilterConfig, selon l’extrait de code ci-dessous.

/// < summary > /// Enregistre les filtres globaux.///</summary > ///<param name="filters"> La collection de filtres à enregistrer </param > public static void RegisterGlobalFilters (filtres GlobalFilterCollection) { filtres.Ajouter (nouveau gestionnaire d'attribut()); filtres.Ajouter (nouveau RequireHttpsAttribute()); filtres.Ajouter (nouvelle AuthorizeAttribute());}

Dans un ASP.NET application, la méthode RegisterGlobalFilters est généralement appelée au démarrage à partir de la méthode Application_Start dans le Global.fichier asax.

Avant de passer à autre chose, il est important de noter que les filtres globaux ne s’appliqueront qu’aux requêtes HTTP transmises à vos contrôleurs. Par conséquent, il est toujours possible pour un client d’accéder à des fichiers statiques tels que des feuilles de style et des fichiers de script via HTTP non sécurisé.

Vous devez prendre soin d’utiliser des liens relatifs à toutes les ressources statiques auxquelles vous faites référence à partir de votre code HTML, ou d’utiliser des URL absolues avec le schéma HTTPS pour vous assurer que tout le contenu est servi en toute sécurité.

Règles de réécriture

Pour rendre votre application Web encore plus sécurisée, vous pouvez configurer la redirection au niveau du proxy inverse, par exemple dans le cadre de votre configuration IIS. Cela garantira que toutes les demandes entrantes sont redirigées de manière appropriée.

Dans le cas d’IIS, vous pouvez l’implémenter via une règle de réécriture en ajoutant ce qui suit à votre site Web.fichier de configuration.

 < réécrire > < règles > < nom de la règle="redirection HTTP vers HTTPS" stopProcessing="true" > < match url="(.*)" /> < conditions > < add input="{HTTPS}" pattern="off" ignoreCase="true" /> </ conditions > < action type="Redirect" url="https://{HTTP_HOST}/{R:1}"redirectType="Permanent" /> </ règle > </ règles > < / rewrite > 

IIS respectera la règle de réécriture ci-dessus lors de la gestion du trafic entrant, redirigeant le trafic non sécurisé vers HTTPS avant qu’il n’atteigne le code de votre application.

Comme pour de nombreux aspects de la sécurité, je pense qu’il est préférable d’avoir plusieurs couches de sécurité en place. Si quelque chose échoue ou est mal configuré à un niveau, avoir une solution de secours est toujours une bonne chose.

.NET Core

.NET Core a également une classe RequireHttpsAttribute intégrée qui peut être appliquée soit par contrôleur / action, soit elle peut être enregistrée globalement.

L’enregistrement global peut être configuré dans la méthode ConfigureServices de votre classe Startup, comme illustré ci-dessous.

/// < summary > /// Cette méthode est appelée par le runtime./// Utilisez cette méthode pour ajouter des services au conteneur.///</ summary > /// <param name="services" > La collection de services de conteneurs </param > public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews(options=> options.Filtrer.Ajouter (nouveau RequireHttpsAttribute()));}

Le code ci-dessus fait fondamentalement la même chose que dans un code traditionnel ASP.NET projet.

Cependant, dans .NET Core, nous pouvons faire mieux que cela.

.NET Core dispose également d’un middleware de redirection HTTPS intégré, qui peut être configuré avec une ligne de code, comme indiqué ci-dessous.

 app.UseHttpsRedirection(); 

La ligne de code ci-dessus doit être ajoutée à la méthode Configure de la classe Startup. La plupart de la norme ASP.NET Modèles d’application Web de base, par exemple pour MVC, configurez automatiquement le middleware de redirection HTTPS.

Voici un exemple du contenu typique de la méthode Configure pour référence.

/// < summary > /// Cette méthode est appelée par le runtime./// Utilisez cette méthode pour configurer le pipeline de requêtes HTTP.///</ résumé > /// < param name="app" > L'objet générateur d'application utilisé pour configurer le pipeline de requêtes </param> ///< param name="env"> L'environnement d'hébergement Web dans lequel l'application s'exécute </param > public void Configure (application IApplicationBuilder, application IWebHostEnvironment env) { if(env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else {app.UseExceptionHandler("/Home/Error"); app.Utilisez la fonction UseHsts(); } app.Utilisez la fonction redirection(); app.Fichier d'utilisation(); app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints=> { endpoints.MapControllerRoute(nom: "default", motif: "{controller=Home} /{action=Index} /{id?}"); });}

Alors, pourquoi le middleware de redirection HTTPS est-il meilleur que le filtre RequireHttpsAttribute ?

Eh bien, grâce à la façon dont ASP.NET Les principales applications Web sont hébergées, les redirections HTTPS du middleware sont appliquées à un niveau supérieur et, par conséquent, les demandes de fichiers statiques tels que les feuilles de style et les scripts seront également redirigées en plus des demandes liées au contrôleur.

HSTS

Un autre morceau utile d’ASP.Le middleware NET Core est le middleware HSTS et il est configuré dans l’exemple ci-dessus via la ligne de code suivante.

 app.UseHsts(); 

Notez que, comme avec de nombreux composants middleware intégrés, de nombreux aspects plus avancés de ASP.NET Le middleware de base peut être configuré dans la méthode ConfigureServices de votre classe de démarrage.

Qu’est-ce que HSTS et pourquoi devrions-nous l’utiliser?

Le problème de la redirection HTTPS en soi provient de la première demande non sécurisée qui entre dans l’application à partir d’un client.

Si la première requête HTTP entrante est interceptée par un ” homme au milieu “, l’intégrité de la requête sera perdue. Par exemple, le client peut être redirigé ailleurs sans qu’il s’en rende compte, par exemple, vers une fausse page de connexion.

HSTS signifie HTTP Strict Transport Security et il aide à résoudre le problème décrit ci-dessus en informant le navigateur qu’une application Web ne doit être accessible que via HTTPS.

Il le fait en renvoyant un en-tête Strict-Transport-Security dans la réponse afin que les requêtes suivantes utilisent HTTPS sans autres redirections. Le navigateur met en cache cette instruction pour s’assurer que les visites ultérieures sur le site se feront via HTTPS sans plus de redirections.

La toute première demande

Oui, tout cela sonne bien, mais qu’en est-il de cette toute première demande?

Nous avons résolu la majeure partie du problème, mais nous n’avons toujours pas traité la toute première demande reçue d’un client qui n’a jamais visité notre site auparavant.

Afin d’être super-sécurisé et de boucler la boucle à ce sujet, nous pouvons enregistrer notre site pour qu’il soit “préchargé”. Les navigateurs conservent une liste de sites figurant sur une liste de “préchargement” et si votre site figure sur cette liste, vous ne recevrez jamais de demande non sécurisée de la part d’un client, car le navigateur honorera le statut de préchargement.

Vous pouvez enregistrer votre site pour qu’il soit préchargé en vous rendant sur le site Web de préchargement HSTS et en soumettant une demande de préchargement.

Voici un exemple d’en-tête HSTS avec la directive de précharge spécifiée.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Notez qu’il est extrêmement important que vous testiez soigneusement votre site avant d’activer HSTS dans un environnement de production pour vous assurer qu’il fonctionne correctement via HTTPS. Ceci est particulièrement important si vous choisissez de précharger votre site car cela ne peut pas être facilement annulé et cela peut prendre des mois pour que votre site soit retiré de la liste de préchargement.

Je recommande fortement de configurer HSTS pour vos applications web. Que vous choisissiez ou non de précharger votre site dépendra de vos exigences de sécurité spécifiques.

Règles sortantes

Selon la section Règles de réécriture de cet article, vous pouvez également activer HSTS au niveau du proxy inverse.

Voici un exemple de configuration dans un Web.fichier de configuration si vous hébergez votre application dans IIS.

 < réécriture > < outboundRules > < nom de règle ="Ajouter une sécurité de transport stricte lorsque HTTPS" enabled="true"> < match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*"/> < conditions > < add input="{HTTPS}" pattern="on" ignoreCase="true" /> </ conditions > < action type="Rewrite" value="max-age=31536000" /> </ règle > < / outboundRules > </ rewrite > 

Maintenant, l’en-tête HSTS sera défini pour tout le trafic HTTPS sur votre site.

Notez que l’approche ci-dessus fonctionnera pour les deux méthodes traditionnelles ASP.NET et ASP.NET Applications de base. Vous avez juste besoin d’ajouter un Web.configurez le fichier dans votre projet et assurez-vous que la propriété ‘Copier dans le répertoire de sortie’ est définie sur ‘Copier si elle est plus récente’.

API

Les API diffèrent un peu des applications Web normales auxquelles les humains accèdent, à la fois par leur conception, les cas d’utilisation prévus et les considérations de sécurité.

Nous aborderons les meilleures pratiques pour exiger HTTPS pour les API dans les sections ci-dessous.

Nécessitant HTTPS ?

Traditionnel ASP.NET Les projets d’API Web n’ont pas accès à un attribut intégré pour exiger HTTPS.

Cependant, cela ne nous empêche pas de créer le nôtre.

Voici un exemple de la façon de procéder.

/// <summary>/// Called when a process requests authorization./// </summary>/// <param name="actionContext">The action context</param>public override void OnAuthorization(HttpActionContext actionContext){ HttpRequestMessage request = actionContext.Request; if (request.RequestUri.Scheme != Uri.UriSchemeHttps) { if (request.Method.Equals(HttpMethod.Get)) { actionContext.Response = request.CreateResponse(HttpStatusCode.Found, "SSL is required"); // Provide the correct URL to the user via the Location header. var uriBuilder = nouveau UriBuilder(request.RequestUri) { Scheme=Uri.UriSchemeHttps, Port=443}; actionContext.Réponse.Tête.Emplacement = uriBuilder.Uri; } else actionContext.Réponse = demande.La réponse à la création (HttpStatusCode.NotFound, " SSL est requis"); }}

Dans l’exemple ci-dessus, j’ai créé une classe appelée RequireHttpsAttribute qui dérive de la classe AuthorizationFilterAttribute et je remplace la méthode virtuelle OnAuthorization.

Pour les requêtes GET, la méthode ci-dessus informe les clients de l’URL correcte à l’aide du schéma HTTPS en la renvoyant dans l’en-tête Location. Pour toutes les autres demandes, le message “SSL est requis” est simplement renvoyé.

Bien que cela soit logique lors de l’appel d’une API à partir d’un navigateur, l’un des problèmes avec le code ci-dessus est qu’il renvoie un code d’état de redirection que la plupart des clients API ne comprendront pas.

Selon votre point de vue, le code ci-dessus pourrait plutôt être modifié pour définir le code d’état HTTP sur autre chose, telle qu’une demande incorrecte, plutôt que d’essayer de rediriger le client.

Nous pouvons implémenter quelque chose de similaire.NET Core en créant notre propre classe telle que ApiRequireHttpsAttribute qui dérive de la classe RequireHttpsAttribute intégrée. Nous pouvons ensuite remplacer la méthode virtuelle HandleNonHttpsRequest et définir le code de réponse en conséquence, selon l’exemple de code ci-dessous.

/// < summary > /// Appelé si la requête n'est pas reçue via HTTPS.///</ summary > ///< param name="filterContext" > Le contexte du filtre </param > protégé override void HandleNonHttpsRequest(AuthorizationFilterContext filterContext) { filterContext.Résultat = nouveau StatusCodeResult (400);} 

Le code ci-dessus définit le code d’état HTTP pour la réponse à une requête incorrecte (400). Il pourrait être modifié pour inclure un message dans la réponse ou toute autre logique personnalisée requise.

Vous n’écoutez pas?

Ok, nous avons donc examiné comment forcer les clients API à utiliser HTTPS chaque fois qu’ils tentent d’utiliser HTTP.

Cependant, est-ce la meilleure option?

La meilleure pratique exige que nous ayons plusieurs couches de sécurité, mais elle exige également que nous mettions en œuvre la sécurité le plus tôt possible.

En fait, la chose la plus sécurisée que nous puissions faire dans le contexte des API est de les empêcher d’écouter sur un port non sécurisé en premier lieu. Ce conseil est reflété dans les documents Microsoft pour ASP.NET Noyau.

Bien sûr, nous ne pouvons pas empêcher un client API d’essayer d’atteindre notre API de manière non sécurisée. Cependant, dans ce cas, c’est la faute de l’intégrateur d’API et non quelque chose pour lequel nous pouvons faire quelque chose de significatif pour empêcher.

Résumé

Dans cet article, j’ai expliqué comment appliquer HTTPS à vos applications Web et API et j’ai discuté des solutions les plus appropriées et sécurisées pour les deux scénarios.

La chose clé à retenir est que vous devez implémenter plusieurs couches de sécurité pour votre application et, si possible, appliquer la sécurité le plus tôt possible.

Utilisez HSTS et tirez parti de la puissance de votre configuration de proxy inverse pour gérer les requêtes de manière sécurisée.