Práticas recomendadas de segurança para desenvolvedores

Adobe AIR 1.0 e posterior

Embora os aplicativos AIR sejam criados usando tecnologias da Web, é importante para os desenvolvedores observar que eles não trabalham na caixa de proteção de segurança do navegador. Isso significa que é possível criar aplicativos AIR que podem danificar o sistema local de maneira intencional ou não intencional. O AIR tenta minimizar esse risco, mais ainda há formas em que as vulnerabilidades podem ser introduzidas. Este tópico cobre faltas de segurança potenciais importantes.

Risco de importar arquivos para a caixa de proteção de segurança do aplicativo

Os arquivos existentes no diretório do aplicativo estão atribuídos à caixa de proteção do aplicativo e têm privilégios completos de tempo de execução. Recomenda-se aos aplicativos que gravam no sistema de arquivos local gravar no app-storage:/ . Esse diretório está separado dos arquivos do aplicativo no computador do usuário, por isso os arquivos não estão atribuídos na caixa de proteção do aplicativo e representam risco reduzido de segurança. Recomenda-se aos desenvolvedores que considerem o seguinte:

  • Somente incluir um arquivo em um arquivo do AIR (no aplicativo instalado) se for necessário.

  • Somente incluir um arquivo em um arquivo do AIR (no aplicativo instalado) se o respectivo comportamento for completamente compreensível e confiável.

  • Não grave nem modifique conteúdo no diretório do aplicativo. O tempo de execução impede que aplicativos gravem ou modifiquem arquivos e diretórios que usam o esquema de URL app:/ , lançando uma exceção SecurityError.

  • Não use dados de uma fonte de rede como parâmetros de métodos da API do AIR que possam conduzir a execução de código. Isso inclui o uso do método Loader.loadBytes() e a função eval() de JavaScript.

Risco de uso de fonte externa para determinar caminhos

O aplicativo do AIR pode estar com o uso de dados ou conteúdo externo comprometido. Por esse motivo, tenha cuidado especial ao usar dados da rede ou do sistema de arquivos. O ônus da confiança, depende em última análise do desenvolvedor e das conexões de rede que eles fazem, mas carregar dados externos é inerentemente arriscado e não deve ser usado em inserções de operações confidenciais. Recomenda-se aos desenvolvedores o seguinte:

  • Usar dados de uma fonte de rede para determinar o nome de arquivo

  • Usar dados de uma fonte de rede para construir uma URL que o aplicativo use para enviar informações particulares

O risco de usar, armazenar ou transmitir credenciais não seguras

Armazenar credenciais do usuário no sistema de arquivos local do usuário introduz inerentemente o risco de que essas credenciais possam estar comprometidas. Recomenda-se aos desenvolvedores que considerem o seguinte:

  • Se credenciais devem ser armazenadas localmente, criptografe as credenciais ao gravá-las no sistema de arquivos local. O tempo de execução oferece um armazenamento criptografado exclusivo para cada aplicativo instalado, através da classe EncryptedLocalStore. Para ver detalhes, consulte Armazenamento local criptografado .

  • Não transmita credenciais de usuário não-criptografadas, exceto se a fonte for confiável e a transmissão utilizar HTTPS: ou protocolos Transport Layer Security (TLS).

  • Nunca especifique uma senha padrão na criação de credencial: deixe que os usuários criem suas próprias senhas. Usuários que mantêm o padrão inalterado expõem as respectivas credenciais ao invasor que já conhece a senha padrão.

Risco de um ataque de downgrade

Durante a instalação do aplicativo, o tempo de execução certifica-se de que não haja uma versão do aplicativo instalada atualmente. Se o aplicativo já estiver instalado, o tempo de execução compara a string da versão em relação à versão que está sendo instalada. Se essa string for diferente, o usuário poderá optar por atualizar a instalação. O tempo de execução não garante que a versão instalada recentemente seja mais recente que a versão anterior, apenas que seja diferente. O invasor pode distribuir uma versão anterior para o usuário, para contornar uma falha de segurança. Por esse motivo, recomenda-se que o desenvolvedor verifique as versões quando o aplicativo for executado. É uma boa ideia fazer com que os aplicativos verifiquem a rede em busca de atualizações necessárias. Dessa maneira, mesmo se um invasor fizer com que o usuário execute uma versão anterior, essa versão anterior irá reconhecer que é necessário atualizar. Além disso, usar um esquema de versão bem-definido no aplicativo torna mais difícil enganar os usuários para que instalem uma versão desatualizada.