shipfast api protection
vor, improvments, fixes and security updates
Bem-vindo! Este repositório faz parte desta série de postagens de blog sobre técnicas práticas de segurança da API. A série orienta você pelo processo de defesa de um back -end de API móvel contra várias façanhas que um invasor pode usar para obter acesso aos dados que possui. Neste cenário de demonstração, o ataque permite que os usuários reais do sistema obtenham uma vantagem injusta comercial às custas da empresa.
Este repositório detém todos os três componentes que são usados para descrever a história do shipfast:
Mantivemos todos os três projetos no mesmo repositório e estruturamos o código para incluir todas as etapas da progressão da série de blogs. Esperamos que isso facilite o entendimento como um todo.
Depois de definir a cena na primeira postagem do blog, entradas sucessivas mostram como as medidas de segurança podem ser fortalecidas (ou desviadas) usando links para o código neste repositório do GitHub, quando apropriado. A série de blogs pode ser resumida referindo -se ao principal método de segurança em discussão em cada um:
Fornecemos implantações disponíveis gratuitamente dos dois serviços e APKs para você baixar e instalar, para que você possa trabalhar com eles enquanto lê o blog. As seções a seguir fornecem um breve resumo dos serviços que implantamos, os aplicativos que fornecemos, onde encontrar o código associado neste repositório e onde estão localizadas as alterações para cada post do blog.
O código da API do Shipfast pode ser encontrado na pasta servidor/shipfast-api. O código é implantado na nuvem e disponibilizado em https://shipfast.demo.approov.io.
A API do Shipfast está em versão de v1 a v4 para seguir a história do blog e você pode acessar cada estágio usando os seguintes URLs:
A página de liberações deste repositório contém um APK para cada estágio. Eles estão configurados para que você possa instalar todos eles ao mesmo tempo no seu dispositivo Android (desculpe, não iOS no momento).
O código para os aplicativos está em um projeto AndroidStudio: App/Android/Kotlin/Shipfast.
Usamos um esquema de cores diferente em cada versão do aplicativo para que você possa identificar rapidamente qual está em execução:
As cores não têm nenhum significado especial, mas obviamente, o verde é o melhor.
O Rogue Web Service, Shipraider, foi configurado por um pirata maligno para ajudar os motoristas de navios a tirar proveito dos clientes de clientes rápidos. O código pode ser encontrado na pasta servidor/shipraider rogue-web.
Cada versão do site é servida de um domínio diferente:
O site da Shipraider segue o mesmo esquema de cores que os aplicativos móveis para diferenciar entre versões.
Abaixo, fornecemos uma breve visão geral das técnicas usadas na série de blogs para bloquear a API com links para as linhas de código relevantes e a postagem do blog associada.
O método mais comum usado pelos desenvolvedores para identificar o que está fazendo uma solicitação ao servidor da API é usar uma string longa no cabeçalho da solicitação, mais frequentemente chamado de Api-Key , consulte a primeira postagem do blog.
As chaves da API são muito simples de implementar no servidor e no cliente. Este código de aplicativo adiciona a chave a todas as solicitações e o servidor valida a solicitação com uma verificação simples do cabeçalho, conforme mostrado por este código.
Infelizmente, ignorar a proteção da chave da API também é fácil, pois é um segredo comunicado em todas as solicitações. O segundo blog da série começa mostrando como extrair a chave da API com um ataque MITM (homem no meio). A chave é então adicionada ao site da ShipRaider para ser usada nas solicitações que faz à API do navio.
Para melhorar a proteção, a segunda postagem do blog apresenta um HMAC para assinar as solicitações de API digitalmente e, portanto, impedir que sejam seqüestrados ou adulterados. É melhor que uma chave da API, pois a parte secreta nunca é enviada explicitamente do cliente para o servidor e, nesta versão, é estaticamente incorporada no código.
A implementação do HMAC é um pouco mais elaborada do que a implementação da chave da API, mas ainda é simples. Você pode verificar este código para a implementação do servidor API e este código para a implementação do aplicativo móvel.
No entanto, se o segredo do HMAC for codificado, ainda é fácil para um invasor extrair. A terceira postagem do blog demonstra isso usando ferramentas de análise binária de código aberto para revelar o segredo do HMAC e o algoritmo associado usado para assinar as solicitações. Uma vez copiados para o código do navio, o site Rogue pode subir e funcionar novamente.
O segundo cenário de ataque revelou que usar um segredo estático para o algoritmo HMAC é um ponto fraco. A próxima defesa é usar um segredo dinâmico; um que é calculado em tempo de execução. A terceira postagem do blog explica como combinar um segredo estático com dados dinâmicos para produzir um segredo dinâmico para inicializar o algoritmo HMAC.
A implementação do aplicativo móvel pode ser vista nessas linhas de código, enquanto o equivalente ao servidor da API pode ser visto aqui.
A computação do segredo do HMAC no tempo de execução torna mais difícil ignorar, mas não é impossível. O invasor agora precisa entender uma seção maior de código para reproduzir o comportamento no site da Shipraider. A quarta postagem do blog lista várias abordagens para isso, dando um exemplo mais detalhado usando a reembalagem de aplicativos e o depurador do Android Studio. Novamente, o invasor pode escrever um código equivalente no Shipraider para continuar usando a API SHIPFFFT.
A quarta postagem do blog, apresenta a medida de segurança final na série. O atestado de aplicativo móvel é o conceito de segurança da API implementado em Aprov. Em poucas palavras, a APPROOV verifica todo o aplicativo e o ambiente em que ele é executado antes de permitir o acesso à API - o aplicativo é a chave . Ele oferece um alto grau de confiança de que seus acessos à API estão bloqueados em instâncias legítimas do seu aplicativo. Essa abordagem é descrita com mais detalhes em nossa página de visão geral do produto e no white paper associado.
A integração Aproov é tão simples quanto pode ser para desenvolvedores de aplicativos móveis. Adicione o SDK apropriado à sua construção, esperançosamente usando um dos [exemplos de integração do QuickStart]]] (https://approov.io/docs/latest/approov-integration-examples/mobile-app/) para acelerar o processo e depois chamar o SDK para obter um aprovante para aproveitar a APROV para incluir a API Soldem. Você pode ver isso no aplicativo Shipfast em shipfastapp.kt, procure as linhas que são precedidas por // *** UNCOMMENT THE CODE BELOW FOR APPROOV *** .
A integração do servidor da API também é simples: use uma das muitas bibliotecas JWT para verificar o token Aprov antes de responder às solicitações da API. A API do Shipfast usa o pacote de nó expresso-jwt para verificar o token Aproov com o retorno de chamada checkApproovToken .
O documento de uso avançado descreve as etapas de compilação e implantação para cada um dos componentes que compõem os serviços de navios e shipraider. Para seguir a série de blogs, normalmente é suficiente usar os serviços e aplicativos implantados e mantidos pela equipe Aproov; nesse caso, você não precisa seguir esse documento. No entanto, você precisará disso se tentar o desafio opcional de pentesting, descrito no final da última postagem do blog.
A série de blogs, como um todo, mostra uma melhoria gradual na segurança da API, garantindo que as solicitações venham apenas de fontes legítimas. Os blogs e o código deste repositório são usados para mostrar como contornar facilmente alguns mecanismos de proteção comumente usados no desenvolvimento da API. Ele culmina em uma integração Aprov, que fornece o maior grau de confiança nas solicitações verificadas recebidas pela API do navio. Se você deseja explorar a solução Aprov em mais profundidade, por que não experimentar um dos links a seguir como ponto de partida:
