OAuth 2.0 e os tokens de acesso

Intervêm três atores. O cliente é a aplicação que pede o acesso. O servidor de autorização emite os tokens depois de autenticar o proprietário dos dados e de obter o seu consentimento. O servidor de recursos aloja os dados e aceita os pedidos acompanhados de um token⁶.

O token de acesso substitui as diferentes credenciais (nome de utilizador e palavra-passe, por exemplo) por um elemento único que o servidor de recursos compreende. Pode assim ter uma duração curta⁶. O token de atualização permite obter um novo, com direitos idênticos ou mais restritos: um token de acesso pode ter uma duração mais curta e menos permissões do que as concedidas pelo proprietário⁶.

O token mais comum é o token de portador: quem o possui pode usá-lo. A OWASP recomenda, por isso, limitá-lo de preferência a um único servidor de recursos, para reduzir os danos em caso de fuga⁶. A aplicação, por seu lado, deve tratar o token como uma cadeia opaca: só a API visada deve ler o seu conteúdo³.

Perante um ecrã de consentimento, bastam algumas verificações.

• Leia o pedido antes de o aceitar. Os utilizadores clicam muitas vezes em «Aceitar» sem examinar os detalhes, incluindo as permissões concedidas¹.
• Compare as permissões com o objetivo da aplicação. Uma aplicação só deveria pedir permissões ligadas à sua finalidade; a Microsoft dá o exemplo de uma aplicação de relógio com acesso total a todas as caixas de correio, o que não corresponde ao seu objetivo¹.
• Desconfie das permissões mais pesadas. O MITRE ATT&CK assinala que o acesso offline e o acesso à leitura de mensagens de correio eletrónico devem despertar mais suspeitas, porque os atacantes podem usar as API dos serviços online para aí procurar credenciais e comunicações sensíveis².
• Veja o endereço de redirecionamento. Se estiver mal escrito ou formar uma sequência de palavras complicada em torno de um serviço esperado, o site tenta provavelmente imitar um serviço verdadeiro².
• Prefira as aplicações comuns. Quanto mais difundida for uma aplicação, na organização como online, maior a probabilidade de ser segura¹.
• Recuse uma aplicação que não reconhece. O MITRE ATT&CK recomenda formar os utilizadores para não autorizarem aplicações de terceiros desconhecidas².
• Um administrador pode investigar as aplicações suspeitas e retirá-las².

O falso ecrã de consentimento

O atacante regista uma aplicação junto do servidor de autorização e depois envia uma ligação de phishing direcionado para levar a vítima a conceder-lhe o acesso². Um exemplo dado pela Microsoft: uma página de consentimento pode parecer legítima a um utilizador comum, quando o «Google APIs Explorer» não tem nenhuma razão para pedir permissões à própria Google. A aplicação pode, portanto, ser uma tentativa de phishing sem ligação à Google¹.

Os nomes tranquilizadores são comuns. O MITRE ATT&CK refere que o grupo APT28 usou aplicações maliciosas que se faziam passar por «Google Defender», «Google Email Protection» e «Google Scanner» junto de utilizadores do Gmail, e por «Delivery Service» e «McAfee Email Protection» junto de utilizadores do Yahoo².

O token que dura

Depois de concedido o token, a aplicação pode obter um acesso potencialmente duradouro às funções da conta². Com um token de atualização que permite o acesso em segundo plano, um atacante pode, por exemplo, pesquisar nas mensagens de correio eletrónico e enumerar os contactos⁵. Mudar a palavra-passe nem sempre resolve o problema: segundo o quadro da Microsoft, certos tokens continuam ativos depois de uma alteração da palavra-passe pelo utilizador⁴.

O token roubado sem lhe perguntar nada

O roubo de tokens nem sempre passa por um consentimento. O MITRE ATT&CK cita também tokens roubados em ambientes de contentores ou em cadeias de desenvolvimento, onde servem para autenticação junto de outros serviços². O programa Kali365 é descrito como tendo obtido tokens de acesso e de atualização OAuth ao enganar vítimas para que validassem pedidos de autorização de dispositivo iniciados pelo atacante².

A aplicação esquecida

Uma aplicação autorizada um dia continua ligada enquanto ninguém a retirar. A Microsoft recomenda identificar as aplicações cuja data da última autorização não é recente: podem já não ser necessárias¹. O MITRE ATT&CK pede aos administradores uma auditoria de todas as aplicações OAuth e das permissões concedidas, seguida de auditorias periódicas, com investigação e remoção das aplicações suspeitas². Para o colaborador, isto traduz-se num gesto simples: rever de vez em quando a lista de aplicações ligadas à sua conta e assinalar as que não reconhece.