Alternativa C
A questão aborda práticas de segurança para evitar Quebra de Controle de Acesso, focando na integridade das verificações realizadas no servidor.
Análise Detalhada
O enunciado destaca que o controle de acesso só é eficaz quando validado pelo lado do servidor. Isso significa que não devemos confiar nos dados enviados ou armazenados pelo cliente (navegador). Vamos analisar cada alternativa:
- (A) Exceto para recursos públicos, negar por padrão.
- Correto. O princípio de Segurança por Padrão (Fail-Secure) dita que, se uma permissão não foi explicitamente concedida, ela deve ser negada. Isso evita vazamentos acidentais.
- (B) Os identificadores de sessão com estado devem ser invalidados no servidor após o logout.
- Correto. Manter sessões ativas após o logout permite que um atacante use credenciais roubadas (ataque de Session Hijacking). A invalidação no servidor garante o encerramento seguro.
- (C) Gravar os dados de autenticação do usuário em cookies.
- Incorreto. Esta é a resposta correta da questão. Embora tokens de sessão sejam frequentemente armazenados em cookies, gravar dados de autenticação sensíveis (como papéis, permissões ou informações pessoais) diretamente em cookies no lado do cliente é arriscado.
- Motivo: O navegador é um ambiente hostil. Se um atacante conseguir injetar código (XSS) ou interceptar o tráfego, pode ler ou modificar esses dados. O controle de acesso deve ser decidido sempre pelo servidor, nunca baseado em atributos modificáveis no cliente.
- (D) Registrar falhas de controle de acesso e alertar os administradores...
- Correto. O monitoramento e registro (logging) são essenciais para detectar tentativas de invasão, como força bruta ou varredura de vulnerabilidades.
- (E) Limitar a taxa de acesso da API...
- Correto. O Rate Limiting impede ataques automatizados e negação de serviço, protegendo a infraestrutura contra sobrecarga e exploração sistemática.
Conclusão
A alternativa C é a incorreta porque confia excessivamente no cliente ao sugerir o armazenamento de dados de autenticação em cookies sem ressalvas de segurança rigorosas (como criptografia ou assinaturas digitais), o que contradiz o princípio de que a verificação crítica deve ocorrer no servidor.