poderia me explicar melhor o conceito de tokens de CSRF ??
poderia me explicar melhor o conceito de tokens de CSRF ??
Essa é daquelas siglas que a gente lê, dá um Google, e mesmo assim fica com cara de "tá, mas como isso funciona na prática?". Deixa eu tentar traduzir de um jeito que faça sentido :)
CSRF significa Cross-Site Request Forgery — ou "falsificação de requisição entre sites", numa tradução livre. O nome é assustador, mas o conceito é mais simples do que parece.
Imagina o seguinte: você tá logado no site do seu banco. Enquanto isso, numa outra aba, você abre um link que alguém mandou num grupo — pode ser um meme, um artigo, qualquer coisa. Só que essa página tem um código escondido que faz uma requisição pro site do seu banco. Algo tipo um formulário invisível que faz uma transferência pra conta de outra pessoa.
E aqui vem o ponto importante: como você tá logado no banco, o seu navegador já tem o cookie de sessão guardado. E cookies são enviados automaticamente em toda requisição pro domínio do banco — o browser não pergunta "ei, foi você que pediu isso?", ele simplesmente manda. Então o site do banco recebe a requisição com o cookie de sessão válido e pensa "beleza, é o usuário, tá autenticado, pode fazer a transferência". Mas não foi você. Foi a página maliciosa que disparou a requisição usando os seus cookies sem você saber.
Isso é o ataque CSRF.
E como a gente se protege disso? É aí que entra o token de CSRF. A ideia é bem direta: o servidor gera um código aleatório e único (o token) e entrega ele junto com a página. Geralmente esse token vem dentro de um campo oculto nos formulários, algo tipo:
<form action="/transferir" method="POST">
<input type="hidden" name="_csrf" value="a8f9d3e7b2c1...">
<input type="text" name="valor">
<input type="text" name="conta_destino">
<button type="submit">Transferir</button>
</form>
Quando você submete o formulário, o token vai junto com os dados. O servidor recebe, confere se o token bate com o que ele gerou pra aquela sessão, e só aí processa a requisição. Se o token não vier ou for diferente, o servidor rejeita tudo.
E por que isso funciona contra o ataque? Porque a página maliciosa até consegue disparar uma requisição pro site do banco (aproveitando os cookies), mas ela não tem como saber qual é o token CSRF que o servidor gerou. Ela não tem acesso ao conteúdo da página do banco — o navegador não deixa um site ler o HTML de outro site (isso se chama Same-Origin Policy). Então a requisição falsa chega sem o token, e o servidor descarta.
Agora, onde os cookies entram nessa história (que é o contexto da atividade do curso): o token em si pode ser armazenado num cookie. O servidor manda o token tanto no cookie quanto no formulário, e na hora de validar ele compara os dois. Se batem, a requisição é legítima. A página maliciosa até consegue enviar o cookie (porque cookies vão automaticamente), mas não consegue ler o valor dele pra colocar no corpo da requisição — então os dois não vão bater.
Isso tudo é um assunto de segurança backend que vai além do escopo do nosso curso de DOM. Mas é bom você ter essa noção porque, quando a atividade menciona "tokens de CSRF" como algo seguro pra guardar em cookies, agora você sabe o que são e por que moram ali. É uma daquelas coisas que você vai encontrar naturalmente quando começar a trabalhar com formulários e autenticação em projetos reais — e aí você já vai saber do que se trata.