Os aplicativos Android podem ser configurados para produzir binários de depuração. Esses binários fornecem mensagens de depuração detalhadas e não devem ser usados em ambientes de produção. O atributo debuggable da tag <application> define se os binários compilados devem incluir informações de depuração.

O uso de binários de depuração faz com que um aplicativo forneça ao usuário o máximo de informações possível sobre si mesmo. Os binários de depuração devem ser usados em um ambiente de desenvolvimento ou teste e podem representar um risco de segurança se forem implantados em produção. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Certas estruturas, como o AngularJS, limitam os protocolos que podem ser definidos para links que levam a outros sites e imagens. Isso tem o objetivo principal de impedir a execução do JavaScript embutido, o que pode resultar em vulnerabilidades de execução de scripts entre sites dentro do aplicativo.

Exemplo 1: O código a seguir altera a lista de permissões com o padrão de protocolos no AngularJS, de forma a também permitir elementos HTML de imagem para liberar um JavaScript embutido.

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

O Strict Contextual Escaping (SCE) é um mecanismo em aplicativos AngularJS que ajuda a proteger o aplicativo contra invasores. Isso pode impedir muitos vetores de ataque em diferentes tipos de vulnerabilidades. A proteção mais proeminente é contra certos tipos de ataques de cross-site scripting. Neste aplicativo, este mecanismo de proteção está especificamente desabilitado.

Exemplo 1: Nesse exemplo, desabilitamos o SCE em um módulo.

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

O código define DangerousEnableCompression como true, que habilita a extensão WebSocket 'permessage-deflate'. Ao habilitar essa compactação em uma conexão criptografada, você abre o aplicativo para ataques CRIME e BREACH.

Exemplo 1: O código a seguir define DangerousEnableCompression como 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);
    });
    

Por padrão, servidores ASP.NET armazenam na memória o objeto HttpSessionState, seus atributos e quaisquer objetos aos quais eles fazem referência. Esse modelo limita o estado da sessão ativa que pode ser acomodado pela memória do sistema de uma única máquina. Para ampliar a capacidade além dessas limitações, os servidores são frequentemente configurados para informações de estado de sessão persistentes, o que expande a capacidade e também permite a replicação através de várias máquinas a fim de melhorar o desempenho global. Para persistir o estado de sua sessão, o servidor deve serializar o objeto HttpSessionState, o que requer que todos os objetos nele armazenados sejam serializáveis.

Para que a sessão seja serializada corretamente, todos os objetos que o aplicativo armazena como atributos de sessão devem declarar o atributo [Serializable]. Além disso, se o objeto exigir métodos de serialização personalizados, ele também deverá implementar a interface ISerializable.

Exemplo 1: A classe a seguir se acrescenta à sessão, mas, como não é serializável, a sessão não pode ser serializada corretamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

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

A minificação melhora os tempos de carregamento de páginas para aplicativos que incluem arquivos JavaScript, reduzindo o tamanho do arquivo. O termo Minificação refere-se ao processo de remover espaços em branco, comentários, pontos-e-vírgulas e chaves desnecessários, de encurtar nomes de variáveis locais e de remover códigos inacessíveis.

Exemplo 1: O código ASPX a seguir inclui a versão não minificada da biblioteca jQuery da Microsoft:

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

Entradas não verificadas são a principal causa de vulnerabilidades em serviços de API da Web ASP.NET. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control, access control e SQL injection. Embora serviços de API da Web ASP.NET geralmente não sejam suscetíveis a ataques de memory corruption, se esse tipo de serviço for chamado em um código nativo que não realiza a verificação de limites de array, um invasor talvez seja capaz de usar uma fraqueza de validação de entrada no serviço de API da Web ASP.NET para lançar um ataque de buffer overflow.

Para impedir esses ataques:
1. use os atributos de validação para anotar programaticamente verificações de validação em parâmetros ou membros de parâmetros de objeto de associação de modelos a ações de serviços de API da Web ASP.NET.
2. use ModelState.IsValid para verificar se a validação de modelo é aprovada.