O analista João administra o AuthServer, o servidor de autorização OAuth 2.0 do TJSE. João determinou que todos os clientes utilizem o parâmetro state nas requisições de autorização feitas ao AuthServer. Os clientes devem atribuir ao state um valor não adivinhável a cada nova requisição de autorização. Os clientes devem ainda validar se o state retornado pelo servidor após a autenticação condiz com o state enviado na requisição. De acordo com as especificações do protocolo OAuth 2.0, João estará mitigando diretamente o ataque malicioso:
- A)phishing;
Phishing é fraude de engenharia social para enganar o usuário, não é o ataque diretamente mitigado pelo uso do state no OAuth 2.0.
- B)clickjacking;
Clickjacking envolve induzir cliques em interfaces ocultas ou sobrepostas, e não é o alvo principal do mecanismo state.
- C)code injection;
Code injection trata de inserção de código malicioso em aplicações, algo fora do problema que o state resolve no fluxo de autorização.
- D)credentials guessing;
Credentials guessing é tentativa de adivinhar credenciais, mas o state não protege contra força bruta de senha ou login.
- E)cross-site request forgery.
Correta, pois o state serve para vincular requisição e resposta e mitigar CSRF no fluxo OAuth 2.0.
Gabarito: E
No OAuth 2.0, o parâmetro state funciona como um “selo” de correlação entre a requisição de autorização e a resposta recebida depois. A ideia é simples: o cliente gera um valor aleatório, difícil de adivinhar, envia junto com a requisição e confere se o mesmo valor volta na resposta. Se não bater, a resposta pode ter sido forjada ou desviada no caminho. Esse cuidado existe principalmente para evitar ataques de CSRF, que tentam induzir o navegador da vítima a aceitar uma resposta de autorização que não foi iniciada por ela. Em outras palavras, o state ajuda a garantir que a resposta do AuthServer pertence àquela tentativa legítima de login/autorização feita pelo próprio cliente. A própria especificação do OAuth 2.0 recomenda o uso de state para mitigar CSRF em fluxos de autorização. Em provas, isso costuma aparecer de forma bem direta: se o enunciado fala em valor não adivinhável, enviado na requisição e validado no retorno, pense em proteção contra CSRF. Por isso, o gabarito é a letra E. Não é um enfeite do protocolo, é um mecanismo de amarração entre ida e volta da autorização, evitando que alguém “embreve” a resposta no lugar do usuário legítimo.