Em aplicações Web, a vulnerabilidade denominada CSRF (cross site request forgery) ocorre quando solicitações não autorizadas a um website são enviadas a partir de um equipamento onde existe uma sessão ativa em que o website confia. Uma forma de se proteger desse ataque é a(o)
- A)desativação do recurso HSTS.
Errada, porque HSTS protege a navegação contra downgrade e ataques de protocolo, mas não impede requisições forjadas em nome do usuário.
- B)uso de cabeçalho X-Csrf-Protection nas requisições GET.
Errada, pois não existe essa proteção padrão para requisições GET e, além disso, CSRF não se resolve com um cabeçalho genérico assim.
- C)uso do atributo httponly nos cookies utilizados.
Errada, porque HttpOnly impede leitura do cookie por JavaScript, mas o navegador ainda envia o cookie automaticamente nas requisições.
- D)uso de tokens anti-csrf pela aplicação.
Certa, pois tokens anti-CSRF permitem ao servidor validar se a requisição foi realmente gerada pela aplicação legítima e não por um site malicioso.
- E)garantia que os cookies não serão enviados em texto claro na rede.
Errada, porque criptografar o tráfego evita interceptação na rede, mas não impede que o navegador envie uma requisição maliciosa com a sessão válida.
Gabarito: D
CSRF, ou cross-site request forgery, acontece quando o navegador da vítima envia uma requisição para um site confiável sem que ela perceba, aproveitando uma sessão já autenticada. Em outras palavras: o atacante não “rouba” a senha, ele faz a vítima clicar ou visitar algo que dispara uma ação indesejada em seu nome. É um golpe de confiança, bem no estilo “se o site confia no seu navegador, o navegador obedece”. A principal defesa é exigir um elemento que o atacante não consegue adivinhar nem reproduzir facilmente, como um token anti-CSRF gerado pela aplicação e validado no servidor. Esse token costuma ser único por sessão ou por formulário, e vai junto na requisição legítima, funcionando como um selo de autenticidade da ação. Por isso o gabarito é a letra D. Sem esse token, o servidor tende a aceitar requisições só porque os cookies de sessão foram enviados automaticamente pelo navegador. Com o token, a aplicação distingue uma ação realmente iniciada pelo usuário de uma requisição forjada por outro site. As demais alternativas não resolvem o problema central do CSRF. HSTS ajuda no uso de HTTPS, HttpOnly protege contra acesso via JavaScript, e garantir que os cookies não trafeguem em texto claro trata confidencialidade da rede, não a falsificação de requisições. Em doutrina de segurança web, a defesa clássica contra CSRF é justamente a combinação de token anti-CSRF e validações complementares, como checagem de origem e uso correto de SameSite nos cookies.