Cómo configurar su ASP.NET Para requerir HTTPS

Para cualquier aplicación alojada en la web, es esencial que la seguridad esté incorporada desde el principio.
Permitir que su aplicación web sirva tráfico seguro a través de HTTPS y hacer cumplir esta directiva es una de las primeras cosas que debe implementar, y esto es tan importante para las aplicaciones web como para las API.

Con servicios bien establecidos como Let’s Encrypt, que proporcionan certificados TLS gratuitos, ya no hay ninguna razón técnica o financiera convincente para no usar HTTPS para sus aplicaciones web.
En este artículo, muestro cómo configurar correctamente sus aplicaciones web de manera que requieran HTTPS y cubro ejemplos para ambos ASP.NET y ASP.NET Proyectos básicos.

Redirección HTTPS

Para asegurarse de que su sitio esté correctamente protegido, después de obtener e instalar un nuevo certificado SSL/TLS brillante, querrá asegurarse de que siempre se use HTTPS.

Para sus aplicaciones web, por ejemplo, aplicaciones MVC, puede configurar el tráfico para que se redirija de HTTP a HTTPS.

Por diversas razones, es recomendable mantener abierto el puerto HTTP predeterminado (puerto 80) y redirigir a los usuarios al puerto HTTPS predeterminado (puerto 443) para las aplicaciones web a las que se accede a través de un navegador.

Esto es parte de los consejos oficiales de mejores prácticas dentro de la documentación de Let’s Encrypt. El principal investigador de seguridad, Scott Helm, también tiene un artículo muy bueno que explica por qué cerrar el puerto 80 es malo para la seguridad en el contexto de las aplicaciones web.

En las siguientes secciones, muestro cómo configurar la redirección HTTPS para ASP.NET y ASP.NET Aplicaciones web básicas.

ASP.NET aplicaciones web

ASP.NET MVC framework convenientemente tiene una clase RequireHttpsAttribute incorporada que podemos utilizar.

Cuando se aplica, el atributo hará que se envíe una respuesta de redirección al cliente si se envió una solicitud a través de HTTP en lugar de HTTPS.

El atributo se puede aplicar por controlador o por acción. Sin embargo, recomiendo encarecidamente aplicar el atributo globalmente para imponer la redirección HTTPS en todo el sitio, como se muestra a continuación.filtros

.Añadir (nuevo atributo RequireHttpsAttribute());

La línea de código anterior aparece típicamente dentro de un método estático RegisterGlobalFilters en una clase FilterConfig, según el fragmento de código a continuación.

/// <resumen> / / / Registra Filtros Globales.///< / summary> / / / < param name = "filters" > La colección de filtros para registrar< / param> public static void RegisterGlobalFilters(GlobalFilterCollection filters){ filtros.Add (new HandleErrorAttribute ()); filtros.Add (new RequireHttpsAttribute ()); filtros.Añadir (nuevo atributo de autorización());}

En un ASP.NET aplicación, el método RegisterGlobalFilters generalmente se llama al inicio desde el método Application_Start dentro del Global.archivo asax.

Antes de continuar, es importante tener en cuenta que los filtros globales solo se aplicarán a las solicitudes HTTP que se pasen a sus controladores. Por lo tanto, aún es posible que un cliente acceda a archivos estáticos como hojas de estilo y archivos de script a través de HTTP inseguro.

Debe tener cuidado de usar enlaces relativos a cualquier recurso estático al que haga referencia desde su HTML, o usar URL absolutas con el esquema HTTPS para asegurarse de que todo el contenido se sirva de forma segura.

Reglas de reescritura

Para hacer que su aplicación web sea aún más segura, puede configurar la redirección a nivel de proxy inverso, por ejemplo, como parte de su configuración de IIS. Esto asegurará que todas las solicitudes entrantes se redirigan adecuadamente.

En el caso de IIS, puede implementar esto mediante una regla de reescritura agregando lo siguiente a su Web.archivo de configuración.

 < reescribir> < reglas> < nombre de la regla = "redirección HTTP a HTTPS" stopProcessing="true" > < url de coincidencia="(.*)" /> <condiciones> <add input="{HTTPS}" pattern="off" IgnoreCase="true" /> </condiciones> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanente" /> </regla> </reglas></reescribir>

IIS respetará la regla de reescritura anterior al manejar el tráfico entrante, redirigiendo el tráfico inseguro a HTTPS antes de que llegue al código de la aplicación.

Al igual que con muchos aspectos de la seguridad, creo que es mejor tener múltiples capas de seguridad en su lugar. Si algo falla o está mal configurado en un nivel, tener un respaldo siempre es algo bueno.

. NET Core

. NET Core también tiene una clase incorporada RequireHttpsAttribute que se puede aplicar por controlador/acción o se puede registrar globalmente.

El registro global se puede configurar dentro del método ConfigureServices de su clase Startup, como se muestra a continuación.

