The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

206

Chapter 7 

■

Attacking Session Management

70779c07.qxd:WileyRed  9/14/07  3:13 PM  Page 206

---

obtains a large sample of tokens from the application in the usual way to pre-

dict or extrapolate the tokens issued to other users.

The most effective token generation mechanisms are those that:

(a) use an extremely large set of possible values, and

(b) contain a strong source of pseudo-randomness, ensuring an even and

unpredictable spread of tokens across the range of possible values.

In principle, any item of arbitrary length and complexity may be guessed

using brute force given sufficient time and resources. The objective of design-

ing a mechanism for generating strong tokens is that it should be extremely

unlikely that a determined attacker with large amounts of bandwidth and pro-

cessing resources should be successful in guessing a single valid token within

the lifespan of its validity.

Tokens should consist of nothing more than an identifier used by the server

to locate the relevant session object to be used for processing the user’s

request. The token should contain no meaning or structure, either overtly or

wrapped in layers of encoding or obfuscation. All data about the session’s

owner and status should be stored on the server in the session object to which

the session token corresponds.

Care should be taken when selecting a source of randomness. Developers

should be aware that the various sources available to them are likely to differ

in strength very significantly. Some, as with 

java.util.Random

, are perfectly

useful for many purposes where a source of changing input is required, but

can be extrapolated in both forward and reverse directions with perfect cer-

tainty on the basis of a single item of output. Developers should investigate

the mathematical properties of the actual algorithms used within different

available sources of randomness and should read relevant documentation

about the recommended uses of different APIs. In general, if an algorithm is

not explicitly described as being cryptographically secure, it should be

assumed to be predictable.