Como configurar seu ASP.NET Web Apps e APIs para exigir HTTPS

Para qualquer aplicação que está hospedado na web, é essencial que a segurança é construída desde o começo.Permitir que seu aplicativo da web sirva tráfego seguro por HTTPS e aplicar essa política é uma das primeiras coisas que você deve implementar e isso é tão importante para aplicativos da web quanto para APIs.

com serviços bem estabelecidos como Let’s Encrypt, que fornecem certificados TLS gratuitos, não há mais nenhum motivo técnico ou financeiro atraente para não usar HTTPS para seus aplicativos da web.
neste artigo, demonstro como configurar corretamente seus aplicativos da web de forma que exijam HTTPS e cubro exemplos para ambos ASP.NET e ASP.NET projetos principais.

redirecionamento HTTPS

para se certificar de que seu site está devidamente protegido, depois de obter e instalar um novo certificado SSL/TLS brilhante, você vai querer ter certeza de que HTTPS está sempre sendo usado.

para seus aplicativos da web, por exemplo, aplicativos MVC, você pode configurar o tráfego para ser redirecionado de HTTP para HTTPS.

por vários motivos, ainda é aconselhável manter a porta HTTP padrão (porta 80) aberta e redirecionar seus usuários para a porta HTTPS padrão (porta 443) para aplicativos da web acessados por meio de um navegador.

isso faz parte do conselho oficial de melhores práticas dentro da documentação Let’s Encrypt. O principal pesquisador de segurança, Scott Helm, também tem um artigo muito bom que explica por que o fechamento da porta 80 é ruim para a segurança no contexto de aplicativos da web.

nas seções abaixo, demonstro como configurar o redirecionamento HTTPS para ASP.NET e ASP.NET principais aplicativos da web.

ASP.NET aplicativos da web

O ASP.NET MVC framework convenientemente tem um built-in RequireHttpsAttribute classe que podemos aproveitar.

quando aplicado, o atributo fará com que uma resposta de redirecionamento seja enviada de volta ao cliente se uma solicitação for enviada por HTTP em vez de HTTPS.

o atributo pode ser aplicado em uma base por controlador ou por ação. No entanto, recomendo aplicar o atributo globalmente para impor o redirecionamento HTTPS em todo o site, conforme mostrado abaixo.

 filtros.Adicionar (Novo RequireHttpsAttribute());

a linha de código acima normalmente aparece dentro de um método estático RegisterGlobalFilters em uma classe FilterConfig, de acordo com o trecho de código abaixo.

/// <sumário > / / / registra filtros globais./// </sumário>/// <param nome="filtros">A coleção de filtros para registrar</param>public static void RegisterGlobalFilters(GlobalFilterCollection filtros){ filtros.Adicionar (Novo HandleErrorAttribute ()); filtros.Adicionar (Novo RequireHttpsAttribute ()); filtros.Adicionar (Novo Autorizeattribute());}

em um ASP.NET aplicação, o método RegisterGlobalFilters é geralmente chamado na inicialização do método Application_Start dentro do Global.arquivo asax.

Antes de seguir em frente, é importante observar que os filtros globais se aplicarão apenas a solicitações HTTP que são passadas para seus controladores. Portanto, ainda é possível para um cliente acessar arquivos estáticos, como folhas de estilo e arquivos de script sobre HTTP inseguro.

você deve tomar cuidado para usar links relativos a quaisquer recursos estáticos que você está fazendo referência a partir de seu HTML, ou usar URLs absolutos com o esquema HTTPS para se certificar de que todo o conteúdo está sendo servido com segurança.

regras de reescrita

para tornar seu aplicativo da web ainda mais seguro, você pode configurar o redirecionamento no nível de proxy reverso, por exemplo, como parte de sua configuração do IIS. Isso garantirá que todas as solicitações recebidas sejam redirecionadas adequadamente.

no caso do IIS, você pode implementar isso por meio de uma regra de reescrita adicionando o seguinte à sua Web.arquivo de configuração.

<reescrever ><regras ><nome da regra="HTTP to https redirect" stopProcessing="true"> <URL de correspondência="(.*)" /> <condições> <adicionar input="{HTTPS}" pattern="off" ignoreCase="true" /> </condições> <ação tipo="Redirect" url="https://{HTTP_HOST}/{R:1}"redirectType="Permanente" /> </regra> <regras></reescrever>

IIS respeito acima regra de reescrita durante a manipulação de tráfego de entrada, redirecionando inseguro tráfego de HTTPS, antes de atingir o seu código de aplicativo.

tal como acontece com muitos aspectos da segurança, acredito que é melhor ter várias camadas de segurança em vigor. Se algo falhar ou estiver mal configurado em um nível, ter um fallback é sempre uma coisa boa.

. Net Core

