Melhores práticas de aplicações seguras para uma melhor cibersegurança
Na era dos vectores elevados e altamente variados de ameaças à cibersegurança, manter uma boa higiene para proteger os utilizadores da sua aplicação é fundamental para a segurança do programador, do consumidor e do utilizador da aplicação.
Embora a estratégia e as técnicas escolhidas para proteger a segurança do utilizador da aplicação dependam da funcionalidade que a aplicação oferece aos utilizadores, os programadores devem ter em mente as seguintes práticas:
Autenticação
Autorização
Armazenamento de dados
Anti-manipulação e anti-reversão
Vamos aprofundar cada uma das quatro áreas.
Autenticação
Validar a identidade do utilizador e garantir o acesso legítimo. Os exemplos incluem biometria, números de identificação pessoal ou geradores de códigos de autenticação multi-fator.
Implemente a autenticação "Algo que você sabe" como um dos fatores de MFA.
Algo que você sabe representa um nível fundamental de verificação de identidade que envolve informações conhecidas apenas pelo utilizador, como um PIN (número de identificação pessoal), uma palavra-passe, um padrão, etc.
A implementação do "Algo que você sabe" como um dos factores MFA garante um nível básico de verificação de identidade, exigindo que os utilizadores forneçam informações únicas associadas às suas contas.
Implementar a autenticação "Algo que você tem" como um dos factores MFA.
O Something-You-Have exige que os utilizadores se autentiquem com um dispositivo físico, uma aplicação ou um token que gere credenciais de autenticação, que podem incluir One-Time Passwords (OTPs) baseadas no tempo. Exemplos de tais tokens incluem tokens de software, tokens de hardware e SMS OTP.
A implementação de algo que se tem como um dos factores de autenticação multifuncional aumenta a complexidade do processo de autenticação ao exigir a posse de um elemento tangível, reduzindo significativamente a probabilidade de acesso não autorizado.
Os programadores devem utilizar um OTP baseado no tempo para tokens de software, tokens de hardware e SMS OTP. Devem ser seguidas as seguintes diretrizes:
Uma OTP só deve ser válida por um período máximo de 30 segundos.
Uma OTP introduzida incorretamente após três tentativas deve ser invalidada e a sessão do utilizador deve ser revogada ou rejeitada.
Implementar a autenticação "Algo que você é" como um dos factores MFA.
O Something-You-Are exige que os utilizadores se autentiquem com identificadores biométricos, como impressões digitais, digitalizações de retina ou reconhecimento facial.
A implementação de "Algo que você é" como um dos factores MFA acrescenta um fator de autenticação altamente personalizado e difícil de replicar. Proporciona um meio mais robusto de verificar a identidade do utilizador do que os factores " Algo que sabe" e " Algo que tem", reduzindo o risco de acesso não autorizado.
Os programadores devem limitar as funcionalidades das aplicações em dispositivos sem hardware Trusted Executed Environment (TEE) ou biometria (por exemplo, os dispositivos Android sem TEE podem ser detectados utilizando a API Android "isInsideSecureHardware") e devem invalidar a autenticação biométrica se ocorrerem alterações no mecanismo biométrico, como o registo de uma nova impressão digital no dispositivo. As plataformas IOS e Android suportam a definição de uma chave criptográfica de aplicação para expirar em resposta a tais alterações.
Utilizar factores baseados no contexto para autenticar.
Os factores baseados no contexto introduzem elementos dinâmicos, como a localização do utilizador e os atributos do dispositivo. Embora a autenticação multifator forneça uma camada robusta de segurança ao exigir múltiplos factores de autenticação, a incorporação de factores baseados no contexto cria um processo de autenticação mais abrangente e adaptável que pode oferecer benefícios adicionais na abordagem dos riscos crescentes de acesso não autorizado.
A implementação de factores baseados no contexto minimiza a dependência de credenciais estáticas, tornando mais difícil a tentativa de acesso não autorizado por parte de agentes maliciosos. Os programadores devem considerar os seguintes factores contextuais para verificar a identidade de um utilizador:
Geolocalização: Permitir o acesso com base na localização real de um dispositivo utilizando a geolocalização por GPS, Wi-Fi ou endereço IP.
Tipo de dispositivo: Permitir o acesso com base nas caraterísticas de um dispositivo. Por exemplo, o tamanho do ecrã pode determinar se um dispositivo é um smartphone ou um tablet.
Implementar autenticação de sessão segura.
A autenticação de sessão segura garante uma gestão de sessão sólida tanto para a autenticação com e sem estado. As sessões mal geridas, independentemente de a aplicação seguir métodos de autenticação com ou sem estado, podem conduzir a ameaças à segurança, como o acesso não autorizado, o sequestro de sessões ou a violação de dados.
A implementação da autenticação de sessão segura para sessões com estado utiliza identificadores de sessão seguros, comunicação encriptada e tempos limite adequados para impedir o acesso não autorizado. Para a autenticação sem estado, garante que os tokens são invioláveis, mantendo a integridade da autenticação sem depender do armazenamento do lado do servidor.
Implementar autenticação segura com estado.
A autenticação segura com estado envolve a proteção e manutenção de sessões persistentes. Embora a autenticação com estado proporcione uma experiência de utilizador perfeita através de sessões de utilizador persistentes, pode ser vulnerável a várias ameaças à segurança, como agentes maliciosos que tentam roubar identificadores de sessão.
A autenticação segura com estado protege as contas de utilizador contra o acesso não autorizado e as potenciais vulnerabilidades associadas à gestão de sessões, sem comprometer o equilíbrio entre a usabilidade e a segurança.
Os programadores devem identificar os pontos finais do lado do servidor que expõem informações sensíveis ou funcionalidades críticas e adotar as seguintes práticas recomendadas de autenticação de sessão com estado:
Rejeitar pedidos com IDs ou tokens de sessão em falta ou inválidos.
Gerar IDs de sessão aleatoriamente no lado do servidor sem anexá-los aos URLs.
Reforçar a segurança do ID de sessão com o comprimento e a entropia adequados, dificultando a adivinhação.
Trocar IDs de sessão apenas através de ligações HTTPS seguras.
Evite armazenar IDs de sessão em armazenamento persistente.
Verificar IDs de sessão para acesso do utilizador a elementos de aplicação privilegiados.
Termina as sessões no lado do servidor, eliminando as informações da sessão após o tempo limite ou o fim da sessão.
Implementar autenticação segura sem estado.
A autenticação segura sem estado envolve práticas de token seguro para uma autenticação eficaz e escalável
autenticação. Embora a autenticação sem estado ofereça vantagens, pode ser mais vulnerável a ameaças à segurança, como a falsificação de identidade do utilizador, se os tokens não forem gerados, transmitidos e armazenados de forma segura.
A autenticação sem estado garante que cada token é tratado de forma segura, ao mesmo tempo que colhe benefícios de eficiência e escalabilidade, reduzindo o risco de acesso não autorizado. Os desenvolvedores devem adotar as seguintes práticas recomendadas de autenticação de sessão sem estado:
Gerar tokens no lado do servidor sem anexá-los aos URLs.
Reforçar a segurança do token com o comprimento e a entropia adequados, dificultando a adivinhação.
Troque tokens apenas através de ligações HTTPS seguras.
Verifique se nenhum dado sensível, como informações pessoais, está incorporado nos tokens.
Evite armazenar tokens em armazenamento persistente.
Verificar os tokens para o acesso do utilizador a elementos privilegiados da aplicação.
Termina os tokens no lado do servidor, eliminando as informações do token após o tempo limite ou o fim da sessão.
Criptograficamente, assinar os tokens utilizando um algoritmo seguro, evitando a utilização de algoritmos nulos.
Implementar o encerramento seguro da sessão durante o logout, inatividade ou encerramento da aplicação.
O encerramento seguro da sessão encerra efetivamente as sessões do utilizador. Os agentes maliciosos podem explorar pontos de acesso persistentes se as sessões não forem geridas adequadamente em cenários como o encerramento da sessão, inatividade ou encerramento da aplicação.
A implementação da terminação segura da sessão durante o encerramento da sessão, a inatividade ou o encerramento da aplicação pode reduzir significativamente o risco de acesso não autorizado, terminando automaticamente as sessões do utilizador e protegendo as informações do utilizador de serem acedidas por partes não autorizadas. Os programadores devem:
Reautenticar os utilizadores após terminarem a sessão, inatividade da aplicação, inatividade, inatividade, colocação em segundo plano, tempos limite absolutos da sessão ou encerramento abrupto/forçado.
O servidor gera novos identificadores de sessão para evitar a fixação da sessão sempre que os utilizadores atingem um novo nível de autenticação.
Assegurar que o encerramento da sessão inclui a limpeza ou a desautorização de todos os tokens ou identificadores de sessão armazenados localmente.
Determine o valor do tempo de inatividade com base no risco e na natureza da funcionalidade.
Implementar proteção contra força bruta para autenticação.
Os ataques de força bruta envolvem tentativas automatizadas e sistemáticas de adivinhar as credenciais do utilizador, por exemplo, tentando várias combinações de nomes de utilizador e palavras-passe para obter acesso não autorizado.
A proteção de força bruta restringe o número de tentativas de início de sessão num determinado período. A implementação da proteção de força bruta para autenticação pode reduzir significativamente o risco de acesso não autorizado, proteger as contas dos utilizadores e manter a integridade do processo de autenticação. Os programadores devem implementar mecanismos de força bruta através das seguintes boas práticas:
Implementar controlos anti-automáticos.
Aplicar limitação de taxa para tentativas de início de sessão.
Incorporar atrasos de tempo progressivos (por exemplo, 30 segundos, 1 minuto, 2 minutos, 5 minutos) para tentativas de início de sessão.
Tenha em atenção que todos os mecanismos MFA são vulneráveis à força bruta, pelo que é essencial transmitir as razões do bloqueio da conta e fornecer meios acessíveis para os utilizadores se autenticarem e removerem o bloqueio. Os exemplos incluem chamar um
linha de apoio ou utilizando a verificação biométrica.
Implementar um mecanismo de verificação da integridade da transação.
Embora a autenticação garanta a identidade do utilizador, não elimina a possibilidade de actividades fraudulentas durante o processo de transação. Os mecanismos de verificação da integridade das transacções são funções de segurança auxiliares que dão aos utilizadores o tempo e as ferramentas para reagir a potenciais fraudes. A implementação de um mecanismo de verificação da integridade da transação garante que cada transação é submetida a um exame minucioso para confirmar a sua exatidão e autenticidade.
Os programadores podem implementar as seguintes melhores práticas sugeridas:
Iniciar uma chamada de verificação/confirmação de transação.
Fornecer um histórico de transacções em tempo real.
Implementar um período de arrefecimento de 12 horas para 24 horas.
Desativar as transacções no estrangeiro por predefinição; ativar apenas através de MFA.
Autorização
Definir e validar os direitos de acesso dos utilizadores aos recursos relevantes da aplicação.
Implementar a autorização do lado do servidor.
A autorização do lado do servidor refere-se à validação e concessão de permissões de acesso a utilizadores ou aplicações por um servidor ou um servidor de autorização. Isto garante que as decisões e permissões de controlo de acesso são geridas e aplicadas do lado do servidor e não do lado do cliente/pelo dispositivo. Ao implementar a autorização do lado do servidor, os programadores reduzem as oportunidades de os atacantes mal-intencionados adulterarem ou contornarem as medidas de segurança na aplicação para obterem acesso não autorizado a dados sensíveis (por exemplo, PII e dados de autenticação).
Os programadores devem implementar a autorização do lado do servidor após uma autenticação bem sucedida antes de conceder permissões de acesso e garantir que os utilizadores recebem acesso com base no seguinte:
Função atribuída com permissões: Garantir que os utilizadores só podem executar tarefas relevantes para as suas responsabilidades.
Factores contextuais: Cenários de acesso dinâmicos, como o tempo de acesso e a análise comportamental.
Implementar a autorização do lado do cliente através da ligação ao dispositivo.
A autorização do lado do cliente (ou seja, no dispositivo) gere as permissões de acesso numa aplicação móvel. Isto é arriscado, uma vez que confiar na autorização do lado do cliente pode expor as aplicações a vulnerabilidades como o acesso não autorizado e potenciais fraudes.
Se as funções comerciais de uma aplicação (por exemplo, a instanciação de tokens de software) exigirem autorizações do lado do cliente, recomenda-se a associação de dispositivos (uma prática de segurança que associa autorizações a privilégios de acesso num determinado dispositivo). Ao implementar a associação de dispositivos, as aplicações podem verificar a identidade do dispositivo e estabelecer confiança. Isto reduz os riscos associados ao acesso não autorizado e mantém um caminho seguro e fiável entre dispositivos, aplicações e servidores. Os programadores devem estabelecer a ligação entre as aplicações e o dispositivo quando a identidade de um utilizador é utilizada pela primeira vez num dispositivo móvel não registado e devem também verificar se as aplicações:
Verificar se houve modificações no dispositivo desde o último tempo de execução.
Verificar se existem modificações nos marcadores de identidade do dispositivo.
Verifique se o dispositivo que está a executar a aplicação é seguro (por exemplo, sem jailbreaking ou rooting).
Estes são apenas alguns exemplos de técnicas de boas práticas utilizadas pelo sector. À medida que o ecossistema de dispositivos móveis evolui, estas técnicas podem ficar desactualizadas. Como tal, os programadores devem manter-se a par das mais recentes práticas recomendadas da indústria para verificar as ligações de dispositivos.
Para verificar um dispositivo Android, os programadores podem:
Obter identificadores únicos como o IMEI ou o ID Android.
Recuperar informações de construção.
Tirar partido das funcionalidades nativas da API do SO, como a SafetyNet da Google.
Para verificar um dispositivo iOS, os programadores podem:
Tirar partido dos serviços nativos do SO, como a ID do dispositivo da Apple, através do UIDevice.
A aplicação notifica os utilizadores de todas as permissões necessárias antes de a utilizarem.
As permissões necessárias são direitos e capacidades específicos que a aplicação solicita ao dispositivo móvel. Estas permissões definem os recursos ou funcionalidades a que a aplicação pode aceder nos dispositivos dos utilizadores. Alguns exemplos incluem, mas não estão limitados a, câmara, microfone e localização.
Ao implementar notificações adequadas que informem os utilizadores sobre as permissões que estão a ser solicitadas, os programadores podem evitar que os utilizadores concedam, sem saber, permissões excessivas, o que pode permitir que agentes maliciosos explorem vulnerabilidades e roubem dados sensíveis (por exemplo, PII e dados de autenticação). Essas notificações também permitirão aos utilizadores tomar decisões informadas sobre as aplicações que instalam.
Os programadores devem:
Utilize alertas na aplicação para pedir permissão aos utilizadores para aceder.
Certifique-se de que as Notificações/Alertas não apresentam dados sensíveis.
Solicite apenas as permissões essenciais para a funcionalidade da aplicação.
A aplicação notifica os utilizadores de todas as transacções de alto risco autorizadas e concluídas.
Se uma aplicação tiver funcionalidades de transação de alto risco, os utilizadores devem ser notificados imediatamente quando uma transação tiver sido autorizada e concluída. Ao implementar este controlo, os programadores podem garantir que os utilizadores são imediatamente informados quando as transacções de alto risco foram autorizadas e concluídas, para que possam identificar potenciais transacções fraudulentas o mais rapidamente possível.
Os programadores devem adotar os seguintes métodos para alertar um utilizador:
Alertas na aplicação (In-App).
Notificações por correio eletrónico.
Notificações do Serviço de Mensagens Curtas (SMS).
Os programadores devem também garantir que as notificações/alertas não apresentam dados sensíveis e apenas solicitam as permissões essenciais para a funcionalidade da aplicação.
Os exemplos acima são apenas algumas das melhores práticas de técnicas de notificação utilizadas pelo sector. À medida que o ecossistema dos dispositivos móveis evolui, estas técnicas podem ficar desactualizadas. Como tal, os programadores devem manter-se a par das melhores práticas do sector para notificar os utilizadores de transacções de alto risco autorizadas e concluídas.
Armazenamento de dados
Proteger a integridade e a confidencialidade dos dados sensíveis no dispositivo do utilizador e no servidor de aplicações.
A aplicação armazena dados sensíveis que só são necessários para as transacções.
Os dados sensíveis são definidos como dados do utilizador (PIIs) e dados de autenticação (por exemplo, credenciais, chaves de encriptação). Os programadores só devem armazenar dados sensíveis que sejam necessários para as funções comerciais da aplicação. A acumulação de informações desnecessárias aumenta o impacto de potenciais violações de segurança, tornando uma aplicação um alvo atrativo para agentes maliciosos.
Ao implementar este controlo de segurança, os programadores podem garantir que a exposição é limitada aos dados necessários para funções comerciais específicas, minimizando o impacto do acesso não autorizado ou das violações de dados.
Os programadores devem classificar os dados utilizados pela aplicação com base nos níveis de sensibilidade de uma organização e com base nos requisitos legais e adotar as seguintes orientações para proteger os dados classificados como sensíveis:
Implementar uma solução de armazenamento seguro com base na sua sensibilidade no lado do cliente/servidor.
Aplicar medidas de proteção de dados (por exemplo, tokenização, hashing com sal, encriptação)
Eliminar dados sensíveis quando já não forem necessários.
A aplicação implementa o armazenamento seguro de dados sensíveis.
O armazenamento seguro para aplicações móveis refere-se à implementação de técnicas e práticas para proteger dados sensíveis armazenados em dispositivos móveis e servidores de aplicações contra acesso não autorizado, roubo ou adulteração. Isto envolve as melhores práticas, tais como encriptação, hashing, tokenização e controlos de acesso adequados. Ao implementar o armazenamento seguro, os programadores podem mitigar o acesso não autorizado, o comprometimento de dispositivos e potenciais violações e fugas de dados.
Os programadores devem implementar uma solução de armazenamento seguro que seja proporcional à sensibilidade dos dados e devem também dar prioridade à seguinte ordem para uma solução de armazenamento seguro (dos dados mais sensíveis para os menos sensíveis):
Do lado do servidor (todos os dados sensíveis devem ser armazenados do lado do servidor).
Do lado do cliente, no âmbito do Trusted Execution Environment (se for impossível do lado do servidor, armazenar todos os dados sensíveis no TEE do lado do cliente).
A aplicação armazena dados sensíveis de forma segura no lado do servidor.
O armazenamento de dados sensíveis no lado do servidor refere-se ao armazenamento de dados em servidores de aplicações ou bases de dados remotas. Esta abordagem cria um melhor ambiente para proteger os dados contra o acesso não autorizado ou violações, permitindo um controlo de acesso mais seguro, opções para implementar melhores medidas de segurança, como encriptação mais complexa, e disposições para actualizações de segurança mais rápidas.
Ao implementar o armazenamento de dados sensíveis no lado do servidor, os programadores podem mitigar os riscos inerentes ao armazenamento de dados no lado do cliente, uma vez que o armazenamento no lado do cliente é inerentemente mais suscetível às técnicas de exploração do armazenamento de dados habitualmente utilizadas por agentes maliciosos em fraudes móveis.
Os programadores devem aplicar pelo menos uma das seguintes medidas de proteção de dados:
Apenas para as palavras-passe, os programadores podem utilizar o hashing com sal (o hashing com sal é utilizado para adicionar uma camada extra de segurança, tornando-o computacionalmente intensivo para os atacantes
Para decifrar dados sensíveis originais. No contexto do armazenamento de palavras-passe ou da derivação de chaves, os programadores devem utilizar funções de derivação de chaves unidireccionais ou algoritmos de hash lentos, como PBKDF2, bcrypt ou script). Em vez de armazenar as palavras-passe reais, são gerados sais únicos que são combinados com as palavras-passe, criando hashes salgados.
Os programadores podem encriptar dados sensíveis com normas de encriptação como o AES-128.
Os programadores podem implementar a tokenização com tokenização auto-gerida ou com um serviço de tokenização, substituindo os dados sensíveis por tokens sempre que possível. Além disso, os programadores devem garantir que a tokenização é suficientemente longa e complexa (apoiada por criptografia segura) com base na sensibilidade dos dados e nas necessidades comerciais.
Estes são apenas alguns exemplos das melhores práticas do sector. À medida que o ecossistema de dispositivos móveis evolui, estas melhores práticas podem ficar desactualizadas. Como tal, os programadores devem estar a par das mais recentes práticas recomendadas da indústria para armazenar dados sensíveis de forma segura no servidor.
A aplicação armazena dados sensíveis de forma segura no lado do cliente num Ambiente de Execução Fidedigno (TEE).
O Trusted Execution Environment (TEE) é uma área isolada na arquitetura do hardware ou do processador de um dispositivo móvel que proporciona um ambiente altamente seguro para armazenar dados sensíveis e executar operações sensíveis ou críticas. Protege dados sensíveis, chaves criptográficas e processos críticos contra acesso não autorizado ou adulteração. Se as funções comerciais de uma aplicação exigirem armazenamento sensível do lado do cliente, este deve ser armazenado no TEE do dispositivo.
Os programadores podem atenuar as ameaças provenientes de um dispositivo comprometido e de agentes maliciosos externos, armazenando corretamente os dados sensíveis no TEE do lado do cliente. Esse armazenamento pode também reduzir o acesso não autorizado aos dados sensíveis de um utilizador numa aplicação e impedir que quaisquer chaves de encriptação sejam roubadas.
Os programadores devem armazenar dados sensíveis de forma segura do lado do cliente num ambiente de execução fiável (Trusted Execution Environment - TEE), como o TrustZone do ARM do Android e o Secure Enclave da Apple. Os programadores devem também armazenar, no mínimo, a seguinte lista de dados sensíveis num TEE:
Identificadores biométricos.
Tokens de autenticação.
Chaves criptográficas num sistema seguro de gestão de chaves, como o Android Keystore ou o iOS Keychain.
Os exemplos acima são dados sensíveis que os programadores devem armazenar no TEE. À medida que o ecossistema dos dispositivos móveis evolui, os programadores devem poder armazenar quaisquer dados necessários no TEE.
Os programadores podem considerar a utilização de TEEs virtualizados para dispositivos sem TEEs de hardware. Em alternativa, os programadores podem desativar a aplicação ou as suas funções de transação de alto risco, uma vez que a aplicação é considerada insegura para transacções de alto risco.
A aplicação elimina os dados sensíveis quando já não são necessários.
Apagar dados sensíveis significa remover ou apagar permanentemente dados confidenciais, privados ou sensíveis de dispositivos de armazenamento, servidores ou bases de dados. Este processo assegura que os dados sensíveis são irrecuperavelmente removidos e não podem ser acedidos, recuperados, acidentalmente expostos ou reconstruídos por indivíduos não autorizados ou através de métodos de recuperação de dados.
Ao implementar este processo, os programadores podem minimizar a janela em que os atacantes podem explorar vulnerabilidades para roubar dados sensíveis. Os programadores devem utilizar as seguintes técnicas de segurança de armazenamento persistente:
Limpar os cookies armazenados ao terminar a aplicação ou utilizar o armazenamento de cookies na memória.
Remover todos os dados sensíveis na desinstalação da aplicação.
Quando as funções comerciais relacionadas cessarem, remova manualmente todos os ficheiros de base de dados que contenham dados sensíveis (por exemplo, caches do iOS WebView) do sistema de ficheiros.
Estes são apenas alguns exemplos das melhores práticas do sector. À medida que o ecossistema dos dispositivos móveis evolui, estas técnicas podem ficar desactualizadas. Como tal, os programadores devem estar a par das mais recentes práticas recomendadas da indústria para eliminar dados sensíveis quando já não são necessários.
Anti-manipulação e anti-reversão
Implementar medidas para evitar que a aplicação seja adulterada ou comprometida. Os exemplos incluem capacidades antivírus e proteção contra a monitorização e espionagem do teclado.
A aplicação é assinada por código com certificados de lojas de aplicações oficiais.
As aplicações são frequentemente falsificadas por agentes maliciosos e distribuídas através de canais menos rigorosamente regulamentados. A assinatura de uma aplicação com certificados fornecidos por lojas de aplicações oficiais garante ao SO móvel e aos utilizadores que a aplicação móvel é verificada.
A implementação da assinatura de código ajuda os sistemas operativos a determinar se permitem a execução ou instalação de software com base nas assinaturas ou certificados utilizados para assinar o código. Isto ajuda a impedir a instalação e execução de aplicações potencialmente prejudiciais. Além disso, a assinatura de código também ajuda na verificação da integridade, uma vez que as assinaturas serão alteradas se a aplicação tiver sido adulterada.
Os programadores devem assinar o código das suas aplicações com certificados. Esta secção fornece exemplos de como o fazer através das duas plataformas mais populares, iOS e Android. Pode ser feito para a App Store da Apple, inscrevendo-se no Apple Developer Programme e criando um
pedido de assinatura de certificado no portal do programador. Os programadores podem registar-se no Programa para Programadores da Apple e consultar o seguinte guia do programador para assinatura de código em pontos a ter em conta. Para o Android, há uma variedade de lojas de aplicações. No caso da Play Store da Google, isso pode ser feito configurando o Play App Signing, que é um requisito para a distribuição através da Play Store da Google.
A aplicação implementa a deteção de jailbreak ou de raiz.
Os dispositivos com root e jailbroken são geralmente considerados inseguros. Permitem que os utilizadores obtenham privilégios elevados, permitindo contornar mais facilmente as limitações de segurança e do sistema operativo. Esses privilégios elevados podem ser inseguros para as aplicações, uma vez que permitem que agentes maliciosos explorem potencialmente vulnerabilidades, roubem credenciais, assumam o controlo dos dispositivos dos utilizadores e executem transacções fraudulentas com as aplicações.
Ao implementar o jailbreak ou a deteção de raiz, os programadores podem impedir que as explorações acima mencionadas aconteçam, proteger a propriedade intelectual das aplicações, garantir a estabilidade das aplicações e impedir o desvio dos sistemas in-app.
Deteção de jailbreak ou root no Android:
Verificar se existe um binário de superutilizador ou SU.
Detetar alterações no sistema de ficheiros raiz.
Procurar aplicações enraizadas.
Verificar a existência de recuperação personalizada.
Verificar a utilização não segura da API.
Deteção de jailbreak ou root do iOS:
Detetar a utilização de APIs restritas.
Procure por ajustes de jailbreak como mods.
Procure lojas de aplicações não oficiais, por exemplo, verifique a assinatura da Cydia App Store.
Procurar modificações no kernel.
Verificar a integridade dos sistemas de ficheiros críticos.
Utilize bibliotecas de terceiros concebidas para detetar a adulteração de dispositivos.
Estes são apenas alguns exemplos de verificações de boas práticas utilizadas pela indústria. À medida que o ecossistema dos dispositivos móveis evolui, estas verificações podem ficar desactualizadas. Como tal, os programadores devem estar a par das mais recentes práticas recomendadas da indústria para implementar a deteção de jailbreak ou root.
A aplicação implementa a deteção de emuladores.
Os emuladores são software utilizado para testar aplicações móveis. Permitem aos utilizadores testar uma aplicação móvel em várias versões e dispositivos móveis imitados. Embora úteis para testes, as aplicações não devem ser montadas em emuladores fora do ambiente de desenvolvimento.
Ao implementar a deteção de emulação, os programadores podem impedir que os intervenientes maliciosos executem análises dinâmicas, enraizamento, depuração, instrumentação, hooking e testes de fuzz num dispositivo emulado que possam controlar. Ao fazê-lo, os programadores podem impedir que os agentes maliciosos descubram vulnerabilidades na aplicação para exploração.
Os programadores devem implementar a seguinte estratégia de deteção para identificar as caraterísticas das soluções de emulação mais utilizadas. Algumas recomendações de coisas a verificar são:
Verificar a utilização da bateria.
Verificar os carimbos de data e hora e os relógios.
Verificar os comportamentos multi-toque.
Verificar a memória e a análise do desempenho.
Efetuar verificações de rede.
Verificar se é baseado em hardware.
Verifique em que é que o sistema operativo se baseia.
Verificar se existem impressões digitais do dispositivo.
Verificar as configurações de compilação.
Verifique se existem serviços e aplicações de emulador.
Estes são apenas alguns exemplos de verificações de boas práticas utilizadas pela indústria. À medida que o ecossistema de dispositivos móveis evolui, estas verificações podem ficar desactualizadas. Como tal, os programadores devem estar a par das mais recentes práticas recomendadas da indústria para implementar a deteção de emuladores.
A aplicação implementa a deteção anti-malware.
Os agentes maliciosos utilizam cada vez mais as aplicações de malware como vetor para comprometer os dispositivos móveis dos utilizadores. Estas aplicações proporcionam aos utilizadores a comodidade necessária para efetuar transacções diárias. As aplicações maliciosas utilizam principalmente funcionalidades de sideloading para levar os utilizadores a instalar malware nos seus dispositivos.
Ao implementar capacidades de deteção antimalware numa aplicação em tempo de execução, os programadores podem impedir que os utilizadores sejam explorados por malware que explora vulnerabilidades da aplicação e do SO, rouba credenciais, assume o controlo do dispositivo e executa transacções fraudulentas. Os programadores devem implementar capacidades de deteção anti-malware nas suas aplicações. Isto pode ser feito de várias formas, mas não se limita a:
Incorporar um kit de desenvolvimento de software (SDK) RASP (Runtime-Application-Self-Protection) nas suas aplicações.
Utilizar SDKs RASP para verificar e detetar aplicações de malware em tempo de execução.
Verificar e evitar sobreposições.
Evitar o roubo de cliques.
Evitar o gancho de memória da aplicação.
Estes são apenas alguns exemplos de verificações de boas práticas utilizadas pela indústria. À medida que o ecossistema dos dispositivos móveis evolui, estas verificações podem ficar desactualizadas. Como tal, os programadores devem estar a par das mais recentes práticas recomendadas da indústria para implementar a deteção anti-malware.
Se for detectada qualquer malícia, os programadores devem desligar a aplicação, fornecer ao utilizador as informações necessárias sobre o motivo pelo qual foi desligada e instar o utilizador a desinstalar a(s) aplicação(ões) maliciosa(s) do seu dispositivo. Em alternativa, os programadores devem avisar o utilizador e desativar as funções de alto risco da aplicação até que o utilizador corrija a(s) aplicação(ões) maliciosa(s).
A aplicação implementa mecanismos anti-hooking.
O hooking refere-se a uma técnica utilizada pelos atacantes para intercetar ou modificar o comportamento de uma aplicação móvel em tempo de execução. Isto envolve a inserção ou a ligação ao fluxo de execução de uma aplicação para monitorizar as suas actividades, alterar o seu comportamento, injetar código malicioso ou modificar funções de código existentes para explorar vulnerabilidades.
Ao implementar mecanismos anti-hooking nas aplicações, os programadores podem impedir a ocorrência dos ataques acima referidos e impedir o acesso não autorizado, proteger operações de transação de alto risco, detetar e impedir tentativas de adulteração e modificação, preservar a propriedade intelectual e manter a fiabilidade da aplicação. Os programadores devem implementar os seguintes exemplos de mecanismos para mitigar os ataques de hooking:
Implementar protecções para bloquear injecções de código.
Implementar protecções para evitar o enganchamento de métodos, impedindo modificações no código-fonte da aplicação (tanto no cliente como no servidor).
Implemente protecções para impedir a execução de códigos modificados na sua aplicação.
Implemente protecções para impedir o acesso à memória e a manipulação da memória da sua aplicação.
Implementar algoritmos resistentes à adulteração ou SDKs anti-violação (normalmente conhecidos como SDKs de auto-proteção de aplicações em tempo de execução).
Verificar a existência de parâmetros inseguros, como APIs e parâmetros obsoletos.
Estes são apenas alguns exemplos de verificações de boas práticas utilizadas pela indústria. À medida que o ecossistema dos dispositivos móveis evolui, estas verificações podem ficar desactualizadas. Como tal, os programadores devem estar a par das melhores práticas mais recentes da indústria para implementar mecanismos anti-hooking.
A aplicação implementa contramedidas de sobreposição, visualização remota e captura de ecrã.
As informações sensíveis podem ser captadas ou registadas sem o consentimento explícito do utilizador quando uma aplicação tem funcionalidades de gravação de ecrã, captura de ecrã ou sobreposição. Por exemplo:
Os ataques de sobreposição enganam os utilizadores criando uma camada falsa que imita aplicações de confiança, com o objetivo de roubar dados sensíveis.
Os ataques de visualização remota envolvem o acesso não autorizado ao ecrã de um dispositivo, permitindo aos atacantes recolher dados sensíveis remotamente.
Os ataques de captura de ecrã ocorrem quando agentes maliciosos capturam o ecrã de um dispositivo sem o consentimento do utilizador e extraem dados sensíveis.
A implementação de contramedidas de sobreposição, visualização remota e captura de ecrã pode garantir que as informações sensíveis permanecem seguras, que a privacidade do utilizador é mantida e que os dados sensíveis são protegidos contra perda inadvertida ou utilização indevida.
Os programadores devem implementar verificações anti-adulteração e anti-malware através de SDKs RASP para evitar que aplicações maliciosas utilizem sobreposições e explorações de visualização remota.
Para capturas de ecrã, os programadores podem utilizar o sinalizador FLAG_SECURE para aplicações Android e sinalizadores semelhantes para iOS para bloquear todas as capacidades de captura de ecrã durante a utilização da aplicação. No entanto, suponhamos que as funções comerciais exigem capacidades de captura de ecrã (por exemplo, tirar uma captura de ecrã de uma transação bancária concluída). Nesse caso, a recomendação é desativar as capacidades de captura de ecrã para ecrãs ou páginas que incluam dados sensíveis (PII e dados de autenticação). Os programadores podem também considerar a possibilidade de mascarar as entradas com dados sensíveis e ecrãs de sensores quando a aplicação está em segundo plano.
Alguns exemplos de onde desativar estas capacidades de captura de ecrã incluem, mas não se limitam a, páginas de início de sessão, páginas de autenticação multifactor, credenciais de segurança e páginas de alteração de informações pessoais.
A aplicação implementa a captura anti-keystroke ou anti-keylogger contra teclados virtuais de terceiros em dispositivos Android.
A captura de teclas e o registo de teclas são métodos que os agentes maliciosos utilizam para monitorizar, registar e gravar as teclas premidas num teclado sem o conhecimento e o consentimento do utilizador. Isto permite o registo e a captura de dados potencialmente sensíveis (por exemplo, PII e dados de autenticação).
Ao implementar um teclado in-app, os programadores podem controlar o destino dos dados de registo e reduzir o risco de teclados virtuais inseguros de terceiros actuarem como keyloggers para capturar as teclas premidas.
Para além da utilização de teclados na aplicação, os programadores devem implementar as seguintes sugestões para entradas que exijam dados sensíveis (por exemplo, PII e dados de autenticação): Desativar a correção automática, o preenchimento automático, a sugestão automática, cortar, copiar e colar para funções ou aplicações que contenham dados sensíveis. Algumas tarefas que devem utilizar teclados na aplicação incluem o início de sessão, a introdução de uma OTP ou outros factores de verificação.
