Solução permite se defender de intrusos ao publicar funcionalidades de servidor por meio de método público
Os browsers modernos se defendem de ataques cross-site scripting. Mas existe um outro tipo de ataque que é ainda mais fácil de lançar: cross-site request forgery (ou CSRF).
Os meliantes que usam CSRF criam um website com elementos clicáveis que colocam as operações maliciosas em funcionamento. A página falsa geralmente contém um script escondido que coleta os dados de um computador local e os envia para o servidor do cibercriminoso. Como você pode se proteger?
O ASP.NET MVC oferece uma solução: ele permite que você publique funcionalidades de servidor por meio de um método público de uma classe controladora. Se o método for crítico, você pode adicionar atributos para prevenir ataques CSRF. O ASP.NET MVC traz um método de ajuda para gerar marcação ad hoc HTML e um atributo ValidateAntiForgeryToken:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Update
(Customer customer)
{
:
}
O atributo HttpPost requer uma solicitação de POST para executar o método. Só isso já corta qualquer solicitação feita por meio de um GET simples. O ValidadeAntiForgeryToken também introduz o executor de comando do método ASP.NET MVC para procurar por algum conteúdo especial na solicitação principal antes de executar o código.
O ValidateAntiForgeryToken contém um código que é ativado durante a ação do método requisitado, garantindo que a solicitação postada contenha um cookie e campo de formulário com um nome fixo comum. Se alguns desses itens estiver faltando, é aberta uma exceção. Esse ajudante de ASP.NET MVC em HTML permite que você insira essa linha em um website:
O método Html.AntiForgeryToken cria um cookie em seu computador e adiciona um campo oculto ao formulário, como esse:
value=”j3Cj++/JUcS+kUMy/9Obj/
oM6ZW7vZozNo7+S” />
Se o alvo do formulário incluir o atributo ValidateAntiForgeryToken, o conteúdo do cookie e o campo de inserção são compensados antes da ação do método ser autorizada. Portanto, os invasores não poderão criar cookies válidos porque eles não saberão qual conteúdo colocar neles. E mesmo que o computador da vítima já contenha um cookie anti-forgery, o conteúdo do cookie não poderá ser lido via script para conseguir um campo de inserção on-the-fly. Um anti-forgery cookie é, na verdade, HttpOnly e não pode ser acessado via script.
*Dino Esposito é MVP da Microsoft e consultor independente de software.