. net Core também tem uma classe embutida RequireHttpsAttribute que pode ser aplicada em uma base por controlador/ação ou pode ser registrada globalmente.

o registro Global pode ser configurado dentro do método ConfigureServices da sua classe Startup, conforme demonstrado abaixo.

/// <sumário > / / / este método é chamado pelo tempo de execução./// Use este método para adicionar serviços ao contêiner./// </summary >/ / / <param name="services">a coleção de serviços de contêiner< / param>public void ConfigureServices(IServiceCollection services){ services.AddControllersWithViews (opções => opções.Filtro.Adicionar (Novo RequireHttpsAttribute()));}

o código acima faz a mesma coisa fundamentalmente como em um tradicional ASP.NET projeto.

no entanto, no. NET Core, podemos fazer melhor do que isso.O. NET Core também possui middleware de redirecionamento HTTPS integrado, que pode ser configurado com uma linha de código, conforme mostrado abaixo.

 app.UseHttpsRedirection ();

a linha de código acima deve ser adicionada ao método Configure da classe Startup. A maior parte do padrão ASP.NET principais modelos de aplicativos da web, por exemplo, para MVC, configure o middleware de redirecionamento HTTPS automaticamente.

abaixo está um exemplo do conteúdo típico do método Configure para referência.

/// <sumário > / / / este método é chamado pelo tempo de execução./// Use este método para configurar o pipeline de solicitação HTTP./// </sumário>/// <param nome="app">O aplicativo construtor de objeto usado para configurar o pipeline de solicitação</param>/// <param nome="env">O ambiente de hospedagem na web o aplicativo está sendo executado em</param>public void Configurar(IApplicationBuilder app, IWebHostEnvironment env){ if (env.O que é o IsDevelopment()) { app.Use o aplicativo UseDeveloperExceptionPage ();} else { app.UseExceptionHandler ("/Home / Error"); app.UseHsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); app.UseAuthorization (); app.Use endpoints (endpoints => { endpoints.MapControllerRoute (nome: "padrão", padrão: "{controller=Home}/{action=Index}/{id?}"); });}

então, por que o middleware de redirecionamento HTTPS é melhor do que o filtro RequireHttpsAttribute?

Bem, graças a forma que ASP.NET Núcleo web apps são hospedados, o middleware HTTPS redirecionamentos são aplicadas em um nível superior e, portanto, as solicitações para arquivos estáticos, como folhas de estilo e scripts também serão redirecionados, além de controlador de pedidos de ligação.

HSTS

outra peça útil de ASP.O middleware NET Core é o middleware HSTS e é configurado no exemplo acima por meio da seguinte linha de código.

 app.UseHsts ();

observe que, como acontece com muitos dos componentes de middleware integrados, muitos aspectos mais avançados do ASP.NET o middleware principal pode ser configurado dentro do método ConfigureServices da sua classe de inicialização.

o que é HSTS e por que devemos usá-lo?

o problema com o redirecionamento HTTPS por conta própria é com a primeira solicitação insegura que entra no aplicativo a partir de um cliente.

se a primeira solicitação HTTP recebida for interceptada por um’ homem no meio’, a integridade da solicitação será perdida. Por exemplo, o cliente pode ser redirecionado para outro lugar sem que eles percebam, por exemplo, para uma página de login falsa.

HSTS significa http Strict Transport Security e ajuda a resolver o problema descrito acima, informando ao navegador que um aplicativo da web só deve ser acessado por HTTPS.

ele faz isso retornando um cabeçalho Strict-Transport-Security na resposta para que as solicitações subsequentes usem HTTPS sem nenhum redirecionamento adicional. O navegador armazena em cache esta instrução para garantir que outras visitas ao site sejam via HTTPS sem mais redirecionamentos.

a primeira solicitação

Sim, tudo parece ótimo, mas e a primeira solicitação?Resolvemos a maior parte do problema, mas ainda não lidamos com a primeira solicitação recebida de um cliente que nunca visitou nosso site antes.

para ser super-seguro e fechar o loop nisso, podemos registrar nosso site para ser ‘pré-carregado’. Os navegadores mantêm uma lista de sites que estão em uma lista de “pré-carregamento” e, se o seu site estiver nesta lista, você nunca receberá uma solicitação insegura de um cliente, pois o navegador honrará o status de pré-carregamento.

você pode registrar seu site para ser pré-carregado acessando o site de pré-carregamento do HSTS e enviando uma solicitação para pré-carregá-lo.

abaixo está um exemplo de um cabeçalho HSTS com a diretiva de pré-carga especificada.

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

observe que é extremamente importante que você teste seu site completamente antes de habilitar o HSTS em um ambiente de produção para garantir que ele esteja funcionando corretamente em HTTPS. Isso é especialmente importante se você optar por pré-carregar seu site, pois isso não pode ser facilmente desfeito e pode levar meses para que seu site seja removido da lista de pré-carregamento.

