Some questions about form cross-origin submission prevention

Today, we can see the method in the book to prevent cross-origin submission. it generates a hidden input on the form submission page, and the value is the random number index in the session. php page {code ...} b. php code {code ...} my question is, can this really prevent cross-origin attacks? If I see the method in the book to prevent cross-origin submission today, it generates a hidden input on the form submission page and the value is a random number in the session.

Index. php page

The following is B. php code

if($_POST['token'] == $_SESSION['token']){    # do code}

My question is, can this really prevent cross-origin attacks? Assume that I access index now. php then right-click to view the source code, copy the token, create a new form page locally, and submit the address to B. php: If I use the copied token value, will the cross-origin process be completed?

Thank you for your patience. I was prompted by a monthly message. I read the session control section in the book and briefly talked about the session mechanism and the index on different computer access servers. the php script sets a cookie file with the unique session_id value locally, and the server also has the same data as your local session_id value, the $ _ SESSION ['token'] value is saved. Therefore, due to the uniqueness of session_id in your local cookie, the session data of different computers on the server is different.

Reply content:

Today, we can see the method in the book to prevent cross-origin submission. it generates a hidden input on the form submission page and the value is a random number in the session.

Index. php page

The following is B. php code

if($_POST['token'] == $_SESSION['token']){    # do code}

My question is, can this really prevent cross-origin attacks? Assume that I access index now. php then right-click to view the source code, copy the token, create a new form page locally, and submit the address to B. php: If I use the copied token value, will the cross-origin process be completed?

Thank you for your patience. I was prompted by a monthly message. I read the session control section in the book and briefly talked about the session mechanism and the index on different computer access servers. the php script sets a cookie file with the unique session_id value locally, and the server also has the same data as your local session_id value, the $ _ SESSION ['token'] value is saved. Therefore, due to the uniqueness of session_id in your local cookie, the session data of different computers on the server is different.

First, the method you mentioned cannot cross-origin.

if($_POST['token'] == $_SESSION['token']){    # do code}

Pay attention to the above test. What is $ _ SESSION ['token?
The SESSION is only valid for your own webpage. do you want to create it?

The correct idea is to copy the local Cookie (corresponding to the SESSION information) and then send it.
However, it is impossible to simply use a browser or handwritten HTML.
To prevent cross-origin submission, you only need to ensure that the webpage is not under JS attacks from other webpages. do not expect too much.

In addition, you need to know that the web page is open to everyone, and all your accessible PHP may receive various parameters.
Hacker attacks, user abuse, web page bugs ......

For example, you need to enter a phone number to submit a form.
You may disable JS and enter a 20-digit number.
Hackers may use tools to send parameters to test your background code.
So?
So you don't need to write the code to check whether the phone number is correct?

It cannot be a waste of food, cool.

Under normal circumstances, cross-origin commit is prevented fromdomainASubmit datadomainBIn this case,
And under normal circumstancesdomainAThere is no way to get the following pagedomainBThe content on the next page of the domain,
Instead, you can directly skip the browser's restrictions on different domains (you can manually obtain the tokens and cannot obtain the content in different domains ), so your practice is actually not feasible (not that you submittokenThe other party does not approve, but indicates that you arehttp/httpsCannot be automated ).

In additiontokenIn addition, there are some additional methods, such as detecting the source of the request (referer) Is it for this site.

Yes, that's right. Cross-origin is only the security measure of the browser itself.
What if there are browsers that do not follow the rules in the future?
Why can I post a session in a debugging tool like flider?
However, session (token) is the identifier of the user's valid identity. these are also for login or authentication.
The only possibility is that he is a developer or a robot...

In addition, token is mainly used to prevent repeated submission or csrf

I am really confused. after the processing code of B. php finishes processing a form, it will destroy the session token so that each submission and processing will be a new token and soon solve the cross-origin problem? What the landlord said is already great. just add it.