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:
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.
|
|
|