El middleware ASP.NET Core que no se agrega a la canalización de middleware en el orden correcto no funcionará según lo previsto, dejando la aplicación expuesta a una variedad de problemas de seguridad.

Ejemplo 1: El método UseHttpsRedirection() agrega middleware de redirección HTTPS a la canalización de middleware, lo que permite la redirección de solicitudes HTTP no seguras a una solicitud HTTPS segura. Cuando se especifica en el orden incorrecto, como se muestra, no se producirá una redirección HTTPS significativa antes de procesar la solicitud a través del middleware que se muestra antes de la redirección. Esto permitirá que la aplicación procese las solicitudes HTTP antes de redirigirlas a la conexión HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

El middleware ASP.NET Core que no se agrega a la canalización de middleware en el orden correcto no funcionará según lo previsto, dejando la aplicación expuesta a una variedad de problemas de seguridad.

Ejemplo 1: El método UseHttpLogging() agrega middleware de registro HTTP a la canalización de middleware que permite que los componentes de middleware se registren. Cuando se especifica en el orden incorrecto, como se muestra, no se agrega ningún middleware a la canalización antes de que se registre la llamada a UseHttpLogging().

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Ejemplo 2: El método UseWC3Logging() agrega el middleware de registro W3C a la canalización de middleware que permite que los componentes de middleware se registren. Cuando se especifica en el orden incorrecto, como se muestra, no se agrega ningún middleware a la canalización antes de que se registre la llamada a UseWC3Logging().

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

Configurar el modo de validación del certificado en None desactiva todo el proceso de validación de la certificación, lo que expone la aplicación a ataques de tipo "man-in-the-middle". Este modo no debe utilizarse en entornos de producción.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Las aplicaciones ASP .NET se pueden configurar para producir binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debug de la etiqueta <compilation> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

La validación de eventos es una característica de seguridad de ASP.NET que valida los controles de eventos en las solicitudes postback para garantizar que los controles sean los mismos que cuando se representaron durante la carga inicial de la página. Cuando esta característica está deshabilitada, los atacantes pueden llevar a cabo ataques de falsificación de solicitud entre sitios con controles de eventos manipulados, lo que lleva a accesos no autorizados, ataques de Cross-Site Scripting, etc.

Ejemplo 1: La siguiente configuración de la aplicación web deshabilita la validación de eventos.

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

Ejemplo 2: La siguiente directiva de página de servidor deshabilita la validación de eventos.

<%@ Page ... EnableEventValidation="false" %>

Cuanto más tiempo permanece abierta una sesión, mayor es la ventana de oportunidad que tiene un atacante para comprometer las cuentas de usuario. Mientras una sesión permanece activa, un atacante puede forzar la contraseña de un usuario, descifrar su clave de cifrado inalámbrica o controlar una sesión desde un explorador abierto. Los tiempos de espera de autenticación más prolongados también pueden evitar que se libere la memoria y acabar en una denegación de servicio si se crea una cantidad suficientemente grande de sesiones.

Ejemplo 1: El siguiente ejemplo muestra ASP.NET MVC configurado con un tiempo de espera de autenticación de una hora.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

Si no se especifica el atributo de tiempo de espera, el tiempo de espera de autenticación predeterminado es de 30 minutos.

De forma predeterminada, .NET Framework impide el envío de nuevos caracteres a API que definen valores de encabezado HTTP. No obstante, este comportamiento se puede deshabilitar mediante programación configurando la propiedad EnableHeaderChecking en el objeto HttpRuntimeSection como false.

Ejemplo 1: El código siguiente deshabilita la comprobación de encabezados.

Configuration config = WebConfigurationManager.OpenWebConfiguration("/MyApp");
HttpRuntimeSection hrs = (HttpRuntimeSection) config.GetSection("system.web/httpRuntime");
hrs.EnableHeaderChecking = false;

Cuando se deshabilita esta comprobación, el código que permite las entradas de usuario para llegar a las API de configuración de encabezados es vulnerable a ataques como la división de respuesta de HTTP.

Los programas se pueden configurar para validar certificados X.509 de una de estas tres formas. De forma predeterminada, los certificados se validan mediante su cadena de confianza con una entidad de certificación raíz de confianza. Esta configuración se conoce como ChainTrust y proporciona el máximo nivel de seguridad de que el certificado es válido. De forma predeterminada, todos los certificados se validan mediante ChainTrust.

Para hacer uso de un certificado que una entidad de certificación raíz de confianza no haya emitido, se puede configurar un programa para que confíe en certificados emitidos por sus pares estableciendo PeerTrust o PeerOrChainTrust. Estas configuraciones no deben usarse en entornos de producción porque reducen significativamente el nivel de seguridad otorgado por los certificados.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Si el atributo cacheRolesInCookie del elemento configuration/system.web/authentication/forms enweb.config se establece entrue , las funciones de cada usuario se almacenan en caché en una cookie. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Los servicios web ASP.NET facilitan el desarrollo de clientes de servicios web al generar automáticamente documentación que describe cómo comunicarse con el servicio web.

Los servicios web que tienen habilitado el protocolo de documentación generan una página con formato HTML al recibir una solicitud del navegador.

Esta página con formato HTML describe la información siguiente:
1. Las operaciones admitidas
2. Los parámetros que cada operación acepta
3. El tipo de datos que se deben pasar en esos parámetros.

El protocolo de documentación también genera un archivo de lenguaje de descripción de servicios web (WSDL) con formato XML. Este archivo está diseñado para permitir que las aplicaciones comprendan cómo estructurar las solicitudes al servicio web. Esta información puede resultar muy útil para los desarrolladores, especialmente para los desarrolladores que crean clientes para servicios web públicos. Sin embargo, revelar información detallada sobre la funcionalidad de los servicios web privados aumenta el riesgo de que un atacante malintencionado utilice el servicio web indebidamente. El protocolo de documentación siempre describe todas las funciones y parámetros de un servicio web, incluso si solo un subconjunto de esas funciones está destinado a ser de acceso público.

