É seguro transmitir tokens de acesso através de cabeçalhos HTTP?

É o primeiro serviço web RESTful e estou preocupado com problemas de segurança. É seguro transmitir meu token de acesso por meio de cabeçalhos HTTP? Por exemplo:

POST /v1/i/resource HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e
Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8

parameter1=foo&parameter2=bar

A conexão feita SSL. Além disso, o que precisa ser definido como o scopeatributo para cadaaccess token

— ahmedsaber111
fonte

Respostas:

Se você transmitisse o cabeçalho do token de acesso por HTTP, ele ficaria vulnerável ao ataque intermediário.

Quando você transmite o cabeçalho do token de acesso por HTTPS, ninguém além do cliente poderá vê-lo, pois a solicitação será tunelada por meio de conexão segura.

— CodeART
fonte

Um cliente desleixado pode estar vulnerável a ataques MITM, mesmo com SSL.

— ott--

Você pode fornecer um exemplo, por favor?

— CodeART 31/08

Você não pode garantir a segurança do lado do cliente se não o controlar, mas isso vale para praticamente qualquer coisa.

— Matt

@CodeWorks A maioria dos navegadores oferece ao usuário a oportunidade de se conectar a um recurso HTTPS, mesmo que o certificado SSL esteja errado para o recurso. Essa é, sem dúvida, uma das coisas mais estúpidas que os autores de navegadores já fizeram, e está essencialmente se oferecendo para aceitar ataques MITM.

— 21813 Ross Spterson

@ Dan, esse certificado MITM específico deve ser adicionado à lista de certificados raiz dos clientes. Caso contrário, você reduziu o aviso HTTPS a um "lobo-chorão" literal, que A) treina seus usuários para ignorá-lo para sempre, B) é difícil (impossível por causa de A) diferenciar um ataque MITM real e malicioso.

— Nick T

Não há nenhum problema sério na transferência do token de acesso pelos cabeçalhos http, porque os dados transferidos são criptografados quando o SSL é usado, significa que ele só pode ser entendido por um cliente específico que fez a solicitação e pelo servidor que responde à solicitação, entre as quais não há chances de entender os dados por terceiros.

Outra coisa é que access tokensão baseados no tempo, para que eles tenham uma vida útil por um período específico, para que não tenham chances de uso no futuro.

— Ashwin
fonte

-1

Uma coisa a considerar também é o cache.

Seu back-end pode ver várias chamadas para o mesmo URL, com os mesmos parâmetros GET / POST, mas um token de acesso ao cabeçalho diferente e considerar o conteúdo pode ser armazenado em cache e separado para qualquer corpo.

— Thomas Decaux
fonte