PHP Security-replay attack

Replay attack replay attacks are sometimes called demonstration attacks. an attacker can reproduce the data sent by a valid user to the server to obtain access or other permissions assigned to the user. Like password sniffing, anti-DDoS...

Replay attacks

Replay attacks are sometimes called demonstration attacks. an attacker can reproduce the data sent by a valid user to the server to obtain access or other permissions assigned to the user.

Like password sniffing, preventing replay attacks also requires you to be aware of data exposure. To prevent replay attacks, you need to increase the difficulty for attackers to obtain any data used to obtain access permissions for restricted resources. This mainly requires avoiding the following practices:

Sets the use of data with permanent access to protected resources;

Set data exposure for protected resource access (or even data that only provides temporary access );

In this way, you should only use the data that sets the temporary access to protected resources, and try your best to avoid this data leakage. These are general guiding principles, but they can provide guidance for your operating mechanism.

The first principle, as far as I know, violates it at an astonishing frequency. Many developers only pay attention to protecting sensitive data exposure, while ignoring the risks arising from the use of data that is used to set permanent access to protected resources.

For example, consider using a local script to calculate and verify the hash value of the form password. In this way, the plaintext of the password will not be exposed, but its hash value will be exposed. This protects the user's original password. The main problem with this process is that the replay vulnerability remains the same-an attacker can simply replay a valid verification process to pass verification. as long as the user password is consistent, the verification process will succeed.

For more secure running solutions, MD5 JavaScript source files, and other algorithms, see #.

A violation similar to the first principle is to specify a cookie to provide permanent access to a resource. For example, consider the following attempt to set a permanent access mechanism for cookie running:

CODE:   
 

If an unauthenticated user provides a verification cookie, the program checks whether the hash value of the password in the cookie matches the hash value of the password in the database. If yes, the user passes the verification.

The problem in this process is that the exposure of the authentication cookie is a very high risk. If it is captured, the attacker will gain permanent access. Although the cookie of a legal user may expire, attackers can provide the cookie for verification every time. See the figure in-2 for this situation.

A better permanent login solution is to only use data that sets temporary access permissions, which is also the topic of the next section.

The above is the PHP Security-replay attack content. For more information, see PHP Chinese network (www.php1.cn )!