eu recomendo configurar o HSTS para seus aplicativos da web. Se você também optar por ter seu site pré-carregado dependerá de seus requisitos de segurança específicos.

regras de saída

de acordo com a seção Regras de reescrita do início deste artigo, você também pode habilitar o HSTS no nível de proxy reverso.

abaixo está um exemplo de como configurar isso em uma Web.arquivo de configuração se você estiver hospedando seu aplicativo no IIS.

<reescrever> <outboundRules> <rule name="Adicionar Estrito-Transporte-Segurança quando HTTPS" enabled="true"> <corresponder serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" /> <condições> <adicionar input="{HTTPS}" pattern="no" ignoreCase="true" /> </condições> <ação tipo="Reescrever" value="max-age=31536000" /> </regra> </outboundRules></reescrever>

Agora o HSTS cabeçalho será definida para todo o tráfego HTTPS em seu site.

observe que a abordagem acima funcionará tanto para ASP.NET e ASP.NET principais aplicações. Você só precisa adicionar uma Web.Config arquivo para o seu projeto e certifique-se de que a propriedade ‘Copiar para Diretório de saída’ está definida como ‘Copiar se for mais recente’.

APIs

APIs diferem um pouco dos aplicativos da web normais que são acessados por humanos, tanto em seu design, casos de uso pretendidos quanto considerações de segurança.

abordaremos as melhores práticas para exigir HTTPS para APIs nas seções abaixo.

requer HTTPS?

tradicional ASP.NET os projetos de API da Web não têm acesso a um atributo interno para exigir HTTPS.

no entanto, isso não nos impede de criar o nosso próprio.

abaixo está um exemplo de como fazer isso.

/// <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 = novo UriBuilder ( pedido.RequestUri) {Scheme = Uri.Eurischemehttps, Port = 443}; actionContext.Resposta.Cabecalho.Localização = uriBuilder.Uri;} mais actionContext.Resposta = pedido.CreateResponse (HttpStatusCode.NotFound, "SSL é necessário"); }}

no exemplo acima, criei uma classe chamada RequireHttpsAttribute que deriva da classe AuthorizationFilterAttribute e estou substituindo o método virtual OnAuthorization.

para solicitações GET, o método acima informa os clientes sobre o URL correto usando o esquema HTTPS, retornando isso no cabeçalho do local. Para todas as outras solicitações, a mensagem ‘SSL é necessária’ é simplesmente retornada.

embora isso faça sentido ao chamar uma API de um navegador, um dos problemas com o código acima é que ele está retornando um código de status de redirecionamento que a maioria dos clientes da API não entenderá.

dependendo do seu ponto de vista, o código acima pode ser alterado para definir o código de status HTTP para outra coisa, como solicitação incorreta, em vez de tentar redirecionar o cliente.

podemos implementar algo semelhante em .Net Core criando nossa própria classe, como ApiRequireHttpsAttribute, que deriva da classe RequireHttpsAttribute embutida. Podemos então substituir o método virtual HandleNonHttpsRequest e definir o código de resposta de acordo, de acordo com o código de amostra abaixo.

/// <sumário > / / / chamado se a solicitação não for recebida por HTTPS./// </sumário>/// <param nome="filterContext">O contexto de filtro</param>protected override void HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Resultado = New StatusCodeResult(400);}

o código acima define o código de status HTTP para a resposta a uma solicitação incorreta (400). Ele pode ser alterado para incluir uma mensagem na resposta ou qualquer outra lógica personalizada é necessária.

não ouvir?

Ok, então analisamos como forçar os clientes da API a usar HTTPS sempre que tentarem usar HTTP.

no entanto, esta é a melhor opção?

Melhor prática dita que devemos ter várias camadas de segurança, mas também dita que devemos implementar a segurança, o mais cedo possível.

na verdade, a coisa mais segura que podemos fazer no contexto das APIs é impedi-las de ouvir em uma porta não segura em primeiro lugar. Este conselho é espelhado no Microsoft Docs para ASP.NET Core.

claro, não podemos impedir que um cliente de API tente alcançar nossa API de forma insegura. No entanto, neste caso, é culpa do integrador de API e não algo pelo qual podemos fazer qualquer coisa significativa para evitar.

resumo

neste artigo, abordei como impor HTTPS em seus aplicativos e APIs da web e discuti as soluções mais apropriadas e seguras para ambos os cenários.

a principal coisa a tirar é que você deve implementar várias camadas de segurança para o seu aplicativo e, sempre que possível, impor a segurança o mais cedo possível.

use o HSTS e aproveite o poder de sua configuração de proxy reverso para lidar com solicitações de maneira segura.