/// <summary>/// Este método es llamado por el tiempo de ejecución./// Utilice este método para agregar servicios al contenedor.///< / resumen> / / / < param name = "servicios" > La colección de servicios de contenedores< / param> servicios de configuración de vacío público (IServiceCollection services){ servicios.AddControllersWithViews (opciones => opciones.Filtro.Añadir (nuevo atributo RequireHttpsAttribute()));}

El código anterior hace lo mismo fundamentalmente que en un código tradicional ASP.NET proyecto.

Sin embargo, en.NET Core, podemos hacer algo mejor que esto.

. NET Core también tiene un middleware de redirección HTTPS integrado, que se puede configurar con una línea de código, como se muestra a continuación.

 app.UseHttpsRedirection();

La línea de código anterior debe agregarse al método Configure de la clase Startup. La mayor parte del estándar ASP.NET Plantillas de aplicaciones web básicas, por ejemplo, para MVC, configure el middleware de redirección HTTPS automáticamente.

A continuación se muestra un ejemplo del contenido típico del método Configure para referencia.

/// <summary>/// Este método es llamado por el tiempo de ejecución./// Utilice este método para configurar la canalización de solicitudes HTTP./// </summary>/// <param name="app">El objeto creador de aplicaciones utilizado para configurar la canalización de solicitudes</param>/// <param name="env">El entorno de alojamiento web en el que se ejecuta la aplicación</param>configuración de vacío público(aplicación IApplicationBuilder, IWebHostEnvironment env){ if (env.IsDevelopment ()) {app.UseDeveloperExceptionPage ();} else { app.Use la aplicación ExceptionHandler("/Home/Error");.UseHsts ();} app.Use la aplicación Httpsredirection ();.UseStaticFiles (); app.Aplicación UseRouting ();.UseAuthorization (); app.UseEndpoints (endpoints = > { endpoints.Mapcontroller Ruta (nombre: "predeterminado", patrón: "{controlador = Inicio} / {acción = Índice} / {id?}"); });}

Entonces, ¿por qué el middleware de redirección HTTPS es mejor que el filtro RequireHttpsAttribute?

Bueno, gracias a la forma en que ASP.NET Las aplicaciones web principales están alojadas, los redireccionamientos HTTPS de middleware se aplican a un nivel superior y, por lo tanto, las solicitudes de archivos estáticos, como hojas de estilo y scripts, también se redirigirán, además de las solicitudes vinculadas al controlador.

HSTS

Otra pieza útil de ASP.El middleware NET Core es el middleware HSTS y se configura en el ejemplo anterior a través de la siguiente línea de código.

 app.UseHsts ();

Tenga en cuenta que, al igual que con muchos de los componentes de middleware integrados, muchos aspectos más avanzados de ASP.NET El middleware central se puede configurar dentro del método ConfigureServices de su clase de inicio.

¿Qué es HSTS y por qué deberíamos usarlo?

El problema con la redirección HTTPS por sí sola es con la primera solicitud insegura que llega a la aplicación desde un cliente.

Si la primera solicitud HTTP entrante es interceptada por un ‘man in the middle’, la integridad de la solicitud se perderá. Por ejemplo, el cliente podría ser redirigido a otro lugar sin que se den cuenta, por ejemplo, a una página de inicio de sesión falsa.

HSTS significa HTTP Strict Transport Security y ayuda a resolver el problema descrito anteriormente al informar al navegador de que solo se debe acceder a una aplicación web a través de HTTPS.

Lo hace devolviendo un encabezado de Seguridad de transporte estricta en la respuesta para que las solicitudes posteriores usen HTTPS sin redirecciones adicionales. El navegador almacena en caché esta instrucción para garantizar que las visitas posteriores al sitio se realicen a través de HTTPS sin más redirecciones.

La primera solicitud

Sí, todo eso suena genial, pero ¿qué pasa con esa primera solicitud?

Hemos resuelto la mayor parte del problema, pero todavía no hemos atendido la primera solicitud recibida de un cliente que nunca ha visitado nuestro sitio antes.

Para ser súper seguros y cerrar el bucle en esto, podemos registrar nuestro sitio para que esté “precargado”. Los navegadores mantienen una lista de sitios que están en una lista de “precarga” y si su sitio está en esta lista, nunca recibirá una solicitud insegura de un cliente, ya que el navegador respetará el estado de precarga.

Puede registrar su sitio para que se precarge yendo al sitio web de precarga de HSTS y enviando una solicitud para que se precarge.

A continuación se muestra un ejemplo de encabezado HSTS con la directiva de precarga especificada.

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

Tenga en cuenta que es extremadamente importante que pruebe su sitio a fondo antes de habilitar HSTS en un entorno de producción para asegurarse de que funciona correctamente a través de HTTPS. Esto es especialmente importante si elige precarga de su sitio, ya que no se puede deshacer fácilmente y podría tomar meses eliminar su sitio de la lista de precarga.

