Como proteger os serviços da Web RESTful?


88

Tenho que implementar serviços web RESTful seguros . Já pesquisei no Google, mas estou travado.

Opções:

TLS (HTTPS) +

Existem mais opções possíveis a serem consideradas? Se for OAuth, qual versão? Isso importa mesmo? Pelo que li até agora, o OAuth 2.0 com tokens de portador (ou seja, sem assinaturas) parece ser inseguro .

Eu encontrei outro artigo muito interessante sobre autenticação baseada em REST .

Proteja sua API REST ... da maneira certa

Respostas:


59

Existe outro método muito seguro. São certificados de cliente. Sabe como os servidores apresentam um certificado SSL quando você os contata em https? Bem, os servidores podem solicitar um certificado de um cliente para que saibam que o cliente é quem dizem ser. Os clientes geram certificados e os fornecem a você por meio de um canal seguro (como entrar em seu escritório com uma chave USB - de preferência uma chave USB sem trojan).

Você carrega a chave pública dos certificados do cliente cert (e o (s) certificado (s) de seu signatário, se necessário) em seu servidor web, e o servidor web não aceitará conexões de ninguém, exceto as pessoas que possuem as chaves privadas correspondentes para os certificados ele conhece. Ele é executado na camada HTTPS, então você pode até ignorar completamente a autenticação no nível do aplicativo como OAuth (dependendo dos seus requisitos). Você pode abstrair uma camada e criar uma Autoridade de Certificação local e assinar Solicitações de Cert dos clientes, permitindo que você ignore as etapas de "fazer com que eles cheguem ao escritório" e "carregar certificados no servidor".

Dor no pescoço? Absolutamente. Bom pra tudo? Não. Muito seguro? Sim.

No entanto, ele depende de que os clientes mantenham seus certificados seguros (eles não podem postar suas chaves privadas online) e geralmente é usado quando você vende um serviço para clientes, em vez de permitir que qualquer pessoa se registre e se conecte.

De qualquer forma, pode não ser a solução que você está procurando (provavelmente não é para ser honesto), mas é outra opção.


Ok, agora estou confuso qual é a melhor, esta abordagem ou outra resposta . Você poderia elaborar? : D
fikr4n

Sua resposta seria perfeita para mestres, mas é confusa para iniciantes. Você pode fornecer algumas informações detalhadas ou links para leitura?
Rajan Rawal

Se os certificados forem autoassinados, ainda é "muito seguro"?
Joyce

@Joyce eu acho que não. Como você não é confiável (sem ofensa), os certificados que você assina (com o seu próprio certificado) não são confiáveis. Acredito que certificados autoassinados são mais úteis para teste.
mbmast

Dado que o usuário final (cliente) tem um certificado de cliente cuja chave pública é compartilhada com o servidor, toda a coisa "muito segura" não desmorona se a máquina do cliente for hackeada e seu certificado de cliente roubado?
mbmast

18

HTTP Basic + HTTPS é um método comum.


3
Não acho que o resumo de http está fornecendo algo além de http básico se ambos estiverem em https.
pc1oad1etter

3
Você está convidado a adicionar informações úteis sobre os benefícios do HTTP digest sem o tom, a sério.
pc1oad1etter

9

Se escolher entre as versões do OAuth, use o OAuth 2.0.

Os tokens de portador OAuth devem ser usados ​​apenas com um transporte seguro.

Os tokens de portador OAuth são tão seguros ou inseguros quanto o transporte que criptografa a conversa. HTTPS se encarrega de proteger contra ataques de repetição, portanto, não é necessário que o token do portador também proteja contra repetição.

Embora seja verdade que, se alguém interceptar seu token de portador, ele pode se passar por você ao chamar a API, há muitas maneiras de reduzir esse risco. Se você der aos seus tokens um longo período de expiração e espera que seus clientes armazenem os tokens localmente, você tem um risco maior de os tokens serem interceptados e mal utilizados do que se der aos seus tokens uma expiração curta, exigir que os clientes adquiram novos tokens para cada sessão, e aconselhar os clientes a não persistirem em tokens.

Se você precisa proteger cargas úteis que passam por vários participantes, você precisa de algo mais do que HTTPS / SSL, uma vez que HTTPS / SSL criptografa apenas um link do gráfico. Isso não é uma falha do OAuth.

Os tokens do portador são fáceis de obter pelos clientes, fáceis de usar pelos clientes para chamadas de API e são amplamente usados ​​(com HTTPS) para proteger APIs voltadas ao público do Google, Facebook e muitos outros serviços.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.