Segurança de esquemas de autenticação de REST

https://stackoverflow.com/questions/454355

19-08-2019
|

Pergunta

Fundo:

Eu estou projetando o esquema de autenticação para um serviço REST web. Isso não "realmente" necessidade de ser seguro (é mais de um projeto pessoal), mas eu quero fazê-lo o mais seguro possível como um exercício / experiência de aprendizagem. Eu não quero usar SSL desde que eu não quero que o aborrecimento e, principalmente, a despesa de configurá-lo.

Estas perguntas assim foram especialmente útil para me começar:

Eu estou pensando em usar uma versão simplificada do da Amazon S3 autenticação (I como OAuth mas parece muito complicado para as minhas necessidades). Eu estou adicionando uma gerados aleatoriamente nonce , fornecido pelo servidor, com o pedido, para evitar a repetição ataques.

Para chegar à pergunta:

Ambos S3 e OAuth dependem de assinatura do URL da solicitação, juntamente com alguns cabeçalhos selecionados. Nenhum deles assinar o corpo da solicitação para solicitações POST ou PUT. Não é este vulneráveis ??a uma the-middle man-in-ataque, o que mantém os cabeçalhos e URL e substitui o corpo da solicitação com todos os dados que o atacante quer?

Parece que eu pode proteger contra isso, incluindo um hash do corpo solicitação na cadeia que fica assinado. É este seguro?

Solução

A resposta anterior só SSL mencionada no contexto da transferência de dados e não chegou a cobrir autenticação.

Você realmente está perguntando sobre a autenticação segura clientes API REST. A menos que você estiver usando autenticação do cliente TLS, SSL somente não é um mecanismo de autenticação viável para uma API REST. SSL sem authc cliente só autentica o servidor , que é irrelevante para a maioria das APIs resto, porque você realmente quer autenticar o cliente .

Se você não usar a autenticação do cliente TLS, você precisa usar algo como um esquema de autenticação Digest-base (como o esquema personalizado da Amazon Web Service) ou OAuth 1.0a ou mesmo HTTP autenticação básica (mas sobre SSL apenas) .

Estes esquemas de autenticação que o pedido foi enviado por alguém que o esperado. TLS (SSL) (sem autenticação do cliente) garante que os dados enviados sobre o fio permanece untampered. Eles são separados - mas complementares - preocupações

Para os interessados, eu expandiu em uma pergunta SO sobre esquemas de autenticação HTTP e como eles funcionam .

Outras dicas

meio de REST trabalhar com os padrões da web, e o padrão de "seguro" de transferência na web é SSL. Qualquer outra coisa vai ser tipo de funky e exigir um esforço implantação extra para os clientes, que terão que ter as bibliotecas de criptografia disponível.

Uma vez que você se comprometer com SSL, não há realmente nada extravagante necessário para a autenticação em princípio. Você pode voltar a ir com os padrões web e usar HTTP Básico auth (nome de usuário e enviados símbolo segredo juntamente com cada pedido), pois é muito mais simples do que um protocolo de assinatura elaborado, e ainda eficazes no contexto de uma conexão segura. Você só precisa ter certeza que a senha nunca vai mais de texto simples; por isso, se a senha é sempre recebida através de uma ligação de texto simples, você pode até mesmo desativar a senha e enviar o desenvolvedor. Você também deve garantir as credenciais não está logado em qualquer lugar após o recebimento, assim como você não iria registrar uma senha regular.

HTTP Digest é uma abordagem mais segura, uma vez que impede que o segredo do token sendo repassados; Ao contrário, é um hash o servidor pode verificar na outra extremidade. Embora possa ser um exagero para aplicações menos sensíveis se você tomou as precauções mencionadas acima. Afinal de contas, a senha do usuário já é transmitida em texto simples quando fazem login (a menos que você está fazendo alguma criptografia JavaScript fantasia no navegador), e da mesma forma os seus cookies em cada solicitação.

Note que, com APIs, é melhor para o cliente a ser símbolos que passam - cordas gerados aleatoriamente - em vez da senha os logs de desenvolvedor para o site com. Então, o desenvolvedor deve ser capaz de entrar em seu site e gerar novos tokens que podem ser usados ??para verificação API.

A principal razão para usar um token é que ele pode ser substituído se ele está comprometido, enquanto que, se a senha for comprometida, o proprietário pode fazer logon na conta do desenvolvedor e fazer tudo o que quiser com ele. Uma outra vantagem de fichas é que você pode emitir vários tokens para os mesmos desenvolvedores. Talvez porque eles têm vários aplicativos ou porque querem fichas com diferentes níveis de acesso.

(Atualizado às implicações da tampa de fazer a conexão SSL-only.)

Ou você pode usar a solução conhecida para este problema e usar SSL. certs auto-assinados são gratuitos e é um projeto certo pessoal?

Se você precisar o hash do corpo como um dos parâmetros na URL e que URL é assinado por meio de uma chave privada, em seguida, um ataque man-in-the-middle só seria capaz de substituir o corpo com o conteúdo que geraria o mesmo hash. Fácil de fazer com valores de hash MD5 agora, pelo menos, e quando SHA-1 está quebrado, bem, você começa a foto.

Para proteger o corpo contra adulteração, você precisaria para exigir uma assinatura do corpo, que um ataque man-in-the-middle seria menos provável que seja capaz de quebrar uma vez que não saberia a chave privada que gera a assinatura.

Na verdade, o auth S3 originais faz permitir o conteúdo a ser assinado, embora com uma assinatura MD5 fraco. Você pode simplesmente impor sua prática opcional de incluir um cabeçalho Content-MD5 no HMAC (string a ser assinado).

http://s3.amazonaws.com/doc/s3- desenvolvedor-guia / RESTAuthentication.html

Seu novo esquema de autenticação v4 é mais seguro.

http://docs.aws.amazon. com / geral / latest / gr / assinatura-version-4.html

Lembre-se que as suas sugestões torna difícil para os clientes para se comunicar com o servidor. Eles precisam entender a sua solução inovadora e criptografar os dados em conformidade, este modelo não é tão bom para API pública (excepto se estiver amazon \ yahoo \ Google ..).

De qualquer forma, se você deve criptografar o conteúdo do corpo eu sugiro que você confira padrões e soluções como o existente:

criptografia XML (padrão W3C)

XML segurança

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow