CSRF defense instance (PHP)

The protection of CSRF can be started from both the server and the client. the defense effect is better from the server, and the general CSRF defense is also carried out on the server. 1. the server can defend against CSRF attacks from both the server side and the client side. the defense effect is better from the server side, and the general CSRF defense is also carried out on the server side.

1. the server performs CSRF defense

The CSRF methods on the server are diverse, but the general idea is the same, that is, to add pseudo-random numbers on the client page.

(1). Cookie Hashing (all forms contain the same pseudo-random value ):

This may be the simplest solution. because attackers cannot obtain third-party cookies (theoretically), the data in the form fails to be constructed:>

Add the Hash value in the form to authenticate the request sent by the user.

Verify the Hash value on the server.

I personally think this method can prevent 99% of CSRF attacks. what about 1% .... because the user's Cookie is easily stolen due to the XSS vulnerability of the website, this is another 1%. Generally, attackers will give up when they see that they need to calculate the Hash value, except for some. Therefore, if 100% is required, this is not the best method.

(2). verification code

The idea of this solution is: every time a user submits a request, the user needs to fill in a random string on the image in the form .... this solution can completely solve CSRF, but I personally think it seems that it is not very easy to use. I also heard that the use of verification code images involves a Bug called MHTML, some versions of Microsoft IE may be affected.

(3). One-Time Tokens (different forms contain different pseudo-random values)

Note the following when implementing One-Time Tokens: "compatibility of parallel sessions ". If a user opens two different forms at the same time on a site, The CSRF protection measures should not affect the submission of any form. Consider what will happen if the site generates a pseudo-random value to overwrite the previous pseudo-random value when each form is loaded: The user can only successfully submit the last opened form, because all other forms contain invalid pseudo-random values. You must be careful when performing this operation to ensure that CSRF protection does not affect option-based browsing or that multiple browser windows are used to browse a site.

The following is my implementation:

1). First, the token generation function (gen_token ()):

 
 
2). then the Session token generation function (gen_stoken ()):
     
  
3). functions used to generate a WEB form to hide input fields:
     
   “;     　　}     ?>
4). WEB form structure:
     
       
5). verify the token on the server:
This is very simple, so I will not be embarrassed here.
The preceding rule does not fully comply with the "parallel session compatibility" rule. you can modify it on this basis.