Los identificadores específicos del hardware y del dispositivo se conservarán incluso tras las operaciones de borrado de datos y restablecimiento de fábrica. No se deberían utilizar estos para generar identificadores exclusivos que permitan autorizar o autenticar usuarios.

Además, la pérdida de identificadores universalmente exclusivos, que se puede asociar a la información personal, constituyen un riesgo para la privacidad y la seguridad del usuario.

Algunas estructuras, como por ejemplo AngularJS, limitan los protocolos que pueden establecerse para los enlaces a otros sitios e imágenes. La razón principal es evitar que se ejecute JavaScript en línea, lo que puede dar lugar a vulnerabilidades de scripts entre sitios adicionales dentro de la aplicación.

Ejemplo 1: lo siguiente modifica la lista predeterminada de protocolos permitidos en AngularJS para permitir también que los elementos HTML de imagen acepten JavaScript en línea.

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

El escape contextual estricto (SCE) es un mecanismo de las aplicaciones AngularJS que ayuda a proteger la aplicación de los atacantes. Esto puede prevenir muchos vectores de ataque a través de diferentes tipos de vulnerabilidades. La protección más destacada es contra ciertos tipos de ataques de secuencias de comandos en sitios cruzados. En esta aplicación, este mecanismo de protección está específicamente desactivado.

Ejemplo 1: en este ejemplo deshabilitamos SCE en un módulo.

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

El código establece DangerousEnableCompression en true, lo que habilita la extensión WebSocket "permessage-deflate". Cuando habilita esta compresión a través de una conexión cifrada, expone la aplicación a ataques CRIME y BREACH.

Ejemplo 1: La siguiente configuración establece DangerousEnableCompression en true.

    app.Run(async context => {
      using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
      await websocket.SendAsync(...);
      await websocket.ReceiveAsync(...);
      await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

Las aplicaciones Microsoft ASP.NET pueden suplantar el contexto de seguridad del usuario actual o el proceso que las llama para ejecutar operaciones con privilegios. Aunque los contextos de suplantación presentan diversos fines útiles como, por ejemplo, la reducción del número general de intentos de autenticación que debe realizarse, un programa que mantenga privilegios elevados plantea de forma innecesaria un riesgo para la seguridad general del sistema. Si un usuario malintencionado explota otra vulnerabilidad en el programa mientras se ejecuta en otro contexto de seguridad, todas las operaciones no autorizadas que realice este usuario se ejecutarán con los privilegios correspondientes.

Ejemplo 1: el siguiente ejemplo de código representa un patrón de uso típico de suplantación de credenciales mediante el método WindowsIdentity.Impersonate().

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

El código del Example 1 suplanta el contexto de seguridad del usuario actual y lo utiliza para realizar una operación con privilegios. Después de llamar a DoSecuritySensitiveTasks(), el código intenta restablecer el contexto de seguridad original, pero, si DoSecuritySensitiveTasks() genera una excepción, no se llamará nunca al método Undo(), por lo que el programa seguirá usando el contexto de seguridad suplantado.

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

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.