Como evitar o uso não autorizado de uma API?

Eu tenho que criar um "widget", um script que os parceiros incorporarão em seus sites para exibir alguma interface do usuário e fazer chamadas para nossa API.

Basicamente, ele exibirá nossos dados nesses sites com base em alguns códigos que eles fornecem em nossas chamadas de API. O que gostaríamos de evitar é alguém abusar da API e usá-la para raspar a totalidade do nosso catálogo.

Cada parceiro que incorporar nosso script receberá uma chave pública que deve ser fornecida ao chamar a API. Uma idéia seria pedir que eles acrescentassem essa chave ao carregar o script, por exemplo:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

Dessa forma, a solicitação do script pode ser usada para registrar o par de IP de chave / fonte e atender chamadas subseqüentes da API apenas se o par de chave / IP corresponder a um registrado (com uma vida útil limitada e um limite de solicitações por dia).

Não tenho certeza se é uma boa ideia, pois é obviamente segurança através da ofuscação (alguém que recarrega o script o ignora completamente); mas não vejo outra maneira de restringir o acesso. Não posso fornecer uma chave exclusiva para todos os usuários, apenas para parceiros. Não posso usar um sistema de chave privada, pois todo o código estará disponível para qualquer pessoa. É basicamente restringir o acesso a uma API pública, ou seja, contraditório em sua definição.

O que você acha dessa solução e o que você faria com essas restrições?

Você precisa de vários tipos de proteção.

Em primeiro lugar , você precisa impedir que a chave do Site A seja usada no Site B.

Em teoria, se a chave estiver vinculada a um domínio, você não poderá depender do referercabeçalho, mas como o cliente está incorporando um script diretamente, você pode confiar razoavelmente no lado document.locationdo cliente. Enviar diretamente esse local (ou partes dele) para o servidor não é confiável; mas você pode usá-lo para gerar uma chave de sessão:

1. O cliente incorpora a client_keysolicitação para a biblioteca da API.
2. O servidor determina o host que tem acesso à API, se houver.
3. O servidor seleciona "salt" para uma chave de sessão e a envia ao cliente com a biblioteca [ou como parte de outra troca de pré-autenticação].
4. O cliente calcula um session_keyuso hash(document.location.host + session_salt).
5. O cliente usa session_key+ client_keypara uma chamada de API.
6. O servidor valida a chamada pesquisando o client_keyhost e o "sal" na sessão, calculando o hash e comparando com o fornecido client_key.

Em segundo lugar , você precisa impedir o Hacker Hank de abrir o console de depuração ou usar um cliente modificado no Site A para fazer o que ele quiser com sua API.

Observe, porém, que é muito difícil, se não impossível, impedir completamente o Hacker Hank de abusar da API. Mas você pode dificultar ainda mais. E a maneira mais razoável de impedir Hank, que eu saiba, é a limitação de taxas.

• Limite o número de solicitações / segundo / sessão e solicitações / hora / sessão. (Os picos de atividade provavelmente são razoáveis, mas não sustentam tráfego acima da média de um único cliente.)
• Limite o número de sessões / IP / hora.
• Limite o número de solicitações / IP / hora. Permitir picos, mas não tráfego pesado sustentado a partir de um único IP.

Em terceiro lugar , como você provavelmente já está fazendo: criptografe o tráfego. Claro, a NSA verá; mas Hacker Hank é menos provável.

Parece que você está fazendo aqui transformando seus arquivos javascript em recursos protegidos. E agrupando-o com uma espécie de geração de token ao mesmo tempo. Isso é interessante.

Os profissionais de segurança com quem trabalho geralmente descartam o endereço IP imediatamente porque o IP é falsificado. Mas se você estiver usando uma restrição de IP combinada com SSL, isso geralmente funciona.

Mas você precisa "colocar na lista branca" os endereços IP, caso contrário, qualquer hacker pode simplesmente entrar pela porta da frente.

Eu era cético, mas estou realmente pensando que seu esquema funciona muito bem. Se 1) o arquivo .js e as chamadas de API subsequentes forem feitas com TLS (ou seja, SSL ou https) e 2) os IPs serão incluídos na lista de permissões. Então, vou fazer uma declaração ousada e dizer que acho que você passaria em uma revisão de segurança, mesmo para interações PCI (cartão de crédito).

IMHO ... Mas se você está apenas tentando proteger informações de propriedade da empresa em vez de informações de cartão de crédito (PCI) ou informações pessoais / privadas (PII), isso provavelmente é bom mesmo sem SSL, dependendo de quanto você disposto a arriscar expor seu catálogo.

Ou então: com SSL, um hacker dedicado não conseguiu seu catálogo. (A menos que eles quebrem o SSL, mas também possam quebrar a Amazon). Sem SSL, um hacker dedicado pode detectar suas chamadas, falsificar IP e exibir seu catálogo. Portanto, é uma espécie de julgamento sobre o risco.

Estou tentando pensar em uma maneira de dispensar a lista de permissões de IP, porque geralmente é um problema para gerenciar;) sem precisar usar o OAuth completo. Eu vou pensar nisso.