Se eu apenas usar a autenticação baseada em nome de usuário / senha, eles não serão seguros o suficiente?
Não, porque você está apenas identificando a OMS está a aceder ao servidor de API, mas não o QUE está acessando.
A diferença entre QUEM e O QUE é acessar o servidor API
Para entender melhor as diferenças entre o QUEM e o QUE está acessando um servidor API, vamos usar esta imagem:
O Canal de Comunicação Pretendida representa o aplicativo móvel sendo usado como você esperava, por um usuário legítimo sem quaisquer intenções maliciosas, usando uma versão não manipulada do aplicativo móvel e se comunicando diretamente com o servidor API sem ser atacado no meio.
O canal real pode representar vários cenários diferentes, como um usuário legítimo com intenções maliciosas que pode estar usando uma versão reempacotada do aplicativo móvel, um hacker usando a versão original do aplicativo móvel, enquanto o homem no meio o ataca, para entender como a comunicação entre o aplicativo móvel e o servidor de API está sendo feita para poder automatizar ataques contra sua API. Muitos outros cenários são possíveis, mas não iremos enumerar cada um aqui.
Espero que agora você já tenha uma ideia do porquê o QUEM e O QUÊ não são os mesmos, mas se não, ficará claro em um momento.
O WHO é o usuário do aplicativo móvel que podemos autenticar, autorizar e identificar de diversas formas, como por exemplo, usando fluxos OpenID Connect ou OAUTH2.
OAUTH
Geralmente, o OAuth fornece aos clientes um "acesso delegado seguro" aos recursos do servidor em nome do proprietário do recurso. Ele especifica um processo para que os proprietários de recursos autorizem o acesso de terceiros aos recursos do servidor sem compartilhar suas credenciais. Projetado especificamente para funcionar com Hypertext Transfer Protocol (HTTP), o OAuth permite essencialmente que tokens de acesso sejam emitidos para clientes de terceiros por um servidor de autorização, com a aprovação do proprietário do recurso. O terceiro então usa o token de acesso para acessar os recursos protegidos hospedados pelo servidor de recursos.
OpenID Connect
OpenID Connect 1.0 é uma camada de identidade simples sobre o protocolo OAuth 2.0. Ele permite que os Clientes verifiquem a identidade do Usuário Final com base na autenticação realizada por um Servidor de Autorização, bem como obtenham informações básicas de perfil sobre o Usuário Final de maneira interoperável e semelhante a REST.
Embora a autenticação do usuário possa permitir que o servidor API saiba QUEM está usando a API, ela não pode garantir que as solicitações tenham se originado do QUE você espera, a versão original do aplicativo móvel.
Agora precisamos identificar o QUE está chamando o servidor API, e aqui as coisas se tornam mais complicadas do que muitos desenvolvedores podem pensar. O QUE é a coisa que está fazendo a solicitação ao servidor API. É realmente uma instância genuína do aplicativo móvel ou é um bot, um script automatizado ou um invasor mexendo manualmente com o servidor de API, usando uma ferramenta como o Postman?
Para sua surpresa, você pode acabar descobrindo que pode ser um dos usuários legítimos usando uma versão reempacotada do aplicativo móvel ou um script automatizado que está tentando gamificar e tirar proveito do serviço fornecido pelo aplicativo.
Bem, para identificar o QUÊ , os desenvolvedores tendem a recorrer a uma chave de API que geralmente eles embutem no código de seu aplicativo móvel. Alguns desenvolvedores vão além e calculam a chave em tempo de execução no aplicativo móvel, portanto, ela se torna um segredo de tempo de execução, em oposição à abordagem anterior, quando um segredo estático é incorporado ao código.
O artigo acima foi extraído de um artigo que escrevi, intitulado POR QUE SEU APP PARA CELULAR PRECISA DE UMA CHAVE DE API? , e que você pode ler na íntegra aqui , é o primeiro artigo de uma série de artigos sobre chaves de API.
Armazenamento de dados confidenciais no dispositivo do cliente
E não consigo salvar esse nome de usuário / senha no dispositivo por razões de segurança, é claro? Devo emitir um GUID para cada usuário no momento da inscrição, salvá-lo em seu dispositivo e recuperá-lo sempre durante uma solicitação de API?
Qualquer coisa que você salvar no dispositivo, mesmo se criptografada, pode sofrer engenharia reversa durante o tempo de execução com ferramentas como Frida ou Xposed.
Frida
Injete seus próprios scripts em processos de caixa preta. Conecte qualquer função, espie APIs de criptografia ou rastreie o código do aplicativo privado, sem a necessidade de código-fonte. Edite, clique em Salvar e veja os resultados instantaneamente. Tudo sem etapas de compilação ou reinicializações do programa.
xPosed
Xposed é uma estrutura para módulos que podem alterar o comportamento do sistema e aplicativos sem tocar em nenhum APK. Isso é ótimo porque significa que os módulos podem funcionar para diferentes versões e até mesmo ROMs sem nenhuma alteração (desde que o código original
Em um dispositivo que o invasor controla, ele também pode usar um proxy para realizar um Ataque Man in the Middle para extrair qualquer segredo que você possa usar para identificar o QUÊ ou o QUEM, conforme mostro no artigo Roube aquela chave API com um homem no ataque :
Embora possamos usar técnicas avançadas, como JNI / NDK, para ocultar a chave da API no código do aplicativo móvel, isso não impedirá que alguém execute um ataque MitM para roubar a chave da API. Na verdade, um ataque MitM é tão fácil que pode até mesmo ser realizado por não desenvolvedores.
E agora ... Estou condenado ao ponto de não conseguir proteger meu servidor API de ser abusado ?? Sem silêncio então ... a esperança ainda existe !!!
Soluções possíveis
Alguém pode me dizer qual método os aplicativos Android famosos, como Facebook, FourSquare ou Twitter, usam para autenticar cada solicitação proveniente de seu aplicativo móvel para seu servidor?
Desculpe, mas eu não tenho conhecimento suficiente sobre este aplicativo para ser capaz de elucidar você, mas posso apontar algumas outras abordagens.
Quais outros padrões estão disponíveis e quais são mais eficientes e seguros, eu só preciso de um fluxo de processo para isso.
Portanto, tudo o que é executado no lado do cliente e precisa de algum segredo para acessar uma API pode sofrer abusos de maneiras diferentes e você pode aprender mais nesta série de artigos sobre técnicas de segurança de API móvel. Este artigo ensina como as chaves API, tokens de acesso do usuário, HMAC e TLS Pinning podem ser usados para proteger a API e como podem ser contornados.
Para resolver o problema de O QUE é acessar seu aplicativo móvel, você precisa usar uma ou todas as soluções mencionadas na série de artigos sobre técnicas de segurança de API móvel que mencionei acima e aceito que elas só podem dificultar o acesso não autorizado ao seu servidor API ignorar, mas não impossível.
Uma solução melhor pode ser empregada usando uma solução Mobile App Attestation que permitirá ao servidor de API saber se está recebendo apenas solicitações de um aplicativo móvel genuíno.
Atestado de aplicativo móvel
O uso de uma solução Mobile App Attestation permitirá que o servidor API saiba O QUE está enviando as solicitações, permitindo, assim, responder apenas às solicitações de um aplicativo móvel genuíno, rejeitando todas as outras solicitações de fontes não seguras.
O papel de uma solução Mobile App Attestation é garantir em tempo de execução que seu aplicativo móvel não foi adulterado, não está sendo executado em um dispositivo com acesso root, não está sendo instrumentado por uma estrutura como xPosed ou Frida, não foi atacado por MitM, e isso é obtido executando um SDK em segundo plano. O serviço em execução na nuvem desafiará o aplicativo e, com base nas respostas, atestará a integridade do aplicativo móvel e do dispositivo em execução, portanto, o SDK nunca será responsável por quaisquer decisões.
No atestado bem-sucedido da integridade do aplicativo móvel, um token JWT de curta duração é emitido e assinado com um segredo que apenas o servidor API e o serviço Mobile App Attestation na nuvem estão cientes. No caso de falha no atestado do aplicativo móvel, o token JWT é assinado com um segredo que o servidor API não conhece.
Agora, o aplicativo deve enviar com cada chamada de API o token JWT nos cabeçalhos da solicitação. Isso permitirá que o servidor API atenda a solicitações apenas quando puder verificar a assinatura e o tempo de expiração no token JWT e os recusará quando falhar na verificação.
Uma vez que o segredo usado pelo serviço Mobile App Attestation não é conhecido pelo aplicativo móvel, não é possível fazer engenharia reversa no tempo de execução, mesmo quando o aplicativo é adulterado, executando em um dispositivo com acesso root ou se comunicando por uma conexão que está sendo alvo de um ataque do Homem no Meio.
O serviço Mobile App Attestation já existe como uma solução SAAS na Approov (eu trabalho aqui) que fornece SDKs para várias plataformas, incluindo iOS, Android, React Native e outras. A integração também precisará de uma pequena verificação no código do servidor API para verificar o token JWT emitido pelo serviço de nuvem. Essa verificação é necessária para que o servidor API possa decidir quais solicitações atender e quais negar.
Conclusão
No final das contas, a solução a ser usada para proteger seu servidor API deve ser escolhida de acordo com o valor do que você está tentando proteger e os requisitos legais para esse tipo de dados, como os regulamentos GDPR na Europa.
VOCÊ QUER PASSAR A MILHAS EXTRA?
Projeto de segurança móvel OWASP - 10 principais riscos
O Projeto de Segurança Móvel OWASP é um recurso centralizado destinado a fornecer aos desenvolvedores e equipes de segurança os recursos de que precisam para construir e manter aplicativos móveis seguros. Por meio do projeto, nosso objetivo é classificar os riscos à segurança móvel e fornecer controles de desenvolvimento para reduzir seu impacto ou probabilidade de exploração.
