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.

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.

Al establecer useUnsafeHeaderParsing en true se relaja el procesamiento de encabezados HTTP. Si las reglas de validación son demasiado permisivas en los encabezados HTTP, pueden permitir diversos ataques contra aplicaciones vulnerables.



En concreto, cuando esta propiedad se establece en false, las siguientes reglas de validación ya no se aplican:

En el código de fin de línea, use CRLF; el uso de CR o LF solo no está permitido.

Los nombres de los encabezados no deben tener espacios.

Si existen varias líneas de estado, todas las líneas de estado adicionales se tratan como pares de nombre-valor de encabezado con formato incorrecto.

La línea de estado debe tener una descripción de estado, además de un código de estado.

Los nombres de encabezado no pueden contener caracteres que no sean ASCII. Esta validación se realiza si esta propiedad se establece en true o en false.

Cuando se produce una infracción de protocolo, se lanza una excepción WebException con el estado establecido en ServerProtocolViolation. Si la propiedad UseUnsafeHeaderParsing se establece en true, se omiten los errores de validación.

Establecer esta propiedad en true tiene implicaciones para la seguridad, por lo que solo debe hacerse si se necesita compatibilidad con versiones anteriores de un servidor.


Ejemplo 1: En el siguiente ejemplo, useUnsafeHeaderParsing está definido como verdadero.

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest  useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

En ASP.NET, el estado de vista es un mecanismo para conservar el estado en formularios web entre devoluciones. Los datos almacenados en el estado de vista no son de confianza porque no existe un mecanismo para prevenir ataques de reproducción. Confiar en el estado de vista es particularmente peligroso cuando la verificación de autenticación del mensaje de estado de vista está deshabilitada. La deshabilitación de esta comprobación permite a los atacantes realizar cambios arbitrarios en los datos almacenados en el estado de vista y puede abrir la puerta a ataques contra el código que confía en el estado de vista. Los atacantes pueden utilizar este tipo de error para anular las verificaciones de autenticación o alterar el precio de los artículos.

ASP.NET MVC es un método fácil para proteger mejor las aplicaciones contra la falsificación de solicitud entre sitios, ya que agrega un token antifalsificación en el lado del formulario y valida dicho token antifalsificación en el controlador. Si se usa, este token suele estar incluido como campo de formulario oculto y se valida cuando se envía el formulario, lo que hace que aumenten las probabilidades de que una solicitud proceda de la aplicación y no sea una falsificación.

El siguiente código de controlador no incluye la defensa incorporad contra la falsificación de solicitud entre sitios:

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC es un método fácil para proteger mejor las aplicaciones contra la falsificación de solicitud entre sitios, ya que agrega un token antifalsificación en el formulario HTML y valida dicho token antifalsificación en el controlador. Si se usa, este token suele estar incluido como campo de formulario oculto y se valida cuando se envía el formulario, lo que hace que aumenten las probabilidades de que una solicitud proceda de la aplicación y no sea una falsificación.

Por lo general, el programador deberá incluir este token antifalsificación porque aumenta el coste de los scripts malintencionados en relación con una aplicación.

Ejemplo 1:El siguiente código de Razor crea un formulario en el HTML resultante sin la defensa integrada contra la falsificación de solicitudes entre sitios:

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

El método de delegado NSURLConnectionDelegate.connection(_:willSendRequestFor:) permite que el delegado tome inmediatamente una decisión informada acerca de la autenticación de la conexión. Si el delegado implementa este método, no será necesario implementar NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) o NSURLConnectionDelegate.connection(_:didReceive:). De hecho, estos métodos no se invocan, por lo que las comprobaciones de seguridad se ignorarán.