Recomiendo encarecidamente configurar HSTS para sus aplicaciones web. El hecho de que también elija o no tener su sitio precargado dependerá de sus requisitos de seguridad específicos.

Reglas de salida

De acuerdo con la sección Reglas de reescritura de este artículo, también puede habilitar HSTS en el nivel de proxy inverso.

A continuación se muestra un ejemplo de cómo configurar esto dentro de una web.archivo de configuración si aloja su aplicación en IIS.

 < reescribir> < Rebasar los límites> < nombre de la regla = "Agregar Seguridad de transporte estricta cuando HTTPS" habilitado = "verdadero" > < emparejar servidor Variable= "RESPONSE_Strict_Transport_Security" patrón=".*" /> <condiciones> <add input="{HTTPS}" pattern="on" ignoreCase="true" /> </condiciones> <tipo de acción="Reescribir" value="max-age=31536000" /> </la regla> </outboundRules></reescribir>

Ahora, la HSTS encabezado se establecerá para todo el tráfico HTTPS en su sitio.

Tenga en cuenta que el enfoque anterior funcionará tanto para ASP.NET y ASP.NET Aplicaciones principales. Solo necesitas agregar una Web.configure el archivo a su proyecto y asegúrese de que la propiedad ‘Copiar al directorio de salida’ esté establecida en ‘Copiar si es más reciente’.

API

Las API difieren bastante de las aplicaciones web normales a las que acceden los humanos, tanto en su diseño, casos de uso previstos como en consideraciones de seguridad.

Cubriremos las prácticas recomendadas para requerir HTTPS para las API en las secciones a continuación.

¿Requiere HTTPS?

Tradicional ASP.NET Los proyectos de API Web no tienen acceso a un atributo integrado para requerir HTTPS.

Sin embargo, esto no nos impide crear el nuestro.

A continuación se muestra un ejemplo de cómo hacer esto.

/// <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 = nuevo uribuidor ( request.RequestUri) { Scheme = Uri.UriSchemeHttps, Port = 443 }; ActionContext.Respuesta.Cabecera.Ubicación = uriBuilder.Uri;} else ActionContext.Respuesta = solicitud.CreateResponse(HttpStatusCode.NotFound, "Se requiere SSL"); }}

En el ejemplo anterior, he creado una clase llamada RequireHttpsAttribute que deriva de la clase AuthorizationFilterAttribute y estoy sobrescribiendo el método virtual OnAuthorization.

Para las solicitudes GET, el método anterior informa a los clientes de la URL correcta utilizando el esquema HTTPS devolviendo esto en el encabezado de ubicación. Para todas las demás solicitudes, simplemente se devuelve el mensaje “SSL es necesario”.

Aunque esto tiene sentido cuando se llama a una API desde un navegador, uno de los problemas con el código anterior es que devuelve un código de estado de redirección que la mayoría de los clientes de API no entenderán.

Dependiendo de su punto de vista, el código anterior podría modificarse para establecer el código de estado HTTP en otra cosa, como una solicitud incorrecta, en lugar de intentar redirigir al cliente.

Podemos implementar algo similar en .NET Core creando nuestra propia clase, como ApiRequireHttpsAttribute, que se deriva de la clase incorporada RequireHttpsAttribute. Luego podemos anular el método virtual HandleNonHttpsRequest y establecer el código de respuesta en consecuencia, según el código de ejemplo a continuación.

/// <summary> / / / Se llama si la solicitud no se recibe a través de HTTPS./// </resumen>/// <param name="filterContext">El contexto de filtro</param>protected override void HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Resultado = nuevo StatusCodeResult (400);}

El código anterior establece el código de estado HTTP para la respuesta a una solicitud incorrecta (400). Podría modificarse para incluir un mensaje en la respuesta o cualquier otra lógica personalizada que se requiera.

¿No escuchas?

Está bien, así que hemos visto cómo forzar a los clientes API a usar HTTPS cada vez que intenten usar HTTP.

Sin embargo, ¿es esta la mejor opción?

La mejor práctica dicta que debemos tener múltiples capas de seguridad, pero también dicta que debemos implementar la seguridad lo antes posible.

En realidad, lo más seguro que podemos hacer en el contexto de las API es evitar que escuchen en un puerto no seguro en primer lugar. Este consejo se refleja en los documentos de Microsoft para ASP.NET Núcleo.

Por supuesto, no podemos evitar que un cliente de API intente llegar a nuestra API de manera insegura. Sin embargo, en este caso, es culpa del integrador de API y no es algo para lo que podamos hacer algo significativo para evitarlo.

Resumen

En este artículo, he cubierto cómo aplicar HTTPS en sus aplicaciones web y API y he analizado las soluciones más adecuadas y seguras para ambos escenarios.

La clave es que debe implementar varias capas de seguridad para su aplicación y, cuando sea posible, aplicar la seguridad lo antes posible.

Haga uso de HSTS y aproveche la potencia de su configuración de proxy inverso para manejar las solicitudes de manera segura.