Quais são as melhores práticas para proteger uma API da web?

15

Preciso criar uma API de serviço web para nosso aplicativo móvel interagir com nosso servidor e banco de dados (no ASP.Net MVC 4, mas isso não é relevante). Enquanto a maioria das ações não precisa que os usuários sejam registrados em nosso serviço, gostaríamos de restringir o acesso apenas aos usuários de nosso aplicativo.

Quais são os métodos para garantir que as chamadas feitas de outro lugar (por exemplo, alguém que queira todos os nossos dados ou crie um aplicativo não oficial) sejam rejeitadas?

Minha ideia inicial é que o dispositivo solicite ao servidor um token, que é gerado aleatoriamente e enviado como está. Todos os outros métodos verificarão se os cabeçalhos da solicitação contêm um específico que será o hash md5 do token salgado. O servidor conhece o token e o salt e é capaz de calcular o hash e compará-lo com o enviado. Além disso, o token tem uma vida útil limitada e o dispositivo deve receber outro a cada duas horas.

Isso parece bastante fácil de implementar e, embora provavelmente não seja 100% a prova, parece ser uma boa idéia. O que você acha?

Antoine
fonte

Respostas:

15

Assim que você libera o aplicativo, ele pode sofrer engenharia reversa. Isso significa que não há nada que você possa fazer para estar 100% protegido se o mesmo aplicativo (mesmos binários, mesmas configurações) for distribuído a todos os seus usuários.

Se você pode personalizar o aplicativo para cada usuário, é possível que talvez não proíba outro aplicativo de usar sua API, mas pelo menos limite esse aplicativo pelo número de solicitações que ele pode fazer à API.

Imagine o seguinte esquema:

  1. O cliente conecta e envia seu identificador exclusivo (um identificador por usuário).
  2. O servidor responde enviando um desafio criptografado com uma chave pública. Essa chave pública está associada ao identificador exclusivo enviado anteriormente.
  3. O cliente resolve o desafio descriptografando os dados usando uma chave privada e envia o segredo descriptografado de volta ao servidor.
  4. O servidor verifica se o segredo enviado corresponde ao originalmente gerado.

O desenvolvedor que invadir seu aplicativo e obter a chave privada com êxito poderá usar sua API a partir de seu próprio aplicativo, mas ele será o próprio identificador de seu servidor.

Se o mesmo usuário puder fazer 10.000 solicitações para sua API por dia e, em média, um usuário ativo fizer 2.000 solicitações por dia, isso significa que esse desenvolvedor poderá usar o aplicativo por conta própria e talvez dar a seus amigos, mas ele não seria capaz de, por exemplo, vendê-lo para milhares de pessoas, apenas porque funcionaria apenas por alguns minutos pela manhã.

Embora isso ajude, também não é 100% à prova. E se o hacker encontrar uma maneira de extrair a chave privada do seu aplicativo quando ele estiver instalado no dispositivo?


Nota lateral que não responde à sua pergunta, mas ainda pode ser útil: não pense em uma API como uma ferramenta para seu produto principal (aplicativo móvel). Pense nisso como um produto de primeira classe , um produto que pode ser pago. O mesmo modelo é usado há anos pela Amazon e Google, passa a ser usado ativamente pela Microsoft com o Azure etc.

Assim que você considerar a API não como uma ferramenta secundária reduzida à escravidão para seus novos aplicativos móveis brilhantes, mas o produto real, no mesmo nível de qualquer aplicativo que o usuário realmente visualizar, você começará a pensar menos em como proteger a API. o uso por outros aplicativos e mais sobre a monetização da própria API . Essa API pode ser usada por seus aplicativos, que são seus clientes ou qualquer outro aplicativo, desenvolvido livremente por qualquer pessoa. Isso tem vários benefícios:

  • Fazer uma API para que ela fosse usada apenas por seus aplicativos é difícil e caro. Esse tempo e dinheiro podem ser usados ​​para algo mais útil.

  • Abrir sua API ao público pode trazer um grande benefício para você e o mundo. Imagine que você é um ótimo arquiteto e um ótimo desenvolvedor, por isso criou uma API surpreendentemente ótima, mas suas habilidades de designer visual são péssimas e você realmente não entende nada sobre design de interação etc. Se você oculta sua API, a única o que as pessoas saberão é que você criou um aplicativo móvel que não pode ser usado e é feio. Se sua API for pública, outros desenvolvedores serão atraídos por sua qualidade e criarão ótimos aplicativos para ela, trazendo muito dinheiro.

  • Você nunca imagina como outras pessoas podem usar suas APIs. Foi o que aconteceu com o Kinect. Originalmente, a Microsoft criou o Kinect para jogos. Quando a Microsoft abriu a API ao público, eles nunca imaginaram que ela seria usada alguns anos depois por aplicativos científicos, setor de saúde etc. É semelhante para APIs da Web: mais desenvolvedores estão usando, mais difundidas serão as idéias.

Arseni Mourzenko
fonte
Resposta muito interessante. Provavelmente, precisamos pensar em como tornar a API pública. Também para referência, o mercado-alvo na França, onde a engenharia reversa e a desmontagem são ilegais, por isso devemos nos preocupar muito com isso.
Antoine
2
@Antoine: A engenharia da Revere seria ilegal em qualquer país assim que a licença a proibisse. Mas o fato de ser ilegal não significa que ninguém reverenciará seu aplicativo.
Arseni Mourzenko