PHP Security-Replay attack

Replay attack

Replay attacks, sometimes referred to as demo attacks, where an attacker reproduces data sent by a previously legitimate user to the server to gain access or other rights assigned to the user.

As with password sniffing, preventing replay attacks also requires you to be aware of data exposure. To prevent replay attacks, you need to increase the difficulty of an attacker acquiring any data that is used to gain access to a restricted resource. This is primarily a requirement to avoid the following practices:

The use of data that sets permanent access to protected resources;

The exposure of data that sets access to protected resources (even data that provides temporary access only);

This way, you should only use data that sets temporary access to protected resources, and you should try to avoid that data leak. These are just general guidelines, but they can provide guidance for your operational mechanisms.

The first principle as far as I know, the frequency of violating it has reached a frightening level. Many developers are only aware of the protection of sensitive data exposure, ignoring the risk of data being used to set the permanent access to protected resources.

For example, consider the case where a local script calculates the hash value of the validation form password. So the plaintext of the password is not exposed, only its hash value is 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 legitimate verification process to verify that the validation process succeeds as long as the user's password is consistent.

For a more secure run scenario, MD5 JavaScript source files, and other algorithms, see http://www.php.cn/.

A violation similar to the first principle is the designation of a cookie to provide permanent access to a resource. For example, consider the following attempt to run a persistent access mechanism by setting a cookie:

CODE:   <?php  $auth = $username. MD5 ($password);  Setcookie (' auth ', $cookie);  ? >

If an unauthenticated user provides a validation cookie, the program checks whether the hash value of the password in the cookie matches the hash of the password that exists in the database. If it matches, the user validates the pass.

The problem with this process is that the exposure to the validation cookie is a very large risk. If it is captured, the attacker gains permanent access. Although a legitimate user's cookie may expire, an attacker can provide a cookie every time for verification. Take a look at the diagram in Figure 7-2 for this scenario.

A better permanent sign-in scenario is to use only data that sets temporary access, which is also the subject of the next section.

The above is the PHP security-replay attack content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

