Transmissões persistentes não podem ser protegidas com uma permissão e, portanto, são acessíveis a qualquer receptor. Se essas transmissões contiverem dados confidenciais ou acessarem um receptor mal-intencionado, o aplicativo poderá ficar comprometido.

Exemplo 1: O código a seguir envia uma transmissão persistente.

...
context.sendStickyBroadcast(intent);
...

Definir novas permissões no namespace android.permission pode ter consequências inesperadas quando o sistema operacional é atualizado. Se a versão mais recente do sistema operacional definir exatamente a mesma permissão, o Android Package Management Service (PMS) concederá silenciosamente a permissão ao aplicativo, sem pedir ao usuário que permita ataques de escalonamento de privilégios.

Como este componente espera receber apenas mensagens de transmissão do sistema e não de outros componentes, ele deve ser privado (inacessível para outros componentes)

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

Não é recomendável que os desenvolvedores criem seus aplicativos usando APIs não documentadas ou ocultas. Não há garantias de que o Google não irá remover ou alterar essas APIs no futuro e, portanto, elas devem ser evitadas. Dessa forma, usar esses métodos ou campos tem um alto risco de violar seu aplicativo.

O código tenta usar o objeto Camera depois que ele já foi liberado. Qualquer referência adicional ao objeto Camera sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de alternância para ativar e desativar a visualização da câmera. Depois que o usuário tocar no botão uma vez, a visualização da câmera será interrompida, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, startPreview() será chamado no objeto Camera anteriormente liberado.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

O código tenta usar o objeto de mídia depois que ele já foi liberado. Qualquer referência adicional a esse objeto de mídia sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de pausa para alternar a reprodução da mídia. Depois que o usuário tocar no botão uma vez, a música ou o vídeo atual será pausado, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, start() será chamado no recurso de mídia anteriormente liberado.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

O código tenta usar o manipulador de banco de dados SQLite do Android depois que ele já foi fechado. Qualquer referência adicional ao manipulador sem o restabelecimento da conexão com o banco de dados lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir pode ser de um programa que armazena em cache valores de usuário temporariamente na memória, mas que pode chamar flushUpdates() para confirmar as alterações no disco. O método fecha corretamente o manipulador de banco de dados depois de gravar atualizações no banco de dados. No entanto, quando flushUpdates() é chamado novamente, o objeto de banco de dados é referenciado novamente antes da reinicialização.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Identificadores específicos de hardware e dispositivos são mantidos persistentes entre limpezas de dados e redefinições de fábrica. Não se deve confiar nesses identificadores para gerar identificadores exclusivos usados para autorizar ou autenticar usuários.

Além disso, o vazamento de identificadores universalmente exclusivos, que podem ser associados a informações pessoais, representa uma ameaça à segurança e à privacidade do usuário.

Vulnerabilidades de Sequestro de Carregamento de Classe Android assumem duas formas:

- Um invasor pode alterar o nome dos diretórios pesquisados pelo programa para carregar classes, apontando o caminho para um diretório sobre o qual ele tem controle: o invasor controla explicitamente os caminhos que devem ser pesquisados em busca de classes.

- Um invasor pode alterar o ambiente no qual a classe é carregada: o invasor controla implicitamente o que o nome do caminho significa.

Nesse caso, estamos preocupados principalmente com o primeiro cenário, com a possibilidade de que um invasor seja capaz de controlar os diretórios pesquisados por classes a serem carregadas. Vulnerabilidades de Sequestro de Carregamento de Classe Android desse tipo ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são usados como uma string, ou parte de uma string, que representa um diretório de biblioteca para procurar classes a serem carregadas.



3. Ao executar o código no caminho da biblioteca, o aplicativo concede ao invasor um privilégio ou uma capacidade que ele não teria de outra forma.

