Приглашаем посетить
Добычин (dobychin.lit-info.ru)

Section 7.3.  Replay Attacks

Previous
Table of Contents
Next

7.3. Replay Attacks

A replay attack, sometimes called a presentation attack, is any attack that involves the attacker replaying data sent previously by a legitimate user in order to gain access or other privileges granted to that user.

As with password sniffing, protecting against replay attacks requires you to be mindful of data exposure. In order to prevent replay attacks, you want to make it very difficult for an attacker to capture any data that can be used to gain access to a protected resource. This primarily requires that you focus on avoiding the following:

  • The use of any data that provides permanent access to a protected resource

  • The exposure of any data that provides access to a protected resource (even when the data provides only temporary access)

Thus, you should use only data that provides temporary access to protected resources, and you should avoid exposing this data as much as possible. These are generic guidelines, but they can offer guidance as you implement your mechanisms.

The first guideline is one that I see violated with frightening frequency. Many developers focus on protecting sensitive data from exposure but ignore the risks of using data that provides permanent access.

For example, consider the use of client-side scripting to hash the password provided in an authentication form. Instead of the cleartext password being exposed, only its hash is. This protects the user's original password. The problem with this approach is that it is still vulnerable to a replay attackan attacker can simply replay a valid authentication attempt in order to be authenticated, and this works as long as the user's password is consistent.

Section 7.3.  Replay Attacks

For more secure implementations and JavaScript source for MD5 and other algorithms, see http://pajhome.org.uk/crypt/md5/.


A similar violation of the first guideline is assigning a cookie that provides permanent access to a resource. For example, consider an attempt to implement a persistent login mechanism that issues cookies as follows:

    <?php

    $auth = $username . md5($password);
    setcookie('auth', $cookie);

    ?>

If an unauthenticated user presents an auth cookie, it can be inspected to determine whether the hash of the password in the cookie matches the hash of the password stored in the database for that user. If it does, the user is authenticated.

The problem with this approach is that the exposure of this cookie is an extreme risk. If captured, it provides an attacker with permanent access. Although the legitimate user's cookie may expire, an attacker can always present the cookie required for authentication, and until the legitimate user's password changes, authentication is successful. See Figure 7-2 for a complete illustration of this scenario.

A better persistent login implementation uses data that only temporarily grants access, and this is the topic of the next section.


Previous
Table of Contents
Next