What is the principle of adding random string csrf_token to a form to prevent CSRF cross-site attacks?

is a cross-site attack seen on the Internet, PHP framework Laravel added a csrf_token in the form to prevent cross-site attacks, want to ask when this random string is playing a role?

Reply content:

is a cross-site attack seen on the Internet, PHP framework Laravel added a csrf_token in the form to prevent cross-site attacks, want to ask when this random string is playing a role?

CSRF attacks are events that modify site data in the face of various forms submissions , but the URL address for each user's event is generally fixed. Users can access this address within your site, and when they are logged in, they can also successfully access this address through the external site , such as their own in the Address bar input: A website/transfer? To= "Zhang San" &money= "100", more special, you can implicitly access this URL through the JS script , secretly modify the site data, then the third-party site can access this address? The answer is yes, just like you can jump on your website Baidu, into their own Baidu home page (with user information). Therefore, third-party websites can use your cookie to operate secretly, so users and the site need some kind of "agreement" to prevent such arbitrary data modification, form verification with your own access to this page in order to obtain the token, verification through, in order to execute, at this time, for security, Of course you can't. Enter in the Address bar: a website/transfer? To= "Zhang San" &money= "100" to transfer money.

This attack is done in the following manner:
1. The user accesses the ServerA in a browser and logs in as an administrator (at this point the user is already certified on ServerA)
2. The user accesses a malicious page of ServerB, which may access an address of ServerA via Ajax or an IFRAME (impersonate the user to access a, but the user does not know at this time)
3.SERVERA accept this visit and complete the appropriate operation

Defense principle:
ServerA when using Csrf_token, each submitted form will contain a token, the server ServerA received will verify the token
Since this token is issued to the user by ServerA, only ServerA and users know that this ensures that the ServerB constructed attack link cannot be verified by ServerA at the 3rd step.

Before getting form input, verify that the incoming CSRF field is valid.
To put it simply, each time a form is submitted, add a CSRF field to the form, submit it with the table Singleton, and the 隐藏的随机的 server must first determine if the submitted CSRF field is consistent with the CSRF field on the servers, and if not, report an error directly.

I think this is used to prevent other Ajax accesses, and there are other software accesses, because to use a Csrf_token interface, you need to find the Csrf_token random string in the HTML.
The above is personal understanding

