Las aplicaciones para Android se pueden configurar para producir archivos binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debuggable de la etiqueta <application> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. 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 la aplicación utilice.

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);
    });
    

De forma predeterminada, los servidores de ASP.NET almacenan el objeto HttpSessionState, sus atributos y cualquier objeto al que hagan referencia en la memoria. Este modelo limita el estado de sesiones activas que puede alojar la memoria del sistema de un solo equipo. Para ampliar la capacidad más allá de estas limitaciones, los servidores se configuran con frecuencia para almacenar la información de estado de sesión, lo que permite ampliar la capacidad y efectuar la replicación entre varios equipos a fin de mejorar el rendimiento general. Para almacenar su estado de sesión, el servidor debe serializar el objeto HttpSessionState, para lo que es necesario que todos los objetos almacenados sean serializables.

Para poder serializar la sesión correctamente, todos los objetos que almacena la aplicación como atributos de sesión deben declarar el atributo [Serializable]. Además, si el objeto requiere métodos de serialización personalizados, también debe implementar la interfaz ISerializable.

Ejemplo 1: la siguiente clase se añade a sí misma a la sesión, pero como no es serializable, la sesión no se puede serializar correctamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

La minimización mejora los tiempos de carga de páginas para las aplicaciones que incluyen archivos JavaScript al reducir su tamaño. La minimización hace referencia al proceso de eliminación de espacios en blanco, comentarios, signos de punto y coma, y llaves acortando el nombre de las variables locales y eliminando código inaccesible.

Ejemplo 1: en el siguiente código ASPX se incluye la versión no minimizada de la biblioteca jQuery de Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

Las entradas sin validar son una de las principales causas de vulnerabilidades en los servicios de API web ASP.NET. Las entradas no comprobadas pueden llevar a muchas vulnerabilidades, incluidas Cross-Site Scripting, Process Control, Access Control y SQL Injection, entre otras. Aunque los servicios de API web ASP.NET normalmente no son susceptibles de ataques de corrupción de memoria, si un servicio de API web ASP.NET llama en código nativo que no realiza comprobaciones de enlaces de matriz, un atacante puede utilizar una debilidad de validación de entrada del servicio de API web ASP.NET para iniciar un ataque de buffer overflow.

Para evitar ataques de este tipo:
1. Utilice atributos de validación para anotar comprobaciones de validación mediante programación en parámetros o miembros de parámetros de objeto de enlace de modelos para acciones del servicio de API web ASP.NET.
2. Utilice ModelState.IsValid para comprobar si la validación del modelo es correcta.