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
}

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 uso de una clase de modelo que tiene propiedades requeridas (marcadas con el atributo [Required]) y propiedades opcionales (no marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene más datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

El hecho de tener requisitos mixtos sin comunicar explícitamente qué parámetros se van a enlazar con modelos puede indicar que hay propiedades de modelos para el uso interno, pero pueden estar controlados por un usuario malintencionado.

El siguiente código define una posible clase de modelos que tiene propiedades con [Required] y propiedades sin [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Si algún parámetro opcional puede cambiar el comportamiento de una aplicación, un usuario malintencionado podría cambiar ese comportamiento comunicando un parámetro opcional en una solicitud.

El uso de una clase de modelos con propiedades requeridas que no admiten valores NULL (marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene menos datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

Si un modelo tiene un parámetro requerido que no admite valores NULL y un usuario malintencionado no comunica ese parámetro requerido en una solicitud, es decir, el usuario malintencionado usa un ataque con cantidad reducida de operaciones POST, la propiedad tendrá el valor predeterminado (normalmente cero), que cumplirá con el atributo de validación [Required]. Esto podría producir un comportamiento inesperado de la aplicación.

El código siguiente define una posible clase de modelos que tiene una enumeración requerida que no admite valores NULL:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Si un clase de modelos tiene una propiedad requerida y el tipo de un miembro opcional de una clase de modelos principal, puede ser susceptible a ataques con cantidad reducida de operaciones POST si un usuario malintencionado comunica una solicitud que contiene menos de los que se esperan.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo, incluidos los submodelos.

Si un submodelo es opcional, es decir, el modelo principal tiene una propiedad sin el atributo [Required], y si un usuario malintencionado no comunica ese submodelo, la propiedad principal tendrá un valor null y los campos requeridos del modelo secundario no estarán confirmados por la validación del modelo. Esta es una forma de ataque con cantidad reducida de operaciones POST.

Tenga en cuenta las siguientes definiciones de clases de modelos:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Si un usuario malintencionado no comunica un valor para la propiedad ParentModel.Child, la propiedad ChildModel.RequiredProperty tendrá un [Required] no confirmado. Esto puede producir resultados no esperados y no deseados.

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.

Antes de crear una credencial de confianza del servidor, es responsabilidad del delegado de un objeto NSURLConnection, un objeto NSURLSession o un objeto NSURLDownload evaluar la cadena de confianza.

Ejemplo 1: El siguiente código inicializa un NSURLCredential mediante una credencial de confianza del servidor no evaluada:

-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * credential)) completionHandler {
        ...
        [challenge.sender useCredential:[NSURLCredential credentialForTrust: challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
        ...
}

Antes de crear una credencial de confianza del servidor, es responsabilidad del delegado de un objeto NSURLConnection, objeto NSURLSession o un objeto NSURLDownload evaluar la confianza del servidor. Para poder evaluar la confianza del servidor, debe llamarse al método SecTrustEvaluate(_:_:) con la confianza obtenida del método serverTrust del objeto del servidor NSURLProtectionSpace.

El método SecTrustEvaluate(_:_:) devuelve dos valores diferentes:

- El valor OSStatus devuelto representa el código de resultado.
- El objeto indicado por el segundo argumento representa el tipo de resultado de la evaluación.

Si la confianza no es válida, el desafío de autenticación debe cancelarse con cancel(_:).

Ejemplo 1: En el ejemplo siguiente, la confianza del servidor se evalúa, pero las credenciales recibidas se utilizan sin comprobar el resultado de la evaluación:

SecTrustRef trust = [[challenge protectionSpace] serverTrust];
SecTrustResultType result = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, &result);
completionHandler(NSURLSessionAuthChallengeUseCredential, [challenge proposedCredential]);

Un objeto NSURLProtectionSpace representa un servidor o un área de un servidor, denominado comúnmente dominio, que requiere autenticación.
Al establecer una conexión URL que requiera autenticación en un espacio de protección, el método NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) se llamará justo antes de llamar al método NSURLConnectionDelegate.connection(_:didReceive:) que debe realizar la autenticación. Esto permite que NSURLConnectionDelegate inspeccione el espacio de información antes de intentar la autenticación. Al devolver true, el delegado indica que puede manejar el formulario de autenticación, lo que hace en la llamada subsiguiente a connection(_:didReceive:). Si su delegado no implementa este método y el espacio de protección utiliza la autenticación del certificado de cliente o la autenticación de confianza del servidor, el sistema intentará utilizar las llaves del usuario para realizar la autenticación, lo cual puede no ser el comportamiento deseado.

La aplicación implementa las llamadas de retorno NSURLConnection o NSURLSession para tratar solicitudes de autenticación. Si olvida comprobar que la solicitud de autenticación proviene del host esperado, las credenciales se enviarán a todas las URL que cargue la aplicación. Además, si no verifica que las credenciales se pueden enviar de forma segura, las credenciales serán susceptibles de ser robadas.

Ejemplo 1: La aplicación siguiente envía credenciales de usuario a cualquier host que solicite autenticación:

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NS URLAuthenticationChallenge *)challenge completionHandler:(void (^)(NS URLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { 
    NSString *user = [self getUser]; 
    NSString *pass = [self getPassword]; 

    NSURLCredential *cred = [NSURLCredential credentialWithUser:user 
    password:pass persistence:NSURLCredentialPersistenceForSession]; 
    completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
} 

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.

Las configuraciones de acceso dinámico exponen innecesariamente 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 (por ejemplo, Heartbleed). Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

Ejemplo 1: La siguiente tarea de Ansible define un grupo de seguridad de AWS que abre al mundo (0.0.0.0/0 ) el puerto TCP22, donde un servidor SSH suele responder a las solicitudes de conexión entrantes.

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0