Autenticação de usuário, quebrada.

1 year ago 103
BOOK THIS SPACE FOR AD
ARTICLE AD

Pretendo compartilhas com vocês algumas coisas que aprendi em livros e artigos, acredito que isso possa te ajudar.

Autenticação de usuário quebrada, refere-se a qualquer fraqueza no processo de autenticação da API. Essas vulnerabilidades geralmente ocorrem quando um provedor de API não implementa um mecanismo de proteção de autenticação ou implementa um mecanismo incorretamente.

A autenticação de API pode ser um sistema complexo que inclui vários processos com muito espaço para falhas. Algumas décadas atrás, o especialista em segurança Bruce Schneier disse: “O futuro dos sistemas digitais é a complexidade, e a complexidade é o pior inimigo da segurança”. As APIs RESTful devem ser sem estado. Para ser apátrida, o provedor não precisa lembrar o consumidor de uma solicitação para outra. Para que essa restrição funcione, as APIs geralmente exigem que os usuários passem por um processo de registro para obter um token exclusivo. Os usuários podem incluir o token nas solicitações para demonstrar que estão autorizados a fazer tais solicitações, como consequência, o processo de registro usado para obter um token de API, o manuseio do token e o sistema que gera o token podem ter seus próprios conjuntos de pontos fracos. Para determinar se o processo de geração de tokens é fraco, por exemplo, podemos coletar uma amostra de tokens e analisá-los em busca de semelhanças. Se o processo de geração de token não depender de um alto nível de aleatoriedade ou entropia, há uma chance de sermos capazes de criar nosso próprio token ou sequestrar o de outra pessoa.

O manuseio de tokens pode ser o armazenamento de tokens, o método de transmissão de tokens em uma rede, a presença de tokens codificados permanentemente e assim por diante.

Podemos detectar tokens codificados permanentemente em arquivos de origem JavaScript ou capturá-los enquanto analisamos um aplicativo da web. Depois de capturar um token, podemos usá-lo para obter acesso a endpoints anteriormente ocultos ou para ignorar a detecção. Se um provedor de API atribuir uma identidade a um token, assumiremos a identidade sequestrando o token roubado.

Os outros processos de autenticação que podem ter seu próprio conjunto de vulnerabilidades incluem aspectos do sistema de registro, como redefinição de senha e recursos de autenticação multifator. Por exemplo, imagine que um recurso de redefinição de senha exige que você forneça um endereço de e-mail e um código de seis dígitos para redefinir sua senha.

Bem, se a API permitisse fazer quantas requisições você quisesse, você só teria que fazer um milhão de requisições para adivinhar o código e redefinir a senha de qualquer usuário. Um código de quatro dígitos exigiria apenas 10.000 solicitações.

Observe também a capacidade de acessar recursos confidenciais sem ser autenticado. Chaves de API, tokens e credenciais usadas em URLs; falta de restrições de limite de taxa ao autenticar; e mensagens de erro detalhadas.

Por exemplo, o código em um repositório do GitHub pode revelar uma chave de API de administrador codificada:

_________________________________________________________________

“oauth_client”:

[{“client_id”: “12345-abcd”,

“client_type”: “admin”,

“api_key”:”AIzaSyDrbTFCeb5k0yPSfL2heqdF-N19XoLxdw”}]

___________________________________________________________________

Devido à natureza sem estado das APIs REST, uma chave de API exposta publicamente é o equivalente a descobrir um nome de usuário e uma senha. Ao usar uma chave de API exposta, você assumirá a função associada a essa chave.

ESPERO QUE TENHAM GOSTADO, E FIQUEM AVONTADE PARA ME SEGUIR NAS REDES SOCIAIS. Estou no Instagram como @diego_o.santoss. https://www.instagram.com/invites/contact/?i=c8d7p6azzkvj&utm_content=gva5bro

Read Entire Article