Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to identify Post Data is hacked using anti-forgery token

I know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.

submit a post request with below information

  • cookie token(antiforgerytoken)
  • form data(first name & last name)
  • form input hidden token(antiforgerytoken)

Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.

In this scenario, how we can make sure the data submitted securely reached server without any modification

Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.

I am not sure if this is a valid question.If yes,any help would be appreciated

like image 964
samiaj Avatar asked Mar 03 '18 08:03

samiaj


People also ask

How does an anti-forgery token work?

Anti-Forgery TokensOne token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values. When the client submits the form, it must send both tokens back to the server.

How do you validate anti-forgery tokens?

To use it, decorate the action method or controller with the ValidateAntiForgeryToken attribute and place a call to @Html. AntiForgeryToken() in the forms posting to the method.

What is anti-forgery and example?

Anti-forgery stands for “Act of copying or imitating things like a signature on a check, an official document to deceive the authority source for financial gains”. Now, in the case of web applications, it is termed as CSRF.

Where are anti-forgery tokens stored?

ASP.NET Core uses a hidden field to store the anti-forgery token and uses the ValidateAntiForgeryToken attribute to validate the token. As the token is sent to the browser in a hidden field, it is also stored in an HttpOnly cookie.


1 Answers

Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.

CSRF, and antiforgerytoken

The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.

This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.

Note that this has nothing to do with legitimate request content.

Integrity of requests

A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.

Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.

Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)

like image 57
Gabor Lengyel Avatar answered Oct 26 '22 05:10

Gabor Lengyel