PHP Security - Replay Attack

Replay attack

A replay attack, sometimes called a demonstration attack, is where an attacker replays data previously sent by a legitimate user to the server to gain access or other rights assigned to that user.

Like password sniffing, preventing replay attacks requires you to be aware of data exposure. To prevent replay attacks, you need to make it more difficult for an attacker to obtain any data used to gain access to restricted resources. This mainly requires avoiding the following practices:

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

Setting protected Exposure of data that provides access to resources (even data that only provides temporary access);

In this way, you should only use data that establishes temporary access to protected resources, and you should also try to avoid leaks of this data. These are just general guidelines, but they can provide guidance on how you operate.

The first principle is, as far as I know, violated with frightening frequency. Many developers focus only on protecting sensitive data from exposure and ignore the risks that arise when the data used to set permanent access to protected resources is used.

For example, consider a local script that calculates a hash of a password for a form validation form. In this way, the plaintext of the password will not be exposed, only 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 the legitimate authentication process once and pass the authentication, and as long as the user's password is consistent, the authentication process will succeed.

For more secure operation solutions, MD5 JavaScript source files and other algorithms, please see http://www.php.cn /.

A similar violation of the first principle is specifying 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(&#39;auth&#39;, $cookie);
  ?>

If an Authenticating the user provides an authentication cookie, and the program checks to see if the hash of the password in the cookie matches the hash of the password stored in the database. If they match, the user is authenticated.

The problem with this process is that exposure of the authentication cookie is a very large risk. If it is captured, the attacker gains permanent access. While a legitimate user's cookie may expire, an attacker can provide the cookie for authentication every time. See Figure 7-2 for an illustration of this situation.

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

The above is the content of PHP security-replay attack. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!