How to identify email data hack using anti-fake token

Question

I know how the anti-fake token in ASP.NET MVC works. But it is still unclear about several scenarios. One of them is mentioned below.

send a request for a request below

• cookie token (antiforgerytoken)
• form data (name and surname)
• enter hidden token (antiforgerytoken)

Before you reach the server, the data of the modified hacker form (name and surname) left the information about the tokens unchanged.

In this scenario, how can we ensure that the data submitted safely reached the server without any changes

Actually, this question is asked by the interviewer. I discussed with my colleagues, and I also searched on Google. Since I could not find clarity in this, I thought to ask here.

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

Answer 1

There are many different things. The confusion is related to the objectives of the various defenses, so let me try and understand this.

CSRF and antiforgerytoken

The main threat is as follows. The user of the victim is registered on the victim’s website. Meanwhile (say, in another browser tab) he visits the malicious website malicious.com, which wants to use CSRF on victim.com. To do this, at malicious.com, the user sends the required parameters to the .com victim to call a specific function that the victim user clearly did not want to perform. This is a basic CSRF case using an existing user session, malicious.com did something on the victim through the victim user.

This is prevented if antiforgerytoken is used because malicious.com will not be able to send the correct token to the .com victim, so the request will be rejected.

Please note that this has nothing to do with the legitimate content of the request.

Request Integrity

Another problem is that the request is received as sent, i.e. the data is the same. This is usually achieved using HTTPS, which provides message integrity and encryption (among others). Therefore, if HTTPS is used, such a data change during 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 a server), i.e. anything outside the TLS channel, then the attacker could modify the data. But that would mean customer control. For example, you can do this if you use a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, how penetration testers work. However, an attacker who does not have this level of control will not be able to do this.

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