Esta aplicación ASP.NET Core no configura controladores o métodos de controlador de naturaleza confidencial para que solo sean accesibles a través de una conexión segura.

ASP.NET W3Clogger.loggingFields se puede configurar para permitir el registro de datos confidenciales, como datos privados e información del sistema.
Estos datos pueden contener información confidencial relacionada con solicitudes HTTP y respuestas HTTP, como IP de clientes/servidores, puertos de servidor, cookies de encabezado y nombres de usuario autenticados que accedieron al servidor.

En caso de filtración de datos, el adversario puede usar esta información para:

- Robar información confidencial o hacerse pasar por un usuario con mayores privilegios.
- Descubrir servidores internos y obtener acceso no autorizado a recursos restringidos.
- Diseñar ataques enfocados a explotar vulnerabilidades conocidas reportadas contra el servidor detectado


Ejemplo 1: El siguiente código muestra un método de acción en un controlador donde se ha deshabilitado la validación:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 muestra cómo se puede configurar W3Clogging, usando All, para registrar todos los campos posibles en la solicitud Http, incluyendo información confidencial como ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName y Cookie.

Las aplicaciones ASP .NET deben configurarse para usar páginas de error personalizadas en lugar de la página predeterminada del marco de trabajo. La página de error predeterminada brinda información detallada sobre el error que se produjo y no debe utilizarse en entornos de producción. El atributo mode de la etiqueta <customErrors> define si se utilizan páginas de error personalizadas o predeterminadas.

Los atacantes pueden valerse de información adicional que obtengan de una página de error predeterminada para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

De forma predeterminada, ASP.NET valida internamente las firmas criptográficas antes de descifrar las cargas útiles, como las direcciones URL ViewState ,FormsAuth cookies y ScriptResource.axd y pasa esos valores a la aplicación para procesarlos posteriormente. Sin embargo, esta funcionalidad se puede modificar utilizando el parámetro aspnet:UseLegacyEncryption para deshabilitar la comprobación de la firma criptográfica antes de descifrar las cargas útiles. Esta alteración puede permitir que un cliente malintencionado descifre, falsifique o altere de otro modo los datos cifrados.

Ejemplo 1: en el siguiente ejemplo, aspnet:UseLegacyEncryption está definido como true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

Las aplicaciones ASP.NET pueden almacenar parejas de nombre de usuario y contraseña en elementos <credentials> en el archivo web.config para una aplicación ASP.NET, que admite texto sin formato, formatos de contraseña MD5 y SHA1.

Las contraseñas almacenadas en texto sin formato o que utilizan un algoritmo de cifrado débil son accesibles para cualquier persona con acceso a los archivos de configuración de la aplicación. Esto puede incluir la máquina donde se alojan la aplicación o el repositorio de código fuente donde reside la aplicación.

Ejemplo 1: La siguiente entrada de web.config almacena incorrectamente sus contraseñas en texto sin formato.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET admite contraseñas de credenciales almacenadas en tres formatos, especificados por el atributo passwordFormat del elemento configuration/system.web/authentication/forms/credentials. Los posibles valores de este atributo son:

Clear- indica que la contraseña se almacena en texto sin formato (menos segura)
MD5- indica que el hash MD5 de la contraseña está almacenado
SHA1- indica que el hash SHA1 de la contraseña está almacenado (más seguro)

Si bien un hash MD5 es más seguro que el texto sin formato, los investigadores han encontrado ataques de fuerza bruta contra el algoritmo de hash MD5. En este momento, un hash SHA1 todavía proporciona una protección razonable contra tales ataques.

El método FormsAuthentication.RedirectFromLoginPage() emite un vale de autenticación, lo que permite a los usuarios permanecer autenticados durante un periodo especificado. Si se llama al método con el segundo argumento false, este emite un vale de autenticación temporal que será válido durante el periodo de tiempo configurado en web.config. Al llamar al segundo argumento true, el método emite un vale de autenticación persistente. En .NET 2.0, la duración del vale persistente se ajusta al valor especificado en web.config, pero en .NET 1.1, el vale de autenticación persistente presenta una duración predeterminada ridículamente larga: cincuenta años.

Permitir que los vales de autenticación persistentes estén vigentes durante un largo periodo de tiempo provoca que los usuarios y el sistema sean vulnerables, como se indica a continuación:

Amplía el periodo de exposición a ataques de secuestro de sesión en relación con los usuarios que no cierran la sesión.

Aumenta la cantidad media de identificadores de sesión válidos disponibles que puede averiguar un usuario malintencionado.

Alarga la duración del ataque cuando un usuario malintencionado logra secuestra una sesión del usuario.

Las entradas no comprobadas son la causa principal de vulnerabilidades en aplicaciones ASP.NET. Las entradas no comprobadas pueden provocar gran cantidad de vulnerabilidades, como Cross-Site Scripting, Process Control y SQL Injection.

Para evitar tales ataques, utilice el marco de validación de ASP.NET para comprobar todas las entradas del programa antes de que la aplicación las procese.

Entre los ejemplos de uso del marco de trabajo de validación se incluye la comprobación para asegurarse de que:

- Los campos de números de teléfono contienen solo caracteres válidos de números de teléfono.
- Los valores booleanos son solo "T" o "F".
- Las cadenas de formato libre son de una longitud y composición razonables.

Si el atributo cacheRolesInCookie del elemento configuration/system.web/authentication/forms enweb.config se establece entrue , las funciones de cada usuario se almacenan en caché en una cookie. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.