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.

La entrada sin marcar es la principal causa de vulnerabilidades en las aplicaciones ASP.NET. La entrada no verificada puede generar numerosas vulnerabilidades, incluidas Cross-Site Scripting, control de procesos e SQL injection.

Para prevenir estos ataques, use el marco de validación ASP.NET para verificar toda la entrada del programa antes de que la aplicación la procese.

Los ejemplos de usos del marco de validación incluyen la verificación para garantizar que:

- Los campos de números de teléfono contengan solo caracteres válidos en los números de teléfono

- Los valores booleanos sean solo "T" o "F"

- Las cadenas sin formato tengan una longitud y una 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.