La validación de eventos es una característica de seguridad de ASP.NET que valida los controles de eventos en las solicitudes postback para garantizar que los controles sean los mismos que cuando se representaron durante la carga inicial de la página. Cuando esta característica está deshabilitada, los atacantes pueden llevar a cabo ataques de falsificación de solicitud entre sitios con controles de eventos manipulados, lo que lleva a accesos no autorizados, ataques de Cross-Site Scripting, etc.

Ejemplo 1: La siguiente configuración de la aplicación web deshabilita la validación de eventos.

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

Ejemplo 2: La siguiente directiva de página de servidor deshabilita la validación de eventos.

<%@ Page ... EnableEventValidation="false" %>

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.

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.

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.

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>
...

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;

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.

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 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

Una configuración comodín para los principales lambda infringe el principio de privilegios mínimos y permite que un atacante invoque el lambda desde cualquier cuenta.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define un principal lambda comodín.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

De forma predeterminada, los clústeres de Amazon Redshift no son de acceso público.

Permitir el acceso público a un clúster amplía la superficie de ataque de la organización.

Ejemplo 1: El siguiente ejemplo muestra una tarea de Ansible que habilita explícitamente el acceso público a un clúster de Amazon Redshift configurando el parámetro publicly_accessible en yes .

- name: example1
  community.aws.redshift:
    identifier: mycluster
    command: create
    db_name: mydb
    node_type: ds1.xlarge
    username: "{{ username }}"
    password: "{{ password }}"
    publicly_accessible: yes

Una mala configuración del acceso público a un contenedor S3 es una de las principales causas de vulneraciones de datos.

Aunque los contenedores S3 bloquean el acceso público de forma predeterminada, cualquier usuario autorizado puede actualizar las directivas de contenedor o las listas de control de acceso (ACL) para permitir el acceso público.

Una AMI de Amazon EC2 que asigna un dispositivo de bloqueo sin cifrar expone los datos a accesos no autorizado y a posibles robos.

Ejemplo 1: La siguiente tarea de Ansible crea una AMI de Amazon EC2 y adjunta un dispositivo de bloqueo sin cifrado de datos en reposo a la AMI porque el parámetro encrypted está establecido en false.

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

De forma predeterminada, un sistema de archivos EFS no está cifrado. Esto expone los datos al acceso no autorizado y posible robo.

Ejemplo 1: La siguiente tarea de Ansible configura un sistema de archivos EFS sin cifrado de datos en reposo porque el parámetro encrypt está establecido en no.

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]