Com o mercado de desenvolvimento de aplicativos para aparelhos móveis (os famosos “mobile apps”) crescendo consideravelmente, os ataques a aplicações mobile também começaram a receber mais atenção, conforme já foi abordado em nosso artigo sobre o cenário de segurança mobile em 2020.
Consequentemente, muitos desenvolvedores e especialistas em segurança têm buscado conhecer cada vez mais sobre segurança no âmbito de aplicações para aparelhos móveis. No entanto, algumas vezes se deparam com dificuldade – principalmente relacionadas às peculiaridades do universo de aplicações mobile.
O objetivo deste artigo é justamente apresentar estas peculiaridades por meio da comparação entre segurança para aplicações web e segurança para aplicações mobile.
O código está no próprio aparelho
Possivelmente a maior diferença entre segurança de aplicações web e mobile está no fato de que enquanto em aplicações web, apenas uma pequena parte está acessível para o usuário (o código do front-end), em aplicações mobile, por mais que haja boa parte da lógica do negócio em uma API no back-end, o código do aplicativo está armazenado dentro do aparelho.
Portanto, qualquer um que fizer o download do aplicativo em seu aparelho móvel é capaz de inspecionar seu código, desde que possua os conhecimentos e as ferramentas adequadas.
Desta forma, é preciso ter em mente que possíveis agentes de ameaça irão inevitavelmente tirar proveito disso, uma vez que poder inspecionar o código facilita muito na compreensão de como um determinado sistema funciona.
Uma vez que isso esteja claro ao time de desenvolvimento, deve-se prestar ainda mais atenção com relação a quais informações serão armazenadas no aparelho. Afinal, mais uma vez, seu conteúdo estará todo no aparelho móvel, incluindo quaisquer dados que se opte por registrar em armazenamento local. Deve-se sempre pensar duas vezes antes de querer armazenar quaisquer informações localmente, para evitar possíveis vulnerabilidades como o item 2 da lista OWASP das 10 principais vulnerabilidades em aplicações mobile: Insecure Data Storage, ou armazenamento inseguro de dados.
Há ainda a possibilidade de um agente de ameaças alterar o código do próprio aplicativo móvel, utilizando, por exemplo, ferramentas como o FRIDA ou o Apktool para provocar os mais diversos comportamentos dentro do aplicativo – possivelmente afetando a API no back-end inclusive.
Comparando os Requisitos de segurança (MASVS vs ASVS)
Em um outro artigo, foi esclarecido com bastante detalhe do que se trata o OWASP – Application Security Verification Standard (ASVS) e como ele pode ser utilizado como uma base para a seleção dos requisitos de segurança de uma aplicação.
Mas para refrescar a memória, no ASVS se classifica o grau de risco de uma aplicação em 3 níveis e de acordo com o nível, serão necessários mais requisitos ou menos requisitos. O detalhe é que os níveis do ASVS são todos cumulativos. Ou seja: se uma aplicação for classificada como grau de risco nível 2, entende-se que para ela são recomendados todos os requisitos do nível 1 também. Da mesma forma, em uma aplicação classificada como nível 3, devem ser aplicados os controles de segurança dos níveis 3, 2 e 1.
Já na versão mobile deste padrão construído pela OWASP, não é bem assim que funciona. De uma certa forma, também há uma classificação em 3 níveis, mas não é tão simples como 1, 2 e 3. No MASVS, a classificação do risco é distribuída em níveis 1 e 2, com ou sem Resiliência contra engenharia reversa. Ou seja, entre os níveis 1 e 2 do MASVS, a avaliação do risco e a seleção dos requisitos se dá de forma bem semelhante ao ASVS. Porém, quando há o interesse em se proteger o código do aplicativo em si, devem ser implementados os requisitos da categoria 8 do MASVS, que são os requisitos exclusivos de resiliência.
Ou seja, interligando os requisitos de segurança com o fato de que o código da aplicação está armazenado no próprio aparelho, sempre que houver o interesse na proteção do código contra possíveis ataques de adulteração, engenharia reversa, ou como uma forma de proteção da propriedade intelectual do aplicativo, devem ser implementados os controles do nível “R” do MASVS.
De acordo com trecho do MASVS:
“The app has state-of-the-art security, and is also resilient against specific, clearly defined client-side attacks, such as tampering, modding, or reverse engineering to extract sensitive code or data.”
Desta forma, tomando o MASVS como base, no cenário de aplicações mobile a classificação de risco pode se dar pelo grau de risco, retirado das características do aplicativo, mais o interesse na proteção de seu próprio código, requisitos de resiliência. No caso do MASVS, portanto, pode-se ter 4 possibilidades de nível de requisitos de segurança a serem trabalhados:
- MASVS-L1
- MASVS-L1+R
- MASVS-L2
- MASVS-L2+R
Alguns dos controles de resiliência que devem ser observados envolvem a prática de ofuscação do código, detecção e resposta à adulteração de arquivos executáveis e detecção de “root” e “jailbreak” (que serão explicados mais à frente).
Sandbox
Ainda levando em consideração o fato de que no cenário de aplicações mobile o aplicativo está armazenado e sendo executado dentro do próprio aparelho, é necessário compreender que cada aplicativo dentro de um aparelho móvel funciona dentro de sua própria sandbox. Ou seja, dentro de seu próprio isolamento e não possui acesso a recursos de fora dele, a não ser que seja explicitamente permitido por outro app. Ou pelo menos é assim que deveria ser.
É justamente aí que se encontra o perigo. Há algumas formas de se romper esta caixa de isolamento, permitindo que um agente de ameaças, neste caso poderia ser uma pessoa mal intencionada ou até mesmo um malware contido no aparelho, realizem ações dentro do espaço do aplicativo, incluindo manipular eventos e furtar dados, por exemplo.
A quebra deste sandbox pode acontecer caso o aparelho esteja rooted ou Jailbroken. Ou seja, o dono do aparelho adulterou as condições de permissionamento do sistema operacional do dispositivo de modo a ter acesso irrestrito à quaisquer caixas destas contidas no aparelho.
Para evitar que isso ocorra, é altamente recomendado que seja implementada alguma forma de detecção de root ou jailbreak em seu aplicativo, de modo que ele seja fechado automaticamente assim que este tipo de comportamento for detectado, conforme recomendado pelo requisito 8.1, de Resiliência, no MASVS.
Outro cenário em que ocorre a quebra deste isolamento é quando o próprio time de desenvolvimento, de forma intencional ou não, deixa alguma “porta” aberta para algum recurso dentro de seu aplicativo. Isso será melhor abordado no item a seguir.
Configurações chave
Quando se pensa em configurações no cenário de aplicações web, geralmente leva-se em consideração configurações relacionadas principalmente às tecnologias utilizadas (cloud, frameworks, bancos de dados, etc.)
Já em aplicações mobile, é necessário compreender que todos os pontos de entrada, serviços que rodam em segundo plano, receptores, pontos de comunicação entre aplicativos, dentre outros itens, possuem suas configurações. E elas devem ser cuidadosamente analisadas.
Para facilitar a compreensão dos cuidados necessários, vamos analisar o seguinte fato. Para que um aplicativo possa ser capaz de utilizar os recursos do aparelho, tais como câmera, touchID, microfone, dentre outros, ele precisa temporariamente “abrir uma porta para fora de sua caixa de isolamento”. Muitas vezes não é aí que se encontra o problema, uma vez que os principais sistemas operacionais dos aparelhos móveis hoje em dia já possuem uma série de proteções para evitar cenários de ataque quando estes recursos forem solicitados.
O perigo está quando são deixadas algumas destas portas deste sandbox abertas, de modo que quaisquer outros aplicativos no aparelho possam acessar estes recursos expostos, como, por exemplo, um possível malware que esteja presente no mesmo aparelho.
Mais especificamente, no caso do Android, uma atenção especial deve ser dada ao arquivo AndroidManifest.xml, presente em qualquer aplicativo construído para Android. Dentro dele, estão todas as configurações destas “portas”, que muitas vezes são mantidas abertas por padrão, principalmente quando o aplicativo for construído utilizando linguagens não nativas. No IOS, possivelmente o item mais próximo seja o info.plist.
Comparando os equipamentos
Outra análise que não pode ser deixada de fora é com relação às características dos aparelhos móveis em relação aos computadores.
Além de questões como o tamanho médio, ou o próprio fato de que o aparelho móvel pode ser facilmente manipulado em qualquer local, na grande maioria das vezes, os dispositivos móveis coletam e armazenam muito mais informações do usuário do que os computadores, tais como localização, imagens, vídeos, áudios, etc. E um destaque especial para informações de cadastro, que muitas vezes também são armazenadas dentro do aparelho.
Se lembrarmos que a maior parte dos ataques à aplicações (tanto web quanto mobile) objetivam o furto de dados, conforme mencionado em nosso artigo sobre o cenário de segurança mobile em 2020, esta característica se torna ainda mais marcante.
Outro ponto a se considerar é que aparelhos móveis são muito mais facilmente roubados. De acordo com pesquisas realizadas pela CanalTech, cerca de 63 smartphones são roubados por hora nas principais capitais. Claro que muitos ladrões querem apenas vender os aparelhos e com isso obter seu lucro, mas muitos exploram o aparelho e aproveitam para furtar diversas informações, tais como credenciais de acesso à contas bancárias, e-mails, mídias sociais, etc.
Uma vez que estas diferenças estão claras para quem for desenvolver a segurança do aplicativo, nota-se que a proteção do dado deve considerar estas peculiaridades do cenário móvel.
Proteção dos dados
Com relação às recomendações para a proteção dos dados, as mesmas recomendações com relação ao uso de técnicas de criptografia se aplicam tanto ao cenário de web quanto de mobile, porém algumas recomendações se tornam ainda mais relevantes no cenário de aparelhos móveis, como é o caso do armazenamento dos dados de forma segura, que no caso de aplicativos mobile deve ser levado em consideração se estes dados podem vir a ser acessados por alguém que tenha roubado o aparelho ou por malwares contidos no mesmo.
Isso envolve uma análise quanto a quais dados de fato precisarão ser armazenados no dispositivo, quais configurações devem ser feitas no código do aplicativo, com quem este dado será compartilhado (dentro e fora do próprio aparelho), dentre outros pontos de atenção.
Outro ponto de atenção é com relação à comunicação entre o front e o backend. Em ambos os casos, web e mobile, deve-se buscar sempre utilizar de forma adequada os certificados de comunicação para garantir que estes dados não possam ser interceptados durante a transmissão. Mas vale lembrar que no caso de dispositivos móveis, hoje em dia é muito mais fácil alguém desavisado se conectar a uma rede wi-fi insegura, por exemplo, permitindo que um agente malicioso, utilizando ferramentas de proxy, consiga facilmente interceptar os pacotes, os famosos ataques de man-in-the-middle (MitM).
Sendo assim, em cenários de aplicações mobile, esse cuidado com a comunicação se torna ainda mais relevante, sendo altamente recomendada a implantação do SSLPinning e do Mutual TLS.
Comparando o pipeline de desenvolvimento seguro
Em outros artigos em nosso blog, já esclarecemos a respeito de como deve ser o Processo de Desenvolvimento Seguro, mas vale aqui um entendimento com relação a o que vai mudar em meu processo de desenvolvimento seguro agora com desenvolvimento mobile?
E a resposta é nada. O processo de desenvolvimento seguro será o mesmo independentemente de se tratar de uma aplicação web, mobile ou API. Ou seja, ainda devem ser realizadas as mesmas atividades, passando pelas revisões de design, modelagem de ameaças, revisão de código e ferramentas de análise estática e dinâmica.
O que vai mudar serão as ferramentas que serão utilizadas, uma vez que uma ferramenta de SAST para uma aplicação web desenvolvida em Java, não necessariamente funcionará corretamente para uma aplicação desenvolvida para Android, por exemplo.
Mas cabe aqui uma breve citação de quais ferramentas irão mudar em um processo de desenvolvimento seguro de aplicação mobile em relação à uma aplicação web.
Como já foi citado anteriormente, a avaliação do risco irá mudar, uma vez que as características das aplicações mobile são diferentes das aplicações web. Utilizar o mesmo método de avaliação de risco para ambas, pode fazer com que um determinado cenário que seja crítico em uma aplicação web, talvez não seja tão alarmante em uma aplicação mobile e vice versa.
Além disso, os requisitos de segurança serão diferentes. ASVS ou outras listas de requisitos de segurança devem ser trocadas por listas destinadas ao cenário de aplicações mobile, que contemplem requisitos específicos das principais plataformas mobile e requisitos de resiliência contra engenharia reversa, como o MASVS por exemplo.
Possíveis mudanças
Quanto às etapas de design, revisão de arquitetura e modelagem de ameaças, pouco irá mudar nas atividades em si. Mas vale ressaltar que, para uma modelagem de ameaças a uma aplicação mobile, é especialmente interessante que participem tanto os membros do time que desenvolve o aplicativo quanto os que trabalham no desenvolvimento da API, a fim de se tornar mais fácil e assertivo identificar cenários de ameaças envolvendo a relação entre estes dois componentes.
Nas etapas de codificação e testes, o que irá mudar serão as ferramentas que serão utilizadas. Note que ainda devem ser realizados tanto testes estáticos quanto dinâmicos no cenário mobile. Porém as ferramentas de testes para o cenário de mobile tendem a variar bastante seu modo de trabalho.
Tem-se visto no mercado o termo MAST, ou Mobile Application Security Testing. Ou seja, ferramentas de análises de segurança automatizadas que atuam especificamente no cenário de mobile. Muitos fornecedores do mercado de ferramentas de segurança em aplicações começaram a utilizar esta expressão. Porém algumas ferramentas chamadas de “MAST” atuam mais próximas de uma análise estática (SAST), enquanto outras atuam mais próximas do que seria uma análise dinâmica (DAST). Portanto, deve-se tomar cuidado ao selecionar a ferramenta.
Conforme já explicamos em nosso artigo sobre testes de segurança aplicados ao pipeline, é ideal que sejam realizadas tanto análises estáticas quanto dinâmicas, portanto, caso selecione uma ferramenta de MAST que atue como um SAST, busque ainda integrar outro recurso, automatizado ou não, para realizar análises dinâmicas e assim contemplar ambos os tipos de teste.
SAIBA MAIS SOBRE NOSSOS SERVIÇOS
Veredito
Em se falando do processo de desenvolvimento seguro de software, pouco irá mudar entre o desenvolvimento de aplicações web e mobile. O que irá se diferenciar mais serão as ferramentas utilizadas para um e para outro.
Já com relação à mentalidade de segurança, no caso de desenvolvedores mobile, deve-se ter em mente aquela primeira grande diferença: o código do seu aplicativo estará contido no próprio aparelho do seu usuário. Tendo isso em mente quando for desenvolver um aplicativo para dispositivos móveis, algumas práticas já começam a se tornar mais relevantes.
Além disso, aparelhos móveis tendem a coletar muitos dados e geralmente possuem muitos recursos, além do fato de que podem ser roubados com maior facilidade ou podem conter malwares que tentarão executar ações dentro de seus aplicativos. Sendo assim, todos estes pontos devem ser levados em consideração quando se estiver analisando a segurança de aplicação mobile.
Artigo por: Nicolas Schmaltz