Exemplo 1: O código a seguir usa o userClassPath alterável pelo usuário para determinar o diretório no qual procurar classes a serem carregadas.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Esse código permite que um invasor carregue uma biblioteca e execute possivelmente um código arbitrário com o privilégio elevado do aplicativo, sendo capaz de modificar o resultado de userClassPath de forma que ele aponte para um caminho diferente que o invasor pode controlar. Como o programa não valida o valor lido do ambiente, se um invasor puder controlar o valor de userClassPath, ele poderá enganar o aplicativo de forma com que este aponte para um diretório controlado pelo invasor e, portanto, poderá carregar as classes que ele definiu usando os mesmos privilégios que o aplicativo original.

Exemplo 2: O código a seguir usa a userOutput modificável pelo usuário para determinar o diretório em que os arquivos DEX otimizados devem ser escritos.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Esse código permite que um invasor especifique o diretório de saída para arquivos DEX otimizados (ODEX). Isso então permite que um usuário mal-intencionado altere o valor de userOutput para um diretório que ele pode controlar, como um armazenamento externo. Quando isso for conseguido, será simplesmente uma questão de substituir o arquivo ODEX processado por um arquivo ODEX mal-intencionado para que este seja executado com os mesmos privilégios do aplicativo original.

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.

Vulnerabilidades de travessia de caminho de Zip ocorrem quando um agente malicioso consegue especificar nomes de entrada de arquivo Zip em um determinado arquivo Zip. Quando um nome de entrada de arquivo Zip é especificado maliciosamente, um invasor pode substituir o conteúdo dos principais arquivos do sistema quando o arquivo Zip correspondente é expandido. Os invasores podem usar expressões idiomáticas de travessia de caminho, como ../ e / para acessar arquivos do sistema que de outra forma estariam fora do escopo do programa. Os aplicativos Android que têm como alvo o Android 14 e versões posteriores podem, por padrão, lançar uma exceção quando expressões idiomáticas como ../ e/ são detectadas durante a extração do arquivo Zip. Esse recurso de segurança pode ser substituído ou desabilitado completamente.

Exemplo 1: O código a seguir desabilita a proteção contra Zip Entry Overwrite.

...
dalvik.system.ZipPathValidator.clearCallback();
...

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 aplicativo usa código que ativa a extensão WebSocket permessage-deflate, que permite a compactação em conexões criptografadas. Habilitar esse tipo de compactação torna o aplicativo sujeito a ataques do tipo CRIME e BREACH.

Exemplo 1: O seguinte código define DangerousEnableCompression como true para ativar a extensão “per-message-deflate”:

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

Exemplo 2: O código a seguir usa DangerousDeflateOptions para definir as opções para a extensão “per-message-deflate”:

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

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.

Aplicativos Microsoft ASP.NET podem representar o contexto de segurança do usuário atual ou o processo que os invocou a fim de executar operações privilegiadas. Embora contextos de representação sirvam a várias finalidades úteis, como reduzir o número total de tentativas de autenticação que devem ser feitas, um programa que mantém privilégios elevados desnecessariamente representa um risco para a segurança geral do sistema. Se um invasor explorar outra vulnerabilidade no programa enquanto este estiver sendo executado em outro contexto de segurança, qualquer operação não autorizada que esse invasor realizar será executada com os privilégios correspondentes.

Exemplo 1: O exemplo de código a seguir representa um padrão de uso típico de representação de credenciais usando o 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();

O código no Example 1 personifica o contexto de segurança do usuário atual e o utiliza para realizar uma operação privilegiada. Depois de chamar DoSecuritySensitiveTasks(), o código tenta restaurar o contexto de segurança original. No entanto, se DoSecuritySensitiveTasks() lançar uma exceção, o método Undo() nunca será chamado, e o programa continuará a usar o contexto de segurança representado.

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseCookiePolicy() adiciona o middleware de política de cookie ao pipeline de middleware, permitindo políticas de cookie personalizadas. Quando especificado na ordem errada, como mostrado, qualquer política de cookie indicada pelo programador será ignorada.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...