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.

La mayoría de las aplicaciones web utilizan un identificador de sesión para identificar de forma exclusiva a los usuarios, que normalmente se almacena en una cookie y se transmite de forma transparente entre el servidor y el explorador web.


Cuando el valor del atributo se establece en true o UseUri, la aplicación no utiliza cookies independientemente de si el explorador o el dispositivo las admite. Cuando el valor del atributo se establece en AutoDetect o UseDeviceProfile, las cookies no se utilizan, según la configuración del explorador o el dispositivo solicitante.

Las aplicaciones que no almacenan identificadores de sesión en cookies a veces los transmiten como un parámetro de solicitud HTTP o como parte de la dirección URL. La aceptación de identificadores de sesión especificados en las direcciones URL facilita que los atacantes realicen ataques de fijación de sesión.

La colocación de identificadores de sesión en las direcciones URL también puede aumentar las posibilidades de que se produzcan ataques de suplantación de sesión con éxito contra la aplicación. La suplantación de sesión ocurre cuando un atacante toma el control de la sesión activa o del identificador de sesión de una víctima. Es una práctica común que los servidores web, los servidores de aplicaciones y los servidores proxy web almacenen las direcciones URL solicitadas. Si se incluyen identificadores de sesión en las direcciones URL, también se registran. Aumentar el número de lugares en los que se ven y almacenan los identificadores de sesión aumenta las posibilidades de que un atacante los ponga en peligro.

Las aplicaciones ASP.NET se pueden configurar para proporcionar resultados de información de depuración de seguimiento. Los resultados de seguimiento contienen información detallada acerca de la solicitud que ha realizado en la página actual, información sobre el encabezado, los métodos y los controles utilizados en la página, y el estado de la sesión activa. 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 utilice la aplicación.

La información de seguimiento se habilita a nivel de página estableciendo el atributo Trace de la directiva <page> en true o a nivel de la aplicación agregando un elemento trace en el archivo web.config y estableciendo su atributo enabled en true.

Existe un procesamiento de encabezado HTTP inseguro al configurar la propiedad useUnsafeHeaderParsing en true. Esta configuración permite ataques contra aplicaciones vulnerables debido a reglas de validación insuficientes en los encabezados HTTP.

La siguiente validación NO se realiza cuando este atributo está establecido en true:

- Utilice CRLF para el código de final de línea. No se permite un CR o LF separado.
- No hay espacios en los nombres de los encabezados.
- Todas las líneas de estado, excepto la primera, se interpretan como un par de nombre/valor de encabezado defectuoso.
- La línea de estado debe incluir un código y una descripción.

Esta configuración también implica que ya no se generarán ciertas excepciones relacionadas con caracteres prohibidos.

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

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

El uso de credenciales suplantadas permite que una aplicación ASP.NET se ejecute con los privilegios del cliente en cuyo nombre se ejecuta o con privilegios arbitrarios otorgados en su configuración.

En ASP.NET, el estado de visualización es un mecanismo que mantiene invariable el estado de los formularios web de una devolución a otra. Los datos almacenados en estado de visualización no son dignos de confianza porque no hay ningún mecanismo que prevenga los ataques de reproducción. Confiar en el estado de visualización resulta especialmente peligroso cuando se desactiva la comprobación de autenticación del estado de visualización de los mensajes. Desactivar esta comprobación permite a los atacantes realizar cambios arbitrarios en los datos almacenados en el estado de visualización y deja la puerta abierta a que los códigos que confían en el estado de visualización puedan sufrir ataques. Los atacantes pueden utilizar esta clase de error para hacer fracasar las comprobaciones de autenticación o para alterar los precios de los artículos.
Ejemplo 1: El código siguiente deshabilita las comprobaciones de autenticación de los mensajes de estado de visualización.

Page.EnableViewStateMac = false;

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.

Las acciones del controlador de ASP.NET MVC que modifican datos escribiendo, actualizando o eliminando podrían beneficiarse de estar limitado a aceptar uno de los siguientes verbos HTTP: Post, Put, Patch o Delete. Esto aumenta la dificultad de forgery de solicitudes entre sitios, ya que el clic accidental de vínculos no hará que la acción se ejecute.

La siguiente acción del controlador acepta de manera predeterminada cualquier verbo y puede ser susceptible de falsificación de solicitud entre sitios:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}