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

15

Preciso criar uma API de serviço da web para que nosso aplicativo para dispositivos móveis interaja com nosso servidor & banco de dados (no asp.net MVC 4, mas isso é pouco 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 do nosso aplicativo.

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

Minha ideia inicial é que o dispositivo peça ao servidor um token, que é gerado aleatoriamente e enviado como está. Todos os outros métodos verificarão se os cabeçalhos de solicitação contêm um hash específico 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 como uma vida útil limitada e o dispositivo deve receber outro a cada duas horas.

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

    
por Antoine 28.04.2013 / 12:06
fonte

1 resposta

15

Assim que você liberar o aplicativo, ele poderá 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 para todos os seus usuários.

Se você puder personalizar o aplicativo para cada usuário, talvez tenha a chance de não proibir outro aplicativo de usar sua API, mas pelo menos limitar 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. Respostas do servidor enviando um desafio criptografado com uma chave pública. Esta chave pública está associada ao identificador exclusivo enviado anteriormente.
  3. O cliente soluciona 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 gerado originalmente.

O desenvolvedor que irá hackear seu aplicativo e obter a chave privada com sucesso poderá usar sua API a partir de seu próprio aplicativo, mas ele será identificador como ele mesmo para seu servidor.

Se o mesmo usuário puder fazer 10 000 solicitações à 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 dele mesmo e talvez entregá-lo ao seu amigos, mas ele não poderia, digamos, vendê-lo a milhares de pessoas, só porque ele funcionaria apenas por alguns minutos pela manhã.

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

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

Assim que você considera a API não como uma ferramenta secundária reduzida à escravidão para seus novos aplicativos móveis, mas o produto real, no mesmo nível de qualquer aplicativo que o usuário realmente vê, você começa a pensar menos sobre como proteger API contra o uso de 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 quaisquer outros aplicativos, desenvolvidos livremente por qualquer pessoa. Isso tem vários benefícios:

  • Criar uma API para que ela seja usada apenas por seus aplicativos é difícil e caro. Este tempo e dinheiro podem ser usados para algo mais útil.

  • Abrir sua API para o público pode ter um grande benefício para você e para o mundo. Imagine que você é um grande arquiteto e um grande desenvolvedor, então criou uma API incrivelmente grande, mas suas habilidades de designer visual são ruins e você realmente não entende nada sobre design de interação, etc. Se você ocultar sua API, a única coisa que as pessoas vão saber é que você criou um aplicativo móvel que é inutilizável e feio. Se sua API for pública, outros desenvolvedores serão atraídos por sua qualidade e escreverão ótimos aplicativos para ela, trazendo muito dinheiro para você.

  • 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 para o 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 seriam as idéias.

por 28.04.2013 / 12:35
fonte