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.

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.

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 claves administradas por el cliente no se utilizan para cifrar datos en reposo.

De forma predeterminada, AWS utiliza claves administradas por AWS para cifrar datos en reposo si el cifrado está habilitado. Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Tenga en cuenta que las claves con el formato aws/service-name están reservadas para las claves administradas por AWS.

Las configuraciones de acceso dinámico pueden exponer los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público suelen estar sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto, como Heartbleed. Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.