Não entendi muito bem como funciona a proteção contra ataques CSRF. Se o servidor gera um token que fica gravado no html da página, o que impede um hacker de alterar o html da página e se utilizar do token gerado?
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
Solucionado
Não entendi muito bem como funciona a proteção contra ataques CSRF. Se o servidor gera um token que fica gravado no html da página, o que impede um hacker de alterar o html da página e se utilizar do token gerado?
Olá Fernando, tudo bem com você?
A questão é que não se trata de um token único do servidor para toda aplicação, caso fosse dessa maneira realmente não faria sentido :)
Essa abordagem que é chamada de Synchronizer Token Pattern, tem 2 formas de ser feitas:
O padrão da configuração feita é ser 1 por sessão, você pode checar isso visualizando o token gerado, deletando o cookie e logando novamente, e verá que o valor mudou
E com isso temos uma proteção, pois agora quem for executar o csrf precisa ter um token único gerado pelo servidor, ( o que já dificulta muito o ataque), agora vamos supor que de alguma forma ele tenha conseguido o token csrf, apenas deslogando do sistema já conseguimos invalidar e fazer com que esse ataque não ocorra, utilizando o por sessão se torna mais difícil ainda ( dado que o tempo de vida será de minutos), por isso que é dito uma proteção de token sincrono, não há como montar um html com algo fixo para simular um usuário cadastrado dado o servidor espera o token que é algo dinâmico e com tempo de vida bem pequeno, protegendo a aplicação desse tipo de ataque :)
Abraços e Bons Estudos!
Oi FERNANDO
O que você descreveu pode ser outro tipo de ataque. Mas o CSRF ocorre quando uma requisição HTTP é feita entre sites na tentativa de se passar por um usuário legítimo. Quem se utiliza desse tipo de ataque normalmente foca em fazê-lo esperando que usuário alvo esteja autenticado no site onde a requisição fraudulenta será realizada, a fim de se ter mais privilégios e acessos à operações. E a razão de todo o problema está em como os navegadores lidam com os Cookies.
A proteção classicamente utilizada nos formulários é a de criar um campo oculto com um token único por usuário. Esse token fica salvo na sessão do usuário no servidor e, quando o formulário é postado, o token enviado pelo formulário é comparado com o que se tem na sessão, lá no servidor. Sendo iguais, a requisição é aceita. Caso contrário, é recusada.
O token resolve o CSRF porque o atacante não tem como submeter uma requisição fraudulenta para o site destino com o token correto da sessão do usuário, o CSRF basicamente explora a forma como os Cookies do browse funcionam, mas sim, existem outros tipos de ataques que não necessariamente um token resolveria.
Abraço!
Obrigado pelas